MCP payments: how to monetize an MCP server, per tool call

The Model Context Protocol gives an AI agent a standard way to discover and call your tools. What it doesn’t give you is a way to get paid for those calls. Every MCP server shipping today is, by default, free — and the agents calling it are the most willing buyers software has ever had. This post is about closing that gap: how MCP payments actually work, three patterns for how to monetize an MCP server per tool call, and what you can wire up in a sandbox today.

MCP has no payment primitive — and that’s your opportunity

The MCP specification defines tools, resources, and prompts. It says nothing about money. There’s no price field in a tool schema, no billing handshake, no receipt object. If your tool does something expensive — a GPU render, a data enrichment, a real infrastructure action — the protocol assumes you’ll eat the cost.

That silence is a feature for you. Agents don’t comparison-shop the way humans do; they call the tool that’s registered, does the job, and returns machine-readable output. If your paid tool is the one that works, the payment step is just one more tool call in the plan. The question is which payment pattern to bolt on.

Three ways to charge for a tool call

There are three workable patterns for charging for MCP tool calls today, and they trade off differently.

1. API-key metering + invoice. Issue keys, count calls, bill monthly. This is the classic SaaS model, and it half-works for agents: metering is fine, but the invoice isn’t. An agent completing a task in ninety seconds can’t wait for month-end billing, and it usually has no card, no billing address, and no accounts-payable department. Metering suits standing relationships where a human set up the account first.

2. x402 per-call settlement. The x402 protocol, driven by Coinbase, revives HTTP 402 Payment Required: the server rejects an unpaid request with a machine-readable price, the agent pays on-chain and retries with proof, the server verifies and serves. It’s stateless and per-request — no account, no session. We walk through the full flow in x402 explained.

3. A gateway payment session per unit of work. Your tool creates a payment session — a priced, addressable payment object with an expiry — returns the payment details to the agent, and executes once the session settles. Slightly more stateful than x402, but you get refundable, traceable units of work with webhooks and receipts attached.

	Metering + invoice	x402 per-call	Payment session
Settlement latency	Days to weeks	Seconds	Seconds
Statefulness	Account required	None	One session per job
Refunds / disputes	Manual credit notes	Hard (payment is the request)	Per-session, traceable
Fits agents?	Poorly	For micro-priced calls	For real units of work

The honest rule of thumb: meter when a human owns the relationship, settle inline when the agent does.

Anatomy of a paid MCP tool

Whichever pattern you pick, a paid tool call has the same skeleton:

1. Request. The agent calls your tool with its arguments.
2. Challenge. Instead of executing, the tool returns a price — an x402-style 402 with payment requirements, or a payment session with an amount, a stablecoin, and an address.
3. Payment. The agent pays from its wallet. Stablecoins matter here because the price the agent was quoted is the price that arrives — see why agents pay per use.
4. Execution. Your server verifies settlement and runs the tool.
5. Receipt. The agent gets a machine-verifiable record it can hand back to whoever is auditing its spend.

The whole loop is designed to fit inside a single agent plan: no redirect to a checkout page, no human in the loop, no state the agent can’t inspect.

Worked example: a VPS shop with a six-tool MCP server

We built a simulated VPS dev shop to test exactly this loop end to end. Its MCP server exposes six tools: list_plans, rent_vps, pay_order, order_status, exec_command, and decommission_vps. Registration is one line:

claude mcp add vps-shop -- node vps-shop-sim/mcp/server.js

The interesting tool is pay_order. It loads the agent’s own wallet keypair, SPL-transfers the exact USDC amount from that wallet to the order’s payment address on Solana devnet, and returns the transaction signature plus a Solana explorer link. The shop’s backend watches the Plaidly payment session, flips the order to running once it settles, and the agent moves straight on to exec_command.

To be plain about it: this runs on testnet rails — Solana devnet, real on-chain USDC transfers, no mainnet value at risk. That’s the point of the simulation. We ran six different agents through it unassisted; the full write-up is in six agents bought a VPS with USDC.

Plaidly’s MCP tools for the merchant side

The VPS shop covers the buying side. For the selling side — your side — the Plaidly Node SDK ships a runnable reference stdio MCP server with five tools:

• register_merchant — create a merchant, sandbox by default
• create_session — create a merchant-scoped payment session
• simulate_payment — settle a sandbox session for testing
• verify_webhook — verify a Plaidly webhook signature and parse the event
• pay_x402_resource — retry a 402-protected resource with a payment proof

The server remembers the most recently registered merchant in-process, so an agent can register once and create sessions without juggling keys. Plaidly also exposes an x402 facilitator endpoint that validates whether a chain/network/token payment payload is supported today; full proof settlement through the facilitator is on the roadmap, and we say so rather than pretend otherwise. Setup details live in the Plaidly docs.

Pricing models that fit agents

Agents make pricing simpler, not harder, because nobody is anchoring on a pricing page:

• Per-tool-call — a flat stablecoin price per invocation. The default; trivially predictable for the agent’s planner.
• Per-unit-of-resource — per byte processed, per second of compute, per row enriched. Quote the estimate in the challenge, settle the actual.
• Outcome-based — price the result, not the attempt: a completed enrichment, a provisioned server. This maps naturally to a payment session per job, since the session settles only when the work does.

Meter when calls are tiny and trust exists; settle inline when each call carries real cost or the caller is anonymous.

Receipts for robots

An agent spending someone’s budget needs proof, and PDFs alone don’t cut it. Plaidly gives paid tools two kinds:

• HMAC-signed webhooks. Every event carries a signature of the form t=<unix>,v1=<hex> — an HMAC over the timestamp and payload with your webhook secret. The verify_webhook MCP tool checks it in one call, so an agent (or your server) can prove the “paid” event really came from Plaidly and wasn’t replayed.
• A per-session receipt endpoint. GET /v1/payment_sessions/{session_id}/receipt returns a PDF receipt for the settled session — a fulfillment artifact the agent can attach to its task output for whichever human reads the report.

Signed event for machines, document for humans. Both hang off the same session ID.

Start taking MCP payments in a sandbox

The path from free MCP server to paid one is short:

1. Register a sandbox merchant (via the API or the register_merchant MCP tool).
2. In your priced tool, create a payment session instead of executing immediately, and return the payment details.
3. Verify settlement — webhook signature or session status — then run the tool.
4. Test the whole loop with simulate_payment before touching a real chain.

Everything above runs on Plaidly today via payment sessions and API keys on testnet rails — sandbox settlement, devnet USDC, the works. Mainnet is where the platform is headed, not where your first integration starts, and that’s exactly how you want to build a payment path: prove the loop where mistakes are free. The broader picture of how agents pay is on the agentic payments page.

Your tools already do the work. Let them send an invoice that settles in seconds.