Evan X. Merz

For the past few years, I have worked in artificial intelligence at big tech. In that role I have had the good fortune to work on the bleeding edge of AI tech, but I never had the opportunity to dig into the emerging hype around Model Context Protocol (MCP).

MCP is a way for LLMs to interact with data sources. The model is the AI/LLM that is doing the reasoning. The context is the data source that provides information necessary for the problem. The protocol is a way to connect them.

The problem is that there is one crucially bad design decision in the MCP specification, and one blank spot in the MCP spec. Both of these reveal that the MCP spec was probably created by AI.

Problem 1: MCP clients are tightly coupled to MCP servers in an unscalable way

Here's the example given by Anthropic of how the MCP client works.

If an AI-enabled application wants to use multiple MCP servers (multiple data sources), then it has to have a separate client application for every MCP server. If you need a custom client integration for every MCP server, then what is the value of the specification at all?

MCP claims that it works on a "client server architecture", so to better understand why this is probably AI slop, let's analogize to the client server architecture that everyone understands, the web. When browsing the web, the web browser is the client and the website is served by a web server. They communicate using tightly defined protocols. It's a very clear relationship.

But the MCP spec states that every single MCP server must have its own MCP client that sits like a babel fish in between the MCP server and the AI model. In the case of the web this would be like if you had to install a separate app for every single website you visited. So if you wanted to go to Amazon.com, not only would you need a web browser, but you would also need the Amazon app.

This is bad design because it creates several problems that should be obvious to anyone closely involved with the spec.

1. This breaks the typical client server pattern because you need numerous clients to use numerous data sources. If a human had designed this, they would have asked, "why not put the work of the client application into the MCP server?"
2. This is entirely unscalable. If you want your AI to connect with an arbitrary number of data sources, then you will now need an arbitrary number of MCP clients, which each require their own infrastructure, development, and maintenance.

Problem 2: MCP clients are tightly coupled to models in an unscalable way

The MCP spec doesn't specify how to trigger tools/actions based on the output of an LLM. In other words, there is nothing in the spec that says what the LLM must say in order to tell the client to fetch data from the MCP server.

This leaves each client to do things a little bit differently, and it means that each client is going to be developed based on however their favored model works. A trigger mechanism that works for one client/model combination might not work as well for another client/model combo.

This is a massive blank spot in the MCP spec, and is, arguably, the most difficult part of this problem. The spec makes it clear that MCP client to MCP server communication is via JSON-RPC, but it leaves out how the LLM to MCP client communication is supposed to occur.

This creates several problems.

1. The MCP client does ALL the heavy lifting. This shifts the burden from the MCP server, which is basically a passive data source, to the MCP client, which has to magically handle all the communication between the MCP server and the LLM.
2. The heavy MCP client removes any benefits over RAG. One of the supposed benefits of MCP over RAG is that it's more generalizable, but once you dig in and discover the heavy MCP client, you can see that that isn't true.
3. The MCP client tool trigger can lead to massive inefficiency. Most MCP clients are defaulting to triggering tools based on keywords in the LLM response, which is going to lead to wasteful overuse of MCP servers.

All of these problems mean that the MCP client is going to be very heavy, and you are going to need several of them, each with complex "business logic" relating to both the LLM and the MCP server.

The MCP specification is AI slop because it doesn't deal with the hard problems

To put it bluntly, the MCP spec is worthless as long as this tightly coupled heavy client exists in the spec. If you have to create a separate client for every single MCP server, then it isn't truly a client-server architecture. It just puts the burden on the AI host applications to do the custom coding to integrate each data source. And if each client can trigger tools in a different way, then what is the spec actually specifying? That we should use JSON-RPC for client server communication? Is that it?

The MCP spec looks like something useful, but when you dig into it, it leaves hard problems unsolved in a way that makes it look like AI slop.

I wanted to finish this post by describing what we could do to fix the MCP spec, but I'm not sure that I can solve that problem in a blog post.

I'm sure the MCP spec can, and will, be clarified in future specifications, but as of August 2026, it just isn't very useful.