Tempo, x402, and the MCP Commerce Stack

Category clarity for buyers deciding where the protocol ends and the product stack begins.

Published March 21, 2026 — temporal.rest

The infrastructure for autonomous agent commerce has, as of March 2026, crystallized into a layered stack where three protocols address three distinct problems. The Model Context Protocol (MCP) governs how AI agents discover and invoke tools. The x402 protocol standardizes how an HTTP request can trigger, verify, and settle a payment. Tempo and the Machine Payments Protocol (MPP) provide the settlement rail and the operator-facing controls that give enterprises confidence their agents are spending within policy.

The strongest market signal is not that one of these standards is winning. It is that they compose. Paid MCP servers running x402-gated endpoints over Tempo settlement are already live in production. For buyers evaluating the landscape, the critical question is therefore not which protocol to bet on but which layer each protocol owns, where the seams are, and what decisions remain at the product level.

This report maps those layers, documents how they interlock, and offers decision guidance for teams building or buying agent-commerce infrastructure.

Layer 1: MCP — The Tool and Context Interface

The Model Context Protocol, introduced by Anthropic in November 2024 and refined through its June 2025 specification update, standardizes how large language models connect to external data sources, tools, and capabilities. It uses JSON-RPC 2.0 messages carried over a stateful session, and its architecture revolves around three building blocks that servers expose to clients:

• Resources — passive, read-only data such as file contents, database schemas, or API responses, each identified by a unique URI (spec).
• Tools — executable operations with typed inputs and outputs validated via JSON Schema, allowing models to discover and invoke them automatically based on context.
• Prompts — reusable template patterns that let server authors showcase best practices for using their services (server concepts).

Crucially, MCP deliberately excludes commerce semantics. The protocol can expose a tool that returns a price, but it provides no standardized way for that tool to charge for its use or for the calling agent to pay for execution. The June 2025 authorization update added OAuth 2.1-based access controls and Protected Resource Metadata discovery, but these authenticate who can access tools — they do not coordinate payment for tool use.

This boundary is strategic. MCP solves the connectivity problem — secure, structured access to capabilities once discovered — and leaves payment to protocols designed for exactly that purpose. By March 2026, MCP adoption has expanded well beyond Claude: the Vercel AI SDK supports MCP clients, and platforms including Shopify and Stripe have begun offering MCP integration points. Every one of these integrations still requires a separate payment mechanism, confirming MCP's role as the tool-interface layer rather than a commerce layer.

What MCP does not do. MCP provides no mechanism for an agent to discover that an MCP server exists in the first place (discovery at web scale), no way to embed pricing information in tool metadata, and no settlement or receipt semantics. These are gaps by design, not oversights.

Layer 2: x402 — The Paid-HTTP Handshake

Where MCP standardizes how to call a tool, x402 standardizes how to pay for a resource within an HTTP request. Developed by Coinbase and published as an open specification, x402 revives the long-dormant HTTP 402 "Payment Required" status code and turns it into a machine-actionable payment flow:

1. The buyer (agent or client) requests a resource.
2. The server responds with HTTP 402 plus a JSON body describing the payment requirement — amount, asset (typically USDC), recipient address, and a validity window.
3. The buyer's wallet constructs a one-time signed payment authorization using EIP-3009 ("Transfer With Authorization"), avoiding the need for a separate on-chain gas transaction.
4. The buyer retries the request with the payment proof in an HTTP header.
5. A facilitator — an independent verification and settlement service operated by Coinbase or others — validates the signature, confirms the amount, submits the transaction to the blockchain, and signals the server to release the resource.

The result is a stateless, per-request payment handshake that requires no API keys, billing accounts, or prior customer relationship. It is purpose-built for machine-to-machine microtransactions and API monetization.

x402 also introduced Bazaar, a discovery layer that lets buyers query a registry of x402-protected endpoints. Bazaar addresses one of MCP's explicit non-goals — finding services at web scale — but only for services that use the x402 payment model.

What x402 does not do. x402 stops at the handshake. It does not manage sessions, budget caps, multi-step workflows, operator-level spend controls, or fiat settlement. It also does not prescribe a specific blockchain — though in practice nearly all production x402 deployments as of March 2026 settle on Base using USDC.

Layer 3: Tempo and MPP — Settlement, Sessions, and Operator Controls

Tempo Mainnet launched on March 18, 2026, alongside the Machine Payments Protocol (MPP), co-developed with Stripe. Tempo is purpose-built payments infrastructure: instant settlement, predictable low fees, high throughput, and global availability. MPP sits atop this infrastructure and extends the machine-payments thesis in several important directions.

According to the Privy integration guide and the Alchemy comparison, the key architectural differences between MPP and x402 include:

• Payment-method breadth. MPP supports multiple payment methods rather than being limited to on-chain stablecoins.
• Sessions. Where x402 is stateless and per-request, MPP introduces a session model that lets an agent open a payment session, execute multiple paid requests within it, and close the session with a single settlement event. This reduces transaction overhead for multi-step agent workflows.
• Spend controls and operator policy. MPP defines operator-facing primitives — budget ceilings, per-session caps, approval gates — that let the human or organization behind an agent govern how much it can spend and on what.

