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. 1 Tool call: the MCP client sends a tools/call request to the server with the tool name and input parameters.
  2. 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. 3 Payment construction: the payment-aware MCP client constructs a stablecoin transaction, signs it with its embedded wallet, and broadcasts to the network.
  4. 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. 5 Retry with proof: the client resends the tools/call request with the X-Payment header containing payment proof.
  6. 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:

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.