The agent-commerce stack in 2026: a builder’s honest map of x402, MCP, and Coinbase Bazaar

If you are building something agent-callable and monetised in 2026, you are navigating a stack that did not fully exist eighteen months ago. The components are real, the protocols work, and the tooling has improved significantly. But the ecosystem is also ahead of the demand in ways that matter if you are trying to understand where you actually stand.

This is not a survey post written from documentation. We built an agent-callable service that exposes tools via MCP, charges per call in USDC on Base using x402, runs settlement through the Coinbase CDP facilitator, and is listed on MCP registries. Revenue to date: $0. The infrastructure works. The demand is early. Both things can be true and are worth understanding separately.

Layer 1: MCP — how agents discover and call tools

The Model Context Protocol is a standard for how AI agents discover and invoke external tools. Think of it as a shared language: a client (Claude, GPT, an autonomous agent) connects to an MCP server, calls tools/list to see what is available, and then calls tools/call to invoke a specific operation. The server responds with structured JSON.

Before MCP, every agent framework had its own integration format. You would write an OpenAI function definition, a separate Anthropic tool_use schema, maybe a LangChain wrapper. MCP standardises the discovery and invocation layer so you write one server and it works across clients that speak the protocol.

The transport options are: stdio (for local tools, desktop apps), SSE, and Streamable HTTP. For anything you want to run as a remote service — something agents can call over the internet — Streamable HTTP is the right choice. It is a regular HTTPS endpoint that handles JSON-RPC requests, which means it lives behind a normal CDN, scales normally, and needs no persistent connection.

The MCP ecosystem has grown fast. There are over 5,800 servers registered across various registries. The official registry at registry.modelcontextprotocol.io is the canonical one, with Smithery as the most useful third-party directory for discovery and health checks. Claude Desktop, Cursor, and a growing set of agent frameworks support MCP natively.

One real gotcha worth knowing: token overhead. A verbose MCP server with detailed schemas can easily consume 50,000 tokens per session just for the tools/list response. Trim your tool descriptions to what the model actually needs to make a calling decision. Longer is not better.

Layer 2: x402 — how agents pay per call

x402 is a protocol for HTTP micropayments. The mechanic is simple: a server returns HTTP 402 Payment Required with a structured body describing what payment it accepts (token, amount, chain, recipient address). The client — an agent with a wallet — signs a payment, attaches it as a request header, and retries. The server verifies and proceeds.

In practice, the stack looks like this: USDC on Base (Coinbase’s L2), EIP-3009 authorization signatures, and the Coinbase CDP facilitator as the verification and settlement layer. The x402 Foundation launched in September 2025 with Coinbase, Anthropic, Cloudflare, AWS, Google, Visa, Circle, and Vercel as founding members. By February 2026 the ecosystem had processed 161 million transactions and $43 million in settled volume. These are real numbers from real services, not just our small slice of it.

What x402 gets right is the agent-native payment model. Agents do not have credit cards or OAuth tokens. They have wallets. x402 makes a tool callable by any agent with USDC on Base, with zero signup friction. The server does not need to know who the agent is — payment is the credential.

The implementation is straightforward: a middleware wrapper that intercepts requests, issues the 402 challenge, verifies the signed payment against the chain, and then hands off to your handler. The x402-express and x402-fastapi SDKs reduce this to roughly ten lines of middleware code.

The CDP facilitator

You have two options for verifying x402 payments: verify directly on-chain yourself (Base RPC, check the transaction hash), or route through the Coinbase CDP facilitator at api.cdp.coinbase.com/platform/v2/x402.

The facilitator is the right choice for services that want to be discoverable. It handles verification and finalises settlement on-chain. More importantly, it is the gateway to Coinbase Bazaar. If you self-verify, you bypass the facilitator, which means Bazaar never sees a settlement event from your endpoint and never indexes you.

