MCP Is the Wrong Abstraction and It's Going to Get Replaced in 18 Months

MCP is a beautifully designed protocol built on the wrong foundation. In eighteen months, the industry will have moved on, and the dozens of MCP server implementations being written right now will become the next generation's CORBA adapters — technically valid, commercially worthless, mourned by nobody. Here is why.

Stdio Was the Original Sin

MCP's reference transport is stdio. The model spawns a subprocess, talks to it over stdin and stdout, and the process exits when the conversation ends. It is the most natural way to get a local demo working in 30 minutes. It is also a non-starter for every production deployment that matters — your database is on a different host, your ticketing system is SaaS, your secrets are in a vault, and your observability stack needs to capture tool calls, which stdio hides.

The spec has an HTTP transport. SSE exists. But the "real" MCP — the one every tutorial, SDK, and guide defaults to — is stdio. The protocol's design center is local development. The marketing pitch is "USB-C for AI." Those two things are not the same.

JSON-RPC Is the Wrong Wire Format

MCP is built on JSON-RPC. That made sense in 2024. It makes less sense in 2026, when every frontier model can produce structured output via constrained decoding and every serious tool definition is JSON Schema. The bottleneck is no longer serialization — it is the round-trip.

JSON-RPC requires the model to produce well-formed JSON, pick the right method, include an id field, and wrap errors in a specific envelope. Each requirement is a place the model can fail silently — you get a malformed request back, not an error, and the model has to recover from a hole it does not know it dug.

The next protocol will lean on constrained structured output. Tools will be defined as schemas, calls will be schema-conformant by construction, and the protocol will be a thin envelope around the result. MCP is fighting its own transport.

The Confused Identity

The MCP spec defines three things: tools, resources, and prompts. The first is what everyone actually uses. The second is a vector database with extra steps. The third is a marketing bullet. A protocol that ships three concepts and has one in production is shipping one concept with two vestigial limbs. The successor will be tool-only — resources handled by retrieval, prompts handled by the application.

The 18-Month Bet

I am putting the marker at December 2027. By then, three things will have happened.

The stdio transport will be deprecated in practice, replaced by HTTP-first SDKs that do not carry MCP's process-model assumptions. A major lab — most likely Anthropic or Google — will ship an MCP competitor that is tool-only, schema-native, and HTTP-first. OpenAI's agent-protocol work is already moving in this direction. The MCP server ecosystem will start to consolidate as teams discover that the spec's flexibility comes at the cost of interoperability — two servers that both claim to "search" something will return incompatible shapes, and the model will be the layer that pays the bill.

The Counterargument, Briefly

The strongest counter is ecosystem. MCP has real network effects — hundreds of servers, every major lab supporting it, every tutorial written for it. That is a real moat, and it lasts as long as it takes one major customer to ship a non-MCP integration and publicly say it is faster and cleaner. The CORBA-to-REST transition took four years because the ecosystem took a while to flip. The MCP transition will be faster because the underlying model APIs are not the bottleneck — the spec is.

The Take

MCP solved a real problem with a real spec, and the people who built it deserve credit. The spec is also solving the wrong problem in the wrong way at the wrong layer. The future belongs to a thinner, tool-only, HTTP-first, schema-native protocol. Build your tool integrations for MCP today. Keep the abstraction layer thin enough to swap it out when the next protocol ships. Eighteen months. That is the bet.

— Mr. Technology