An opinion about payments, not a payment processor.

The MCP gap

The Model Context Protocol gave agentic systems a clean way to describe tools, resources, and prompts. Discovery has a home — the MCP Registry — and identity has one too, under SEP-2127's Server Card. The one thing missing is money. If the tool I want to call costs $0.003, there is no standard place for a server to say so, and no standard way for an agent to plan around it.

x402 and Tempo's MPP each solve a piece of the problem, but only inside their own ecosystem. An x402-aware agent will not know that the same server also accepts Lightning. An MPP-aware agent will not see card support advertised three lines down. The result is a payment landscape where every wallet sees a different version of the world.

What mcp-pay is

mcp-pay is a single JSON file served at /.well-known/mcp/pay.json. It lists pricing per tool, the rails the server accepts, and the SLA it commits to for settlement. It is rail-agnostic. It is cacheable. It is meant to be small enough that you can paste an example into a fresh repo and start charging within a day.

The current draft (v0.1) ships:

• A JSON Schema at specs/schema/pay.schema.json.
• A written specification at specs/mcp-pay-specification.md.
• Three Rust crates: mcp-pay-schema, mcp-pay-server, and mcp-pay-cli (the CLI is Phase 2 work).
• A working axum reference server that returns HTTP 402 on paid endpoints and verifies x402 payments via a facilitator URL.

What mcp-pay is not

It is not a payment processor. Settlement happens on the underlying rail. mcp-pay describes; it does not custody.

It is not an MCP registry. The Registry is the right place for capability discovery. mcp-pay is the right place for pricing discovery. The two manifest files sit side by side in /.well-known/mcp/.

It is not a token. There is no governance system. There is no fee. The schema is MIT/Apache-2.0 licensed and any server can adopt it without asking.

The design principles

The specification has four stated principles, and we are trying to be honest about them.

• Complementary. It works alongside the MCP Server Card. No duplicated fields; the manifest links to the card and stays focused on payments.
• Rail-agnostic. The same manifest can advertise x402, MPP, Lightning, card, and ACH. The agent picks.
• Minimal. Only payment-specific fields. If a field can live in the Server Card, it does.
• Cacheable. The manifest is static. Dynamic data — usage stats, congestion — lives in a separate endpoint.

How it relates to SEP-2127

SEP-2127 defines the MCP Server Card. mcp-pay is being drafted as a companion specification — proto-SEP for the same working group — that focuses on the payment dimension. The two manifest files coexist at /.well-known/mcp/server-card.json and /.well-known/mcp/pay.json. Either can be deployed without the other; neither replaces the other.

Status today

v0.1 is a draft. Phase 1 (schema + reference server) is complete. Phase 2 (registry crawler), Phase 3 (rail router that picks the cheapest acceptable rail per call), and Phase 4 (submission as a SEP) are planned, in that order.

The repository is at github.com/neul-labs/mcp-pay. Issues and pull requests are open. The license is dual MIT / Apache-2.0.

Who Neul Labs is

Neul Labs builds developer infrastructure for agentic AI. mcp-pay is one of a handful of small specifications we are working on around MCP. We are interested in the parts of the stack where standards do not yet exist and where the early-but-not-too-early decisions will compound. Payment metadata is one of those.