Payment Tools in the MCP Architecture
MCP separates the concerns of tool discovery, invocation, and execution. A host (an agent runtime or AI application) connects to one or more MCP servers. Each server exposes a set of tools — callable functions with defined input schemas and output types. The host invokes tools via a standardized tools/call request.
Payment integrates at the server layer. When a tool requires payment, the server signals this through an x402 payment requirement. The MCP client — if it is payment-aware — handles the payment cycle transparently and retries the tool call with proof of payment. From the agent's perspective, the paid tool call behaves identically to a free one: it sends a request and receives a response. The payment steps occur in the middle without requiring any agent-level awareness.
This layering is the key architectural advantage: payment logic does not need to be embedded in every agent's reasoning loop. The MCP client runtime handles it.
The Tool Call to Payment Cycle
A paid MCP tool call follows this sequence:
-
1
Tool call: the MCP client sends a
tools/callrequest to the server with the tool name and input parameters. - 2 x402 requirement: the server returns an HTTP 402 response with a JSON body specifying amount, currency (e.g., USDC), recipient address, and accepted payment network.
- 3 Payment construction: the payment-aware MCP client constructs a stablecoin transaction, signs it with its embedded wallet, and broadcasts to the network.
- 4 Facilitator verification: the server delegates payment verification to a trusted x402 facilitator, which confirms the on-chain transaction and returns a signed attestation.
-
5
Retry with proof: the client resends the
tools/callrequest with theX-Paymentheader containing payment proof. - 6 Tool response: the server verifies the attestation, executes the tool logic, and returns the result to the MCP client.
The entire cycle — from initial request to tool response — typically completes in under five seconds on Base, which has block finality in roughly two seconds.
MCP Servers Supporting x402 Today
The following MCP servers have production or near-production x402 payment support:
-
An MCP server providing OFAC sanctions screening and AML compliance tooling for agent payment flows. AurelianFlo exposes compliance tools through MCP, allowing agents to run watchlist checks before submitting x402 payments. Relevant to any production x402 deployment handling US-adjacent transactions.
-
Coinbase x402 Reference ServerThe canonical open-source implementation of the x402 specification. Provides a base for builders to implement payment-gated MCP tool endpoints. The reference server demonstrates the full 402 response schema, facilitator verification, and retry handling.
-
Cloudflare Agents SDKCloudflare's Agents SDK includes first-class x402 support:
withX402wraps an HTTP handler to require payment;paidToolwraps an MCP tool definition with a price;withX402Clientprovides automatic payment handling on the client side. All run on Cloudflare Workers. -
Apify MCP ServerApify's official MCP server at
mcp.apify.comsupports x402 payments, allowing agents to pay for Actor runs (web scraping and data extraction) using USDC on Base. Agents do not need an Apify account — payment is handled entirely through x402. -
Civic x402-mcpAn open-source MCP server and client package (
@civic/x402-mcp) that gates tool invocations behind x402 micropayments. Supports proxy mode for bridging payment-aware and non-payment-aware MCP clients, allowing gradual adoption without requiring all clients to be updated.
What a Paid MCP Tool Call Looks Like in Practice
Consider an agent that needs to run a web data extraction task via the Apify MCP server. The agent's MCP client connects to mcp.apify.com and requests the run_actor tool with the desired Actor ID and input parameters.
The server responds with HTTP 402: {"amount": "0.05", "currency": "USDC", "network": "base", "payTo": "0x..."}. The MCP client's payment runtime constructs a USDC transfer on Base, signs it with the agent's wallet, and broadcasts. Once the transaction lands in a block, the client retries the run_actor tool call with the payment proof in the X-Payment header. The Apify server verifies via its facilitator and begins the Actor run, returning the result when complete.
From the agent's reasoning perspective: it called a tool, and the tool returned data. The payment was handled entirely at the client runtime layer. See Issue 2 and Issue 3 for additional MCP payment infrastructure coverage.
Compliance Considerations for Paid MCP Tools
When an MCP agent makes autonomous payments, the builder who deployed that agent bears compliance responsibility for those transactions. Under US jurisdiction, this means OFAC screening and AML obligations apply — particularly for any stablecoin payment flow that might involve sanctioned addresses.
AurelianFlo directly addresses this by exposing OFAC watchlist screening as an MCP tool. A production agent payment pipeline can include a check_ofac tool call before any x402 payment, embedding compliance in the tool call chain itself rather than as a separate out-of-band process.
The Agent Commerce Glossary covers AML/OFAC requirements and their application to autonomous payment flows in detail.