Decionis CommerceGate MCP

Use this first, or when someone asks 'can you check prices, orders or refunds against our policy?'. It lists the seven kinds of commerce action CommerceGate can check in Shadow Mode: price changes, inventory updates, order acceptance, fulfillment steps, promotion changes, refund requests, and return authorizations. It also explains PROCEED, HOLD, and BLOCK, tenant connection state, and available evidence tools. This local diagnostic never calls the Decionis API, reveals credentials, or claims that a platform connector can execute an action.

Use this as the default preflight before a price, inventory, order-acceptance, fulfillment, promotion, refund, or return proposal, for questions like 'would repricing this SKU to $89 on Walmart still clear our margin floor after the referral fee?', 'is it safe to accept this 40-unit order with the stock we have left?', or 'can the support bot refund $2,850 on this order?'. It sends the bounded canonical action and policy signals to Decionis in SHADOW mode and may persist a signed Decision Dossier. This is a generic Protocol evaluation: it never calls a marketplace API, executes the proposal, or confirms that a connector exposes the required write path. The result maps to PROCEED, HOLD, or BLOCK: APPROVE is evidence, not consent to execute; REJECT means stop; REVIEW or ESCALATE means hold for a human.

Use this to answer 'why was that order held?' or 'what policy version decided that price change?' by reading the signed Decision Dossier for a known dossier UUID within the environment-bound organization. This is a tenant read; it never executes or modifies a commerce action and it fails closed when credentials are absent or invalid.

Use this when finance or an auditor asks for signed evidence by fetching the proof packet for a known dossier UUID in the environment-bound organization. The tool is read-only, performs no marketplace action, and never treats successful verification as permission to execute.

Use this to answer 'what would Shadow Mode have held recently?' by listing recent SHADOW evaluations in the environment-bound organization across price, inventory, order, fulfillment, promotion, refund, and return proposals. Results describe what policy would have done; they do not report marketplace execution and must not be interpreted as authority to mutate commerce state.

Use this for 'how much would we have caught this month?' style questions: aggregate SHADOW outcomes, near misses, and policy mismatches for the environment-bound organization, so an operator can judge whether to turn enforcement on. It is a read-only operational summary; it neither changes enforcement mode nor executes any commerce action.

Use this for a fully formed Dynamics 365 Business Central or Finance and Supply Chain Management transaction that needs central enforced authorization. CommerceGate evaluates line economics first and, only after policy clears, atomically authorizes the agent budget before returning the binary ALLOW or BLOCK decision used by the ERP enforcement shell. The tool can reserve budget and returns a reason-coded validation response; unlike the Shadow evaluator, it does not promise a retrievable dossier. It never writes, posts, releases, or modifies the ERP transaction itself. ALLOW is authorization evidence for the exact transaction, not user consent to perform the ERP write.