Critically, Tempo and MPP explicitly build on the same foundation as x402. Both use HTTP 402 to signal that a request requires payment. Both enable programmatic, request-based payments within standard HTTP flows. MPP extends this model rather than replacing it. One developer reported going live with both x402 and MPP on launch day without breaking existing x402 integrations — evidence that the protocols compose rather than conflict.

What Tempo and MPP do not do. Neither protocol defines how an agent discovers tools or negotiates capability metadata. That remains MCP's domain. And while MPP's session model adds statefulness, it does not attempt to replace MCP's structured tool-invocation semantics.

The Composition Pattern: x402-Aware MCP Servers

The most important architecture emerging in production as of March 2026 is the x402-aware MCP server — a pattern that wires all three layers together without collapsing them.

Coinbase's official documentation provides a reference integration showing how to run an MCP server whose tools are gated behind x402 payment requirements. Vercel's x402-mcp library packages this further, letting any MCP server declare tool prices and accept x402 payments within the Vercel AI SDK.

The flow works as follows:

1. An agent connects to an MCP server and discovers available tools via standard MCP capability negotiation.
2. The agent invokes a tool — say, "premium-search."
3. The MCP server proxies the request to an x402-protected HTTP endpoint.
4. The endpoint returns a 402 with payment requirements.
5. The agent's wallet (configured via an environment variable or key-management service like Privy) constructs a signed payment authorization.
6. The request is retried with the payment header; the facilitator settles the payment; the tool returns its result to the agent.

Community implementations such as the spot-402-mcp-server on LobeHub and tutorials like Monetizing MCP Servers with x402 confirm this pattern is reproducible across frameworks.

When Tempo and MPP are added to this stack, the settlement layer gains sessions and operator controls. An enterprise deploying agents can configure budget policies at the Tempo layer while the MCP interface and x402 handshake remain unchanged at the tool and payment layers.

Comparison Table

Decision Guidance for Buyers

Step 1: Start with the tool interface

If your agents need to discover and invoke third-party tools, MCP is the connectivity standard to adopt. It is vendor-neutral, multi-platform, and supported by major LLM providers. Evaluate MCP server frameworks (Vercel AI SDK, Cloudflare Workers, MCP-Go) based on your runtime environment.

Step 2: Add the payment trigger

If any of those tools should be paid per-request — and the service provider uses or plans to use HTTP 402-based gating — adopt x402 client support. This is a lightweight addition: an x402-aware HTTP client or MCP wrapper intercepts 402 responses, constructs payment proofs, and retries. The Coinbase x402 SDK and community wrappers make this a single dependency addition.

Step 3: Evaluate settlement and operator controls

For organizations that need session-based billing, budget governance, fiat settlement options, or compliance-friendly audit trails, Tempo and MPP add the operator layer. The decision between x402-only and MPP depends on:

• Transaction volume. If agents make many small requests within a workflow, MPP's session model reduces per-request overhead.
• Payment-method requirements. If buyers or sellers need fiat settlement (via Stripe), MPP supports this natively; x402 alone does not.
• Spend governance. If a finance team needs to cap agent spending per day, per session, or per vendor, MPP's operator controls are purpose-built for this. x402 has no equivalent.
• Chain flexibility. As of March 21, 2026, x402 production deployments overwhelmingly settle on Base. Tempo settles on its own mainnet. Evaluate based on your treasury and compliance posture.

When to use both

The strongest evidence from production deployments is that x402 and MPP are not either/or. MPP is designed to layer atop x402 infrastructure. Teams that adopted x402 early can add MPP without rewriting their payment integration. The launch-day dual-deployment report confirms backward compatibility.

Caveats and Open Questions

• MCP payment semantics remain undefined. As of March 21, 2026, the MCP specification includes no native pricing, payment, or receipt primitives. x402-MCP bridges exist as community and vendor integrations (Coinbase, Vercel, LobeHub), not as part of the MCP standard itself. Whether a future MCP revision will standardize payment metadata is an open question.
• MPP is still at launch-stage maturity. Tempo Mainnet and MPP launched on March 18, 2026. That means the protocol direction is now public and credible, but long-term interoperability, tooling quality, and production depth still need more time in market than x402's earlier request-handshake model.
• Discovery remains fragmented. MCP discovers capabilities only after a server is known. Bazaar discovers payable x402 endpoints. Tempo and MPP maintain their own service surfaces. Buyers should expect to assemble discovery, invocation, and payment policy as separate product concerns for now.
• Settlement remains a product choice, not a protocol inevitability. As of March 21, 2026, x402 is strongly associated with Base and USDC in production, while MPP is strongly associated with Tempo and Stripe-backed multi-method flows. That may change over time, but teams making platform bets today still need an explicit treasury, compliance, and latency view.

Bottom Line

The right way to think about this market is not as a protocol horse race.

• Use MCP to let agents discover and invoke tools in a structured, cross-platform way.
• Use x402 when you need a clean, stateless HTTP-native payment handshake for paid resources.
• Use Tempo and MPP when you need a settlement rail plus operator controls, sessions, and broader payment-method flexibility for agent commerce.

The buyer error is to collapse those layers into one category because they show up in the same demo. The market reality, as of March 21, 2026, is that they are becoming more complementary, not less. Teams that understand that layering can adopt each part of the stack on its own merits, swap pieces without rewriting the full system, and package the result into a product that humans and agents can actually trust.