Paying for MCP Tools with Stripe's Machine Payments Protocol (MPP)

Paying for MCP Tools with MPP

Machine Payments Protocol (MPP) is an open protocol for paying for API calls programmatically, without a checkout UI. It is co-authored by Stripe and Tempo (opens in a new tab) and documented at Stripe's machine payments docs (opens in a new tab).

If you are building the client side — an agent that calls paid MCP tools — this guide describes what your agent actually has to do. For the server side, see Accepting MPP in your MCP server.

Stripe describes the MCP + MPP approach as experimental. The protocol is new, the tooling is young, and the package versions below move quickly.

The flow your agent has to handle

MPP is an HTTP-level handshake, not an MCP feature. From Stripe's MPP documentation (opens in a new tab):

[Agent] -- Request paid resource without payment --> [Server]
[Server] -- HTTP 402 with payment requirements --> [Agent]
[Agent] -- Retry request with payment credential --> [Server]
[Server] -- POST /v1/payment_intents to record payment --> [Stripe]
[Server] -- Return requested resource --> [Agent]

Concretely, when your agent calls a paid MCP tool:

1. ▸The tool returns a payment link (a normal HTTPS URL on the seller's server), plus instructions. It does not return a result yet.
2. ▸Your agent POSTs to that URL with no credential.
3. ▸The server replies 402 Payment Required with a payment challenge that states what is being charged and in which currency.
4. ▸Your agent obtains a payment credential from a wallet and retries the request with it.
5. ▸The server verifies the payment, fulfils the purchase, and returns the result with an MPP receipt.

The key design point: MPP never asks a human for a card number. The agent holds a credential it can present without further interaction.

What your agent needs: an agent wallet

To produce a payment credential, the agent needs a wallet. Stripe ships one as the Link agent wallet, distributed as the @stripe/link-cli (opens in a new tab) package. Its own description is the clearest summary of the idea:

Link CLI lets agents get secure, one-time-use payment credentials from a Link wallet to complete purchases on your behalf — without storing your real card details.

Those credentials are Shared Payment Tokens (SPTs) (opens in a new tab). An SPT is scoped, single-use, and does not expose your underlying card number.

Set up the Link agent wallet

npx @stripe/link-cli auth login

Stripe also publishes it as an agent skill, which is the documented way to wire it into an agent harness:

npx skills add stripe/link-cli

To connect an MCP server that charges for tools:

claude mcp add --transport http paid-catalog https://example.com/mcp

codex mcp add paid-catalog --url https://example.com/mcp

Test against a sandbox before moving real funds

Stripe's guidance is to tell the agent explicitly that the flow is a test, so the Link agent wallet issues sandbox credentials that do not charge a real payment method. Put that instruction in CLAUDE.md or your system prompt, then make sure the agent passes the --test flag when it creates a spend request.

Without that, an end-to-end test moves real money.

Paying a real endpoint by hand

You can drive the payment flow manually, which is the fastest way to confirm a seller's implementation works:

npx @stripe/link-cli mpp pay /paid \
  -X POST \
  -d '{}' \
  --context "Testing machine payments integration on Stripe MPP using the link-cli."

The stablecoin alternative

Stripe also supports MPP payments over stablecoins on the Tempo network. If your agent holds a crypto wallet rather than a Link account, it can pay a deposit address instead of presenting an SPT.

There is a hard floor on both rails, from the MPP docs (opens in a new tab):

The card minimum is a real constraint for micropayments. A per-call price below 0.50 USD is only viable on the stablecoin rail unless the seller bundles calls.

Spending controls: what actually exists

Be careful here, because a lot of third-party content about MPP is invented.

There is no MPP-standard budget environment variable. No MPP_MAX_PER_TOOL_CALL_USD, no MPP_MAX_SESSION_SPEND_USD, no MPP_REQUIRE_CONFIRMATION_ABOVE_USD, and no "Machine Wallet" object that holds a balance. POST https://api.stripe.com/v1/machine_wallets is not a Stripe endpoint — it returns 404 Unrecognized request URL.

What genuinely controls spend:

• ▸The challenge amount. Your server decides the price, and the 402 states it before your agent commits anything. Treat an unexpected amount as an error and stop.
• ▸Your own agent policy. Enforce per-call and per-session ceilings in the agent's own configuration and system prompt. There is no protocol-level enforcement you can rely on.
• ▸Credential scope. SPTs are one-time-use, so a leaked credential buys one call, not an open wallet.

That last point is the honest headline: MPP's risk model is scoped, single-use credentials, not a funded wallet with a spending cap. If you need hard budget enforcement, you need to build it in your own agent.

Verifying a seller's implementation

Stripe publishes a validator. If a seller's endpoint claims MPP support, run this against it and see what it reports on discovery, challenge format, and the full payment flow:

npx mppx@latest validate 

Run it against both a sandbox and a live version of the server. In live mode the CLI can complete roundtrip transactions with real funds, so point it somewhere you control.

Reference

• ▸MPP specification (opens in a new tab) — the open protocol
• ▸Stripe: machine payments (opens in a new tab)
• ▸Stripe: MPP (opens in a new tab)
• ▸Stripe: monetize your MCP server (opens in a new tab)
• ▸Stripe: Shared Payment Tokens (opens in a new tab)
• ▸Link agent wallet (stripe/link-cli) (opens in a new tab)
• ▸mppx on npm (opens in a new tab)