The XGR MCP Gateway now includes optional, mainnet-only purchase tools for preparing bounded XGR purchase orders. The feature is disabled by default and is registered only when the production configuration explicitly enables it.
The tools add a real purchase workflow to the agent-facing MCP surface while preserving a strict separation between order preparation and payment authorization.
Planning and order creation
quote_xgr_purchase can be used for optional planning. create_xgr_purchase_order creates the actual order through the XGR purchase backend.
The backend is authoritative for the binding result, including:
- the final XGR market price,
- the exact crypto amount,
- the custody or payment destination,
- the payment reference,
- and the reservation details.
The MCP Gateway does not reproduce pricing logic locally and does not treat an earlier planning quote as binding.
Bounded autonomous-order policy
The MCP purchase integration applies a maximum autonomous-order policy of 249.99 EUR or less. This is an MCP-side policy boundary, not a general maximum of the XGR purchase backend.
The backend may require additional billing information from a separately calculated threshold. If the backend rejects an order because information is missing or repricing invalidates the request, the MCP returns the error rather than silently changing or retrying the order.
Exact payment instruction, external payment authority
The returned order contains the exact payment instruction. An external wallet agent, user wallet or custody system may execute that instruction under its own authorization rules.
The MCP Gateway does not receive user or third-party private keys and does not pay on behalf of the user. This keeps purchase preparation machine-readable while retaining final authority outside the agent-access layer.
Fixed-amount and budget orders
The purchase tools distinguish between fixed-XGR orders and conservative stablecoin budget orders. For budget orders, the live backend response determines the final amount. If the exact returned amount exceeds the configured cap, the payment is not executed and the reservation expires through the normal backend process.
The implementation is intended as a narrow, auditable building block for agent-assisted payments rather than an unrestricted autonomous wallet.