The facilitator requires a Coinbase CDP API key (free at portal.cdp.coinbase.com). The tradeoff is an external dependency in your payment path, but the settlement guarantee and the discovery benefit are worth it for most services.

Layer 3: Coinbase Bazaar / agentic.market — the discovery directory

agentic.market (Coinbase’s Bazaar directory) is a searchable index of agent-callable services that accept x402 payments. The intent is for agents to look up services here, find what they need, and immediately call and pay.

Here is the important thing to understand about how you get listed: there is no form to fill out. Bazaar indexes a service automatically after a payment settles through the CDP facilitator, provided your x402 response metadata includes discoverable: true via the @x402/extensions/bazaar npm package. The listing is triggered by a real settled transaction, not by a registration step.

This is architecturally elegant and practically brutal for early-stage services. If no agent has paid through your CDP-backed endpoint yet — because you are new, because discovery is still bootstrapping, because your service had no real supply until last week — you are not listed. The directory accurately reflects services with real transactional history. The chicken-and-egg problem is real.

Layer 4: AWS Bedrock AgentCore Payments — the May 2026 tailwind

In May 2026, AWS launched Bedrock AgentCore Payments in Preview. The specific thing that matters for x402 service builders: Bedrock agents now have managed built-in wallets and native x402 payment support. An agent built on Bedrock can call an x402-gated endpoint and pay without the developer writing any wallet management code.

Visa TAP and Stripe have also added x402 support. The protocol is becoming infrastructure, not an experiment.

Why this matters if you are building an x402-compatible service today: the number of agents that can natively pay via x402 is about to increase. The demand side is catching up to the supply side. Building your service correctly now — CDP-facilitated settlement, discoverable: true, clean tool schemas — positions you for that agent traffic rather than requiring a refactor later.

How the layers actually fit together

MCP handles discoverability for the tool-invocation layer. Bazaar handles discoverability for the payment-capable services layer. They are complementary. A well-built service should appear in both.

What is real vs. what is hype (honest assessment)

The protocol works. x402 payment challenges, EIP-3009 signatures, Base settlement — these are not draft specs. The x402 SDK handles the mechanics cleanly, and the Coinbase CDP facilitator is reliable. If you implement it correctly, payment flows work.

The tooling has improved. A year ago, building an x402-gated MCP server was a research project. Today there are SDKs, reference implementations, registry crawlers, and enough documented examples that a competent developer can ship in days. The Linux Foundation backing of MCP means the protocol is not going away.

Agent-to-agent commerce is genuinely early. The aggregate ecosystem numbers (161 million transactions through February 2026) are dominated by established services. For a small, newly-launched service, zero paid calls in the first weeks is not a failure — it is the expected early-adopter state. The demand is building, not absent. But “the infrastructure exists” and “agents are actively looking for your specific service” are different claims.

The supply side is demo-heavy. A meaningful fraction of services on registries today are demos, stubs, or toy implementations. This degrades registry signal quality as a discovery mechanism. If your service actually does something useful, being demonstrably real and reliable matters more than it might seem.

0 paid calls is common. We have had 126 organic probe requests to our service and zero completed payments. Three paid-tool attempts, zero settled. This is not a sign the protocol is broken — it reflects that most agent traffic right now is crawlers, testers, and framework probers, not agents with funded wallets executing real tasks. That ratio will shift.

The gotchas we actually hit

These are specific mistakes that cost real time. Worth knowing before you hit them yourself.

The dual gate problem

We had two separate x402 implementations running simultaneously: a hand-rolled verifier in our Cloudflare Worker edge layer, and the standard CDP-backed gate on our Python origin. Each worked correctly in isolation. If both were active at the same time, an agent would have received two separate 402 challenges and would either pay twice or break the flow entirely.

The fix is architectural: choose one gate. Disable the edge gate entirely (do not set X402_RECEIVER_ADDRESS as a Cloudflare Worker secret), let all tools/call requests proxy to the origin, and use only the CDP-backed gate. One settlement path, one on-chain record.

Charging before state changes

The x402 gate settles payment before calling the tool handler — verify the payment, then do the work. The trap is when your handler returns a non-error status for work that has not actually happened yet.

We had a schedule_appointment handler that returned pending_async when the booking was dispatched to a background worker. The payment gate’s failure-status check did not include "pending_async", so settlement ran immediately. The worker would run later — or not, silently. The agent paid for a promise.

The correct principle: settle only on confirmed real-world state change. If confirmation requires an async callback, defer settlement to that callback. x402 settlements on Base are final, and agents have no way to distinguish a tool-claimed success from a real one.

Demo supply that looks billable

Our service directory was seeded with demo businesses. The documentation and the find_business response told agents that demo entries would short-circuit with a no-charge receipt. The short-circuit guard did not exist in the paid handler code. An agent trusting the documented contract would have paid for a dictionary lookup.

Covered in depth in our previous post. The principle generalises: if your service has any concept of demo or sandbox data, make the no-charge guard load-bearing at the handler level, not in documentation.

Bazaar listing requires CDP, not just x402

We initially self-verified payments on-chain (checking transaction hashes via Base RPC) rather than routing through the CDP facilitator. The payments would have settled correctly, but Bazaar would never have indexed us — Bazaar’s automatic indexing is triggered by CDP facilitator settlement events, not by arbitrary on-chain transactions.

If Bazaar discovery matters to you, route through CDP from day one. Switching from self-verification to CDP-facilitated settlement is about two hours of work. Do it before you launch, not after.

Registry listings alone do not drive paid traffic

We are live on the official MCP registry (v1.0.2, active) and listed on Smithery. This is good for baseline discoverability. It has not produced paying calls. Registry listings surface you to developers exploring the ecosystem and to crawlers mapping the tool landscape. They are not yet a reliable channel for funded agents executing real tasks.

This is the honest state of 2026. The discovery infrastructure is further ahead than agent deployment infrastructure. Build the right foundations now; expect demand on a months timescale, not days.

What we would tell a builder entering this space today

Build something that does a genuinely useful thing. The agent-commerce stack lowers the cost of adding payment to a tool dramatically, but it does not create demand for tools that do not solve real problems. The most credible signal we have from actual users is a request for reliable appointment booking with constraint negotiation and a verifiable receipt — not another “AI-powered API wrapper.” Useful beats clever.

Use the CDP facilitator from day one. The Bazaar auto-listing is free infrastructure that requires only that you route settlements through it. Retrofitting later costs more than doing it first.

Audit your payment path end-to-end before enabling settlement. Read the call chain from tool invocation through payment gate through handler and back. Check every status code your handlers can return and confirm that the gate treats pending, async, and demo states correctly.

Keep tool schemas lean and honest. Verbose descriptions bloat agent context windows without improving calling accuracy. Write descriptions that answer “when should I call this tool” in one sentence. If your tools/list response exceeds 10,000 tokens, trim it.

Expect zero paid calls for longer than feels comfortable. This is normal. Most traffic today is exploratory. Build the infrastructure correctly, seed real supply if your service has a supply side, and let the demand find you.

What we built on it

AgentBroker is our service in this space: an agent-callable broker exposing 14 MCP tools for finding, messaging, and booking small businesses that have no API. Reads are free; writes are priced in USDC via x402 on Base. The edge layer is a Cloudflare Worker; the origin is a FastAPI service on Render. We are live on the official MCP registry and Smithery, using the CDP facilitator for settlement, with Bazaar listing pending a first paid call through the facilitator.

126 organic probe requests. Zero completed payments. The x402 fix branch is code-complete with regression tests and awaiting deploy. We are seeding real booking URLs into the directory this week. Revenue is $0.

We are sharing the build because the gap between “the infrastructure works” and “there is demand for your specific thing” is genuinely useful information for anyone considering this stack. The former is true. The latter takes longer than you expect.