What MCP used to be

When Anthropic shipped Model Context Protocol in November 2024, the canonical setup was a JSON config in ~/Library/Application Support/Claude/ and a Python or Node process spawned over stdio. The protocol was just list_tools/call_tool round trips. Local. Single-user.

That was fine for filesystem access and a database query or two. Pretty quickly it stopped being enough.

What it is now

By mid-2025 the spec had grown HTTP transport plus OAuth flows. Streamable responses came shortly after. Remote MCP servers became normal. You point Claude or Cursor at https://mcp.someservice.com, do an OAuth dance once, and that service's tools show up alongside your local ones. Same protocol, no install.

And once you can host an MCP server on the public internet, the obvious move is to put a catalog behind it. Tens or hundreds of tools, paginated.

Catalog-first servers

A catalog-first MCP server fronts a directory. The MCP tools/list call doesn't return five hand-written tool definitions, it returns whatever's in the underlying registry, often with pagination because the count gets silly. Smithery hosts thousands. MCP.run does the same. Coinbase's x402 directory exposes an MCP face that lets an agent see every paid endpoint in the Bazaar without leaving the chat.

Here's what a tools/list response from a catalog server actually looks like, trimmed: 

{
  "tools": [
    {
      "name": "weather_forecast",
      "description": "7-day forecast for a coordinate. $0.001/call via x402.",
      "inputSchema": { "type": "object", "properties": { ... } }
    },
    {
      "name": "satellite_tile",
      "description": "Sentinel-2 RGB tile at zoom 8-14. $0.005/call via x402.",
      "inputSchema": { ... }
    }
  ],
  "nextCursor": "eyJwYWdlIjogMn0="
}

The agent sees price, schema, one-line purpose. It picks. It calls. If the call returns HTTP 402 with a payment requirement, the MCP client either auto-pays from a hot wallet or pops a confirmation. The whole loop runs without a human reading docs.

What changes for providers

If you sell agent-facing APIs, you're shipping catalog rows now. The old unit was a REST endpoint with a docs site. The catalog row needs a price an agent can budget against and a schema strict enough that a model can fill it on the first try. Plus a description that reads like a tool, not a marketing page.

The cost of getting any of those wrong is silent. Agents don't file bug reports. They just don't call you.

So thin wrappers around existing APIs aren't dead weight. A 30-line worker that takes a $0.002 x402 payment and forwards to an upstream API you're already paying flat-rate for is genuinely useful if the upstream doesn't speak MCP or x402. The wrapper earns the catalog slot.

What changes for agents

Agents stop hard-coding integrations. The pattern that's settling in: connect to two catalog servers at session start, cache the tool list, route by description match plus price. Cheaper providers get tried first. Failed calls demote the provider in the local ranking. Nobody wrote a Yelp for APIs, the agent's call history is the Yelp.

A side effect is that any catalog with bad data poisons itself. If half the tools have wrong schemas or stale prices, agents downrank the whole server, not just the broken entries. So curation matters, and the catalogs that win are the ones that drift-check their listings against live endpoints.

Where this goes

The interesting frontier is cross-catalog federation. An MCP client today connects to N servers and unions their tools. Nothing stops a meta-catalog from aggregating other catalogs and exposing the merged set as one MCP server, with payment routing already wired through x402's settlement layer. That collapses discovery for the agent down to one connection, and turns provider competition into pure price plus schema quality.

If you're building an endpoint today, list it in every catalog that'll take it. The ones that get traction will be obvious within a quarter.