Who told the agent it could spend?

Who told the agent it could spend?

MCP is a common protocol that connects AI agents to external data and services. It already gives agents a standard way to discover and call tools; its new stateless design, introduced in the 2026-07-28 changes, makes that tool-call surface easier to protect with payment policy.

Together, stateless MCP and x402 let an agent request tool access, receive a price, and retry with wallet-approved payment proof while the MCP service handles the tool call independently.

What changed in MCP

Earlier MCP clients began with an initialization handshake. The client and server exchanged their protocol version and capabilities. With Streamable HTTP, a server could also issue a session ID. If it did, the client sent that ID with every later request. Where a server used a session ID, later requests were tied to that session. In a large deployment, a load balancer can send traffic to any available server. The service then has to share session state between servers or route the client back to the server that created the session.

MCP 2026-07-28 removes the handshake and session header. Each MCP request now carries the information that the server needs to handle it. When an application needs state across calls, it can return an explicit handle, such as an invoice ID, and the agent can send that handle with its next request.

How a paid tool call works

x402 is a payment standard for web requests. A service uses 402 Payment Required to state its payment requirements. The client attaches payment proof when it retries.

Before an agent pays for a tool, it needs to understand what the tool does. MCP gives the agent a shared way to discover tools and their inputs. x402 gives the tool a way to state payment requirements for a request. Providers can publish this information openly or protect it with MCP authorization.

The integration pattern proposed here is to apply x402 directly at an MCP HTTP gateway. MCP defines the tool-call protocol. The gateway adds payment enforcement around that MCP request.

The supplier can apply that pattern to an invoice. The first call asks the `pay_invoice` tool to pay invoice `inv-4417`. The gateway checks the agent's token and the requested action, prices the request, and responds with x402 payment requirements before the MCP service performs the tool call. The x402 payment is the provider's fee for invoking `pay_invoice`; it is separate from the amount owed on `inv-4417`.

Agent → supplier gateway → MCP service

POST /mcp HTTP/1.1
Host: supplier.example
Accept: application/json, text/event-stream
Content-Type: application/json
Authorization: Bearer <agent-token>
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: pay_invoice

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "pay_invoice",
    "arguments": {
      "invoice_id": "inv-4417"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientCapabilities": {},
      "io.modelcontextprotocol/clientInfo": {
        "name": "ExampleAgent",
        "version": "1.0.0"
      }
    }
  }
}

HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED:  <base64-encoded PaymentRequired>

Those requirements state the provider's fee for invoking `pay_invoice`, not the amount owed on `inv-4417`. The agent gives them to its wallet, which checks the amount, recipient, and spending policy before creating payment proof for the retry.

POST /mcp HTTP/1.1
Host: supplier.example
Accept: application/json, text/event-stream
Content-Type: application/json
Authorization: Bearer <agent-token>
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: pay_invoice
PAYMENT-SIGNATURE: <base64-encoded PaymentPayload>

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "pay_invoice",
    "arguments": {
      "invoice_id": "inv-4417"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientCapabilities": {},
      "io.modelcontextprotocol/clientInfo": {
        "name": "ExampleAgent",
        "version": "1.0.0"
      }
    }
  }
}

The gateway verifies and settles the provider fee, then forwards the MCP request. The tool uses the agent's existing payment authority to settle `inv-4417` and returns the result.

HTTP/1.1 200 OK
Content-Type: application/json
PAYMENT-RESPONSE:  <base64-encoded SettlementResponse>

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "resultType": "complete",
    "content": [
      {
        "type": "text",
        "text": "invoice inv-4417 paid"
      }
    ]
  }
}

MCP 2026-07-28 makes this gateway pattern stronger: agents get standard tool discovery and schemas from MCP, while x402 payment enforcement stays at the HTTP request layer through `PAYMENT-REQUIRED`, `PAYMENT-SIGNATURE`, and `PAYMENT-RESPONSE`.

Why it matters

Better infrastructure for paid agent workflows

Stateless MCP makes it easier for teams to separate payment enforcement from tool execution. The MCP service handles each paid request independently. Teams can scale a payment gateway separately from the tools that do the work.

Put spend limits on the agent's wallet. A wallet turns a user's budget into rules that apply across paid tools. The agent can compare a price with those rules before it pays. It can choose a tool, pay for the work, or stop when the work costs too much.

An MCP App could ask a person to approve or decline a payment before the wallet creates payment proof, while the wallet continues to enforce its configured spending limits.

The agent follows one clear payment path. It calls a tool. The gateway returns 402 Payment Required with payment requirements. The wallet creates payment proof when it approves the request. The agent sends the request again. The gateway verifies the proof and passes the request to the MCP service.

Better ways to monetize agent tools

x402 lets providers charge for a data lookup, model call, or tool action at the time of use. MCP gives agents a common way to discover and call those tools. Together, they let providers price agent-facing services without building a custom billing relationship for every buyer.

Conclusion

The session change may look like a transport detail. Paid tools show why it matters. A payment request can now follow a clear path. The agent asks for work, receives a price, gets wallet approval, and retries with proof of payment.