← Return to Operating System Overview

Context

As the Model Context Protocol (MCP) rapidly scales to become the standard interface for autonomous agents, a critical vulnerability in the unit economics of the Agentic Web has emerged.

Currently, MCP provides no native protocol-level mechanism for payment tracking, session budget caps, or token metering. As highlighted in recent ecosystem discussions (e.g., google-gemini/gemini-cli#4472), developers are experiencing massive, unexpected API bills (e.g., $2,800 in 60 seconds) because autonomous agents can enter infinite loops or aggressively poll paid resources with zero proactive financial guardrails.

Simultaneously, open-source MCP server creators are struggling to host their servers publicly because they absorb the inference and database COGS without a standardized way to bill the agent operator per-transaction.

Proposal

We propose introducing x402 (inspired by the HTTP 402 Payment Required status code)—a standardized protocol extension for MCP that introduces native capabilities for token metering, live margin tracking, proactive session budget firewalls, and compliance verification.

1. The capabilities Extension

Servers should be able to advertise their metering and billing requirements during the initialization handshake.

{
  "protocolVersion": "2024-11-05",
  "capabilities": {
    "prompts": {},
    "resources": {},
    "tools": {},
    "x402_metering": {
      "supported": true,
      "currency": "usd",
      "enforces_budget_caps": true,
      "supports_preflight_quotes": true
    }
  },
  "serverInfo": {
    "name": "Titan Signal Core Server",
    "version": "1.0.0"
  }
}

2. Pre-Flight Quotes (Client-Side Guardrails)

While server-side accounting is necessary, the most effective way to stop a runaway agent loop is for the client to decline the call before making it.

We propose a native primitive to request a pre-flight quote. A client can ping the server with the intended payload, and the server returns a projected_cost_usd or projected_tokens. This allows the client to make a budgetary decision before dispatching the actual request, rather than only discovering the cost inside an error path.

3. Standardized JSON-RPC Error: 4020 Payment Required

Currently, if an MCP server wants to block a transaction because the client has insufficient funds or has exceeded their session budget, they must return a generic -32000 Server Error.

We propose adding a standardized -4020 JSON-RPC error code to explicitly signal that a transaction was blocked due to financial guardrails.

{
  "jsonrpc": "2.0",
  "id": 4,
  "error": {
    "code": -4020,
    "message": "x402: Session budget of $10.00 USD exceeded.",
    "data": {
      "projected_cost_usd": 0.05,
      "remaining_budget_usd": 0.01
    }
  }
}

4. Compliance and Sanctions Verification (HTTP 451)

Before settlement, facilitators must be able to decline payments to sanctioned or high-risk entities. Alongside -4020, we propose a verify step that carries a compliance decision. A hard failure maps to an HTTP 451 Unavailable For Legal Reasons at the facilitator boundary.

{
  "jsonrpc": "2.0",
  "id": 4,
  "error": {
    "code": -4510,
    "message": "x402: Payment declined due to compliance sanctions.",
    "data": {
      "decision": "FAIL",
      "reason_code": "OFAC_SANCTION_MATCH",
      "evidence_uri": "https://compliance.provider/report/12345"
    }
  }
}

Keeping this compliance decision in-band avoids bolting it on later and prevents an agent from blindly looping against a sanctioned endpoint.

5. Per-Transaction Cost Headers (Metadata)

When an MCP Server responds to a tool call or resource read, it should optionally include x402 metadata indicating the cost of that specific transaction. This allows the client to maintain a live ledger.

{
  "jsonrpc": "2.0",
  "id": 4,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "..."
      }
    ],
    "_x402": {
      "cost_usd": 0.05,
      "input_tokens": 1200,
      "output_tokens": 400
    }
  }
}

Why this belongs at the Protocol Level

If billing and metering are pushed to the API gateway layer or handled via ad-hoc SDK decorators, the ecosystem will fracture. Agents will not know how to automatically handle -4020 or -4510 responses if every server implements it differently.

By standardizing x402 in the core protocol:

• Developers are protected: Agents can natively halt themselves before dispatching calls if a pre-flight quote exceeds budgets.
• Compliance is Native: Sanctions checking is baked directly into the payment negotiation.
• Creators can monetize: Open-source developers can safely host their MCP servers, knowing the protocol enforces their required take-rate.

Reference Implementation & Ecosystem Adoption

Our team has built a working reference implementation of this logic at the SDK level (Titan Signal Core), demonstrating 1-ms latency ledger validation and proactive blocking. This architecture has recently been greenlit for integration by the Haystack framework, cementing x402 as the foundational billing standard for the open-source ecosystem. We are actively finalizing upstream contributions to the core MCP specification.