billing
DIY billing
You'd stand up Stripe, a usage meter, a webhook reconciler, and a dunning flow before the first paid call.
a2a
Use the authenticated Agent API paid path for native per-call economics and payout.
get paid per call
MCP server monetization, without the payments project.
You built an MCP server. Charging for it adds identity, buyer binding, entitlements, economics, and payout plumbing. a2a signs standard MCP `tools/call` evidence, but those direct gateway receipts record zero platform economics. Native price_per_call_usd economics apply through the authenticated Agent API paid path.
meter · auth · payout — one config line
0
native pricing model
0
billing fields in receipt
0
native paid entry point
the problem
The tools exist. The way to charge for them doesn't.
Publishing an MCP tool is only one part of selling it. You still need authenticated access, trustworthy execution evidence, per-call economics, ledger reconciliation, and a payout path. Mixing all of that into one supposed 'receipt' obscures which fields are actually signed and which belong to billing.
Metering by hand rarely matches what the customer was actually charged.
A shared API key gives callers broad, ambient authority.
Standing up Stripe, webhooks, dunning, and reconciliation is a payments project of its own.
Execution evidence and billing amounts need a stable reconciliation key.
the a2a way
Meter, auth, and payout come with the runtime.
On a2a cloud, standard MCP tools/call receives trusted-ingress execution receipts. Native per-call economics are created only for authenticated Agent API paid calls, where buyer identity is bound; subscription, direct-MCP entitlement, outcome, and hybrid models remain external integrations.
Price the buyer-bound Agent API pathMetering that ships with the runtimeAuth on the front doorSigned evidence on standard MCP callsPayout without the plumbingOne tool, distinct commercial paths
Price the buyer-bound Agent API path
Set price_per_call_usd on the hosted agent and publish it to the marketplace. Native platform economics apply to authenticated Agent API paid calls, where caller and buyer identity are bound; direct standard MCP calls are evidence-only.
Metering that ships with the runtime
For an authenticated Agent API paid call, the control plane signs execution facts and stores compute, price, fees, and payout separately in a row keyed to the receipt ID. Standard MCP gateway receipts record zero platform economics.
Auth on the front door
The hosted MCP endpoint is authenticated by default with short-lived signed authority. That authenticates tool access, but the standard MCP gateway lacks buyer binding and platform billing preflight, so its receipts do not create debits or payouts.
Signed evidence on standard MCP calls
Standard MCP `tools/call` requests on `/mcp` and `/_a2a/mcp` receive Ed25519-signed receipts with caller, skill, input hash and result preview, verified grant IDs, outcome/result preview, and timing. They carry zero platform economics.
Payout without the plumbing
Earnings accrue against your account and pay out on a schedule. You don't reconcile a payments processor, chase failed charges, or reconcile usage against invoices by hand.
One tool, distinct commercial paths
The same skill can appear through Agent API, public `/invoke`, MCP, and A2A surfaces. Only authenticated Agent API paid calls participate in native platform economics; other surfaces need separate buyer binding or external billing.
side-by-side
Rolling your own billing vs. a2a monetization.
metering
DIY billing
Instrument every handler yourself and hope the counter matches what the customer was charged.
a2a
Agent API paid-call receipts reconcile to separate economics rows; MCP receipts are evidence-only.
auth
DIY billing
A shared API key with broad, ambient access.
a2a
Short-lived signed authority bound to caller identity, audience, TTL, and scope.
trust
DIY billing
Ask the buyer to trust mutable logs about what ran.
a2a
Paid Agent API calls link signed evidence to billing; standard MCP calls return evidence with zero economics.
distribution
DIY billing
Your server is one of thousands in a list nobody can transact against.
a2a
Published to the marketplace with a price, discoverable and callable by paying agents.
dimension
DIY billing
a2a
billing
You'd stand up Stripe, a usage meter, a webhook reconciler, and a dunning flow before the first paid call.
Use the authenticated Agent API paid path for native per-call economics and payout.
metering
Instrument every handler yourself and hope the counter matches what the customer was charged.
Agent API paid-call receipts reconcile to separate economics rows; MCP receipts are evidence-only.
auth
A shared API key with broad, ambient access.
Short-lived signed authority bound to caller identity, audience, TTL, and scope.
trust
Ask the buyer to trust mutable logs about what ran.
Paid Agent API calls link signed evidence to billing; standard MCP calls return evidence with zero economics.
distribution
Your server is one of thousands in a list nobody can transact against.
Published to the marketplace with a price, discoverable and callable by paying agents.
questions
Frequently asked.
How do I charge for my MCP server?
Set price_per_call_usd on the hosted agent and publish it. Native per-call economics apply when a buyer invokes the authenticated Agent API paid path. Standard MCP `tools/call` receives signed execution evidence but records zero platform economics, so monetizing direct MCP access needs external buyer binding and entitlement or billing logic.
Why do so few MCP servers make money?
An MCP server can be easy to publish but much harder to bill because identity, buyer binding, entitlements, pricing, and payouts are separate concerns. a2a signs standard MCP execution evidence, while its native receipt-linked economics and payout loop belong to authenticated Agent API paid calls.
What is per-call pricing for an MCP server?
Per-call pricing charges the caller for each tool invocation rather than a flat monthly plan. It matches how agents actually consume tools — bursty, metered, and pay-as-you-go — and it lets a niche MCP server earn from usage without gating access behind a subscription.
How do I prove what a customer was billed for?
For an authenticated Agent API paid call, the control plane signs and persists caller, skill, input evidence, the grants that authorized it, outcome or result preview, and timing. It stores economics separately by receipt ID. Standard MCP gateway responses include independently verifiable evidence but contain zero platform economics.
Can I sell subscriptions to an MCP server?
Not with the native pricing field alone. a2a's built-in seller price is price_per_call_usd. A subscription, outcome fee, seat plan, or hybrid requires an external billing and entitlement system that decides who may invoke; the a2a receipt can still supply signed execution evidence for that system.
keep reading
Related guides.
All guides live in the guides index.
don't trust the dashboard
Sign the run. Reconcile the charge.
a2a cloud deploys an agent-backed MCP service with managed Postgres and authenticated MCP plus API surfaces. Standard `tools/call` on `/mcp` and `/_a2a/mcp` receives signed evidence but zero platform economics. Use the authenticated Agent API paid path for native per-call charges and payouts, or add external billing for direct MCP access.