The Open MCP Billing Standard — How AI Agents Pay for Tools

The Problem: MCP Tools Can't Charge for Anything

Anthropic's Model Context Protocol has become the standard way AI agents interact with external tools. Thousands of MCP servers exist — code analysis, data retrieval, web scraping, image generation — and the ecosystem is growing exponentially.

But here's the uncomfortable truth: almost none of them make money.

The MCP spec defines how agents call tools. It says nothing about how agents pay for tools. Every builder who wants to charge has to invent their own auth, metering, invoicing, and payment flow from scratch. Most don't bother. They open-source it, run it at a loss, or just don't build it.

This is the AI equivalent of the pre-Stripe web. You could build a store, but accepting payments required a merchant account, a payment gateway, PCI compliance, and weeks of integration work. The result? Fewer stores got built.

The same thing is happening with MCP. Without a billing standard, the tools that should exist — the expensive-to-run, high-value tools — don't get built because there's no business model.

What the MCP Billing Standard Actually Does

The open MCP billing spec (published by Agent Bazaar) defines four primitives that, together, give every MCP server a complete monetization layer:

• 01.Pricing Schemas. Providers declare their pricing in a machine-readable format right in the MCP tool manifest. Per-call flat fees, per-token metering, tiered volume pricing, free tiers — all expressible in a single JSON object. Agents can compare prices across providers before making a single call.
• 02.Meter Events. Every billable action emits a structured meter event — a timestamped record of what was consumed (tokens, API calls, compute seconds). These events are the source of truth for billing. They're append-only, tamper-evident, and auditable by both parties.
• 03.Receipts. After each tool call, the provider returns a cryptographically signed receipt. The receipt references the meter events, the total cost, and a hash that proves the response matches what was billed for. Agents can verify receipts locally — no trusted third party required.
• 04.Trust Scores. The spec includes a trust and reputation layer. Providers accumulate scores based on uptime, response accuracy, billing honesty, and dispute outcomes. Agents can filter tool discovery by minimum trust threshold — “only show me providers with 95%+ reliability.”

Together, these four primitives turn “I built an MCP server” into “I have a business.”

Think of It as Stripe for MCP

The analogy is direct. Before Stripe, every web merchant needed custom payment infrastructure. Stripe standardized it: a universal API, transparent pricing, built-in fraud detection, and instant payouts.

The MCP billing standard does the same thing for AI agent payments:

The key difference: Stripe is a company. The MCP billing standard is an open specification. Anyone can implement it. No vendor lock-in, no platform fees baked into the protocol itself.

Why Open Standards Beat Proprietary Solutions

The MCP billing space isn't empty. Several projects have taken a proprietary approach — xpay and MCP Hive among them. They offer billing dashboards, hosted metering, and managed payment flows. They work. But they come with trade-offs that matter at scale:

• →Vendor lock-in. Proprietary billing means your revenue depends on a single platform's uptime, pricing decisions, and terms of service. If they raise fees or shut down, you're stranded.
• →Opaque metering. Closed platforms control how usage is measured. You trust their numbers. With an open standard, both provider and consumer can independently verify meter events.
• →Ecosystem fragmentation. If every platform invents its own billing protocol, agents need a different integration for each one. A shared standard means one integration works everywhere — the same reason HTTP won over proprietary networking protocols.
• →No community governance. Proprietary specs evolve based on one company's roadmap. Open specs evolve based on what the ecosystem actually needs. Pull requests beat feature requests.

This isn't hypothetical. We've seen this pattern play out in payments (open banking vs. closed APIs), identity (OAuth/OIDC vs. proprietary SSO), and infrastructure (Kubernetes vs. proprietary orchestrators). Open standards win on a long enough timeline because they reduce friction for everyone.

The Trust Layer: Verification, SLAs, and Disputes

Billing without trust is just invoicing. The MCP billing standard includes a trust layer that makes AI agent payments safe for both sides:

Provider Verification

Providers register with a verifiable identity — domain ownership, GitHub org, or on-chain address. Agents can confirm they're talking to the real provider, not a man-in-the-middle. Verification status is included in discovery responses so agents can filter for verified-only providers.

SLA Metrics

Every provider exposes machine-readable SLA metrics: uptime percentage, p50/p95/p99 latency, error rate, and median response quality score. These aren't self-reported — they're aggregated from actual consumer interactions and independently auditable.

This means an agent can make decisions like: “I need a code analysis tool with <500ms p95 latency and 99.5% uptime. Show me options.” No human research required. The agent shops for tools the way a load balancer picks healthy backends.

Dispute Resolution

What happens when a provider charges for a tool call that returned an error? Or when the response doesn't match what was promised? The spec defines a dispute flow:

1. 01.Consumer submits a dispute referencing the signed receipt and meter events.
2. 02.Provider responds with evidence (logs, response hashes).
3. 03.Resolution is determined by the marketplace implementation — automated checks for clear-cut cases (error responses billed at full price), human review for edge cases.
4. 04.Dispute outcomes feed back into the provider's trust score. Repeated bad behavior degrades discoverability.

The result is a self-correcting marketplace. Bad actors get priced out by the reputation system, not by a platform admin making judgment calls.

Getting Started

The MCP billing standard is open and available today. Here's how to start:

• →Read the spec. The full specification is at /specs/mcp-billing-v1. It covers pricing schemas, meter events, receipts, trust scores, and the dispute flow in detail.
• →Browse the reference implementation. The GitHub repo includes TypeScript types, validation utilities, and example implementations for both providers and consumers.
• →Add billing to your MCP server. The minimum integration is three things: a pricing object in your tool manifest, meter event emission on each call, and receipt generation in your response. The reference implementation handles most of this with a single middleware wrapper.
• →List your tool on Agent Bazaar. Once your server supports the billing spec, you can register it on noui.bot for discovery. Agents find you, call you, pay you — all through the standard protocol.
• →Contribute. The spec is living. Open issues, propose extensions, or submit PRs. The goal is a community-owned standard, not a corporate one.

The Economics Have to Work

AI agents are going to consume more API calls than humans ever did. The tools they use need sustainable economics. That means billing infrastructure that's as standardized and boring as HTTP — something every tool builder can adopt in an afternoon, and every agent can interact with automatically.

The MCP billing standard is that infrastructure. It's open, it's implemented, and it's ready for builders who want to turn great MCP tools into real businesses.

AI agent payments shouldn't require a proprietary platform. They should require a standard.