A small protocol got a big job

MCP shipped in late 2024 as a clean way for coding agents (Claude Code, then Cursor, then Codex and Replit Agent) to expose tools to an LLM. The original use case was local: read this file, run that command, query my Postgres. Filesystem-level glue.

Then someone realized you could put a remote server behind it. Then someone realized that remote server could be paid. Then someone wired x402 into the payment side. And now MCP isn't really about local tools anymore. It's about how an agent finds out what APIs exist, what they cost, and how to call them — without a human writing integration code first.

That's a discovery protocol with payment built in. Which is most of what an agent economy needs.

The shape of the shift

Three different layers used to do this job:

1. Manual integration. Human reads docs, writes a wrapper, hands the wrapper to the agent. Slow, doesn't scale. 2. OpenAI plugins. ai-plugin.json + an OpenAPI spec at a well-known URL. Worked in 2023. Mostly abandoned because it required a curated marketplace and a sign-up flow per plugin. 3. MCP. No marketplace, no sign-up. An agent's MCP client is its discovery surface. New tools show up by adding a server to your mcp.json.

What changed in 2026 is that the MCP server itself can pull a remote catalog. Our x402-deployer MCP, for instance, fetches https://agentutility.ai/registry.json at startup. Every endpoint in the portfolio becomes a tool. When we ship a new endpoint, every Claude Code instance that has the MCP installed sees the new tool on the next restart. No client update. No package bump.

That's the difference: tools used to be code you imported. Now tools are catalog entries you fetch.

The pricing-aware part

Here's where MCP and x402 fit together. When the LLM is choosing among tools, it ideally sees the price. "summarize: $0.005" is a different cost calculation from "summarize: $0.10". An agent that knows the price can pick the cheaper one, batch when it makes sense, or skip the call entirely when the budget is tight.

Until recently MCP tools didn't expose pricing in a structured field. Now they're starting to. The x402 deployer MCP returns a pricing object per tool — {currency: "USDC", amount: "0.02", chain: "base"} — and the agent can budget against it.

This sounds small. But it's the difference between an agent that calls every tool eagerly and an agent that has an opinion about spend.

What discovery still misses

Three real gaps right now:

No agent reputation. Two endpoints could have the same name and price. There's no signal yet about which one returns better answers. The closest thing is ERC-8004 attestations — third parties can attest to the quality of agentId 47167's outputs — but the data layer underneath isn't dense yet. So agents fall back on heuristics like "I called this last week and it worked".

No standard for endpoint health. Is the endpoint up? Is the underlying upstream rate-limited? Is the price about to change? An agent calling 30 APIs needs to know. The MCP spec is silent on this. We expose a /health per endpoint and a portfolio-wide status page, but it's not standardized across providers.

No common schema for capabilities. What does "summarize" mean? Plain summary or extractive? Bullet points or paragraph? Right now every endpoint defines its own input schema. An agent needs to read all of them, or it has to lean on the LLM to infer. We've started using schema.org Service + ConsumeAction in JSON-LD on every endpoint page so search-grade crawlers can pick up the shape, but that's a side-channel, not part of MCP itself.

What to do about it

If you're building an MCP server, three concrete moves that help the discovery layer mature:

  • Expose per-tool pricing in a structured field even if your tools are free today. Set price: "0". Let agents budget normally.
  • Cache your catalog at startup but refresh on a TTL. Don't make new tools wait for a restart.
  • Return a stable tool_id per capability so an agent that learned "this tool works" can find it again across server restarts.

And if you're an agent author: stop treating MCP as a static config. Read the catalog at runtime. Re-rank tools based on price + success rate per tool. The catalog is data, not configuration.

The protocol is the easy part. The catalog economics are where the next year of work is.