The MCP ecosystem's missing layer is the gateway

The Model Context Protocol solved a genuinely hard problem: how an agent describes and invokes tools in a uniform way. Every major agent — Claude, Cursor, Cline, Codex — now speaks MCP, and the protocol has won.

But look at how the ecosystem is growing, and there's a pattern worth noticing.

The default way to connect an agent to a real system is to write an MCP server. There are thousands of them now — one per API, one per SaaS product, one per internal service. That's fine when you're a SaaS vendor with the engineering capacity to build and maintain a server, plus a registry listing, docs, and an auth story.

But most of the systems agents actually need to reach are not MCP servers. They're plain HTTP APIs: internal tools, partner APIs, legacy services, homegrown microservices. For those, "write an MCP server" is the wrong answer. You're not building a product around the tool — you just want the agent to be able to call it.

The gateway layer

What's missing is a layer between an arbitrary HTTP API and an agent's tool set: a gateway that maps HTTP endpoints to MCP tools without you hand-writing a server.

The properties that matter:

• Declarative, not code. You describe the endpoint; the gateway generates tools/list and handles tools/call. No per-API server to build or maintain.
• One endpoint, N tools. An agent shouldn't need ten MCP server URLs to use ten services. A gateway aggregates them behind a single streamable-HTTP endpoint — the client configures one URL and gets the whole tool surface.
• Auth at one choke point. Downstream systems keep their own auth; the gateway holds the credentials and does the exchange, so the agent never sees a raw API key.

This is the same story the API-gateway layer already told in the REST world — Kong, Apigee, Envoy — just replayed one level up for agents.

Why it matters now

Two things are converging. First, the number of agent clients keeps growing, each with its own way of registering MCP servers, which makes "configure once, distribute everywhere" more valuable, not less. Second, agents are starting to call other agents' tools — and when they do, someone has to mediate that traffic: identity, metering, and eventually payment.

That's the machine-economy bet: the gateway is where agent-to-agent tool calls get brokered.

Where we landed

We built this as JiZhiMCP — an agent-first MCP gateway that hosts any HTTP API as MCP tools behind one streamable-HTTP endpoint. One endpoint, N services, auth handled once upstream. It's live on the official MCP Registry (installable from any agent client that reads it) and open on GitHub: https://github.com/alanwang100/jizhineng-mcp

The gateway layer is the part of the MCP stack that's still up for grabs. Curious what other people building in this space are seeing — are you still writing servers by hand, or has the gateway pattern started showing up in your stack?