DEV Community

jamilxt
jamilxt

Posted on

MCP Is Dying as a Tool List. That Was Never Its Real Job.

#mcp #ai #llm #architecture

Two years ago, connecting an AI model to Slack or GitHub meant writing custom glue code for every pairing. Then MCP arrived, and the industry treated it like a gift. Thousands of servers launched. Conferences ran all-day tracks about it. Companies built monitoring tools for it.

Now the mood is changing. A growing group of developers says the protocol is obsolete. Their argument sounds strong: today's models can read API docs, write a Python script, and call services they have never seen before. If the model can do all that, why do we need a standard protocol that feeds it pre-defined tools?

I have followed this debate closely. My conclusion is uncomfortable for both camps: the critics are right about what MCP has become, and wrong about what it actually is.

The problem MCP solved in 2024

MCP launched in November 2024. The models of that time could chat well but could not reliably plan a multi-step API interaction. Ask one to discover an unfamiliar REST API and write correct calls against it, and it would hallucinate endpoints or invent parameters.

MCP fixed this with a simple trade. A server publishes a fixed list of tools. Each tool comes with a schema. The model picks from the list instead of inventing requests. The protocol also gave a standard home to credentials, consent, and permissions.

This worked, and adoption exploded. But the design carried a hidden cost, and the cost grew with every server people added.

The tool list collapsed under its own weight

Every MCP server contributes multiple tools, and every tool carries a schema that lives inside the model's context window. Add enough servers and a large part of your context is consumed by instructions for tools the model will never touch this session. This is the context bloat problem, and it is real.

The industry responded with an entire ecosystem around the protocol. Gateways such as Composio, MintMCP, and Pipedream now sit between agents and servers. They hold your credentials in one place and expose a small search-and-execute toolset instead of hundreds of schemas. Monitoring platforms track whether MCP servers return healthy responses.

When a protocol needs a gateway industry to stay usable, something in the design is under pressure. That is the strongest point in favor of the critics.

The models outgrew the crutch

Here is what changed since late 2024. Modern models can write and run code. Give one terminal access and it will read documentation, write a script against an unfamiliar API, fix its own errors, and compose several services in one workflow.

Cloudflare made this pattern official with Code Mode, launched in September 2025. The idea: instead of the model choosing from hundreds of rigid tool schemas, it writes a TypeScript program against typed API definitions, and that program runs in a sandbox. The tool list shrinks to one tool: run this code.

There is also a simpler shift happening in parallel. Agents discovered the command line. A model that can run --help against a well-built CLI does not need a server wrapping the same service. Most remote MCP servers, if you inspect them, turn out to be thin wrappers around public APIs that already exist.

So the case for MCP as a pile of tool descriptions is genuinely weak. Pre-defined tools now often add cost without adding capability. But ending the story there misses what protocols are for.

Why the death reports are premature

A protocol does not exist to feed the model. It exists to make two independent parties work together without custom integration. HTTP did not survive because browsers were too weak to write raw TCP. It survived because millions of clients and servers needed a shared contract.

The same logic applies here, in three places.

Sandboxed environments. Claude Desktop, IDE assistants, and most enterprise agent deployments do not hand the model a shell. In those settings, "let the agent write scripts against any API" is not a capability upgrade, it is a security downgrade. MCP gives administrators a controlled boundary: which servers exist, which tools are visible, what requires consent. "Just give it bash" removes the boundary along with the schemas.

Credentials and audit. A gateway or MCP host holds OAuth tokens in one place and logs which tool ran when. When the integration path is "the model reads the docs and improvises scripts," your secrets end up scattered through generated code, and your audit trail is whatever the model happened to print.

Independent upgrades. When a service changes its API, the server author fixes the MCP server once, and every connected agent keeps working. In the improvised-script world, every agent relying on yesterday's docs breaks in its own unique way.

Where this actually lands

The synthesis is already visible in production, and both sides of the debate can claim it.

MCP as "paste 200 tool schemas into the context window" is dying, and it should. The tool-list pattern fit models that could not plan, and better models make it pure overhead.

MCP as a discovery, authentication, and governance layer has a future. In that role, the protocol sits under the agent, not inside its context. The model writes code against a small, stable interface. The protocol handles who is allowed to do what, with which credentials, logged where. Cloudflare's Code Mode is instructive here: its marketing says "a better way to use MCP," and that is accurate. It is an evolution of the protocol, not a replacement for it.

Two smaller ideas point the same direction. Some documentation sites now serve Markdown directly when a client sends an Accept: text/markdown header. A Vercel engineer proposed a companion convention: put the preferred programming language in the Accept-Language header, so docs can return relevant SDK examples first. Tobi Lutke announced Shopify docs would support it. These are small, boring standards. They are also exactly how the web grew: common headers, negotiated content, no new protocol required.

My take

Calling MCP "a bad idea from the start" gets the history wrong. The November 2024 models genuinely could not discover and compose raw APIs reliably. A fixed tool list was a reasonable crutch for that moment. The mistake is not having used the crutch. The mistake is keeping it after the leg healed.

The likely endpoint is boring and practical. Small agents in sandboxed apps keep using MCP tool calls, because the boundary matters more than the token cost. Heavy coding agents bypass the protocol entirely and call APIs through generated code. Large deployments run both behind gateways. MCP survives not as the thing the model sees, but as the plumbing that decides what the model is allowed to reach.

Protocols rarely die when they stop being necessary. They die when they stop being useful to someone. MCP still has a customer: everyone who cannot hand a model a root shell.

Sources:

Top comments (0)