This came up in Chinese AI dev circles recently: a breakdown of MCP that ended with the blunt warning "stop mythologizing MCP." The post got traction not because it was cheerleading, but because it called out a real failure mode practitioners keep running into. That failure mode is worth naming precisely, because if you have already shipped an MCP server and hit it, you probably blamed yourself before you blamed the protocol.
Here is the failure: you wire up 15 tools to your MCP server, the host queries the tool list, the model gets a context window stuffed with tool schemas, and your effective token budget for actual user content drops by 30-40% before the conversation even starts. You did not misconfigure anything. You followed the spec. The cost is real and it compounds per turn.
What MCP Actually Is and Is Not
MCP, Model Context Protocol, is a standardized client-server protocol that sits between an LLM host (Claude Desktop, Cursor, Cline inside VSCode, etc.) and the external tools or data sources that host needs to reach. Anthropic published it to solve a genuine problem: before MCP, every "model plus tools" integration was a bespoke snowflake. You had OpenAI Function Calling with one JSON schema convention, Anthropic tool use with a slightly different one, and every third-party API with its own data shapes. Developers were writing glue code for every combination of model and tool, and that glue code was not portable.
MCP introduces a Host-Client-Server architecture. The Host is the application the user is running. The Client lives inside the Host and handles the protocol mechanics. The Server is the process that actually owns the tools and exposes them. The protocol defines message formats, request-response structure, and how tools register themselves. That is the whole thing. It is a connectivity standard, not a reasoning layer.
This distinction matters and practitioners in that thread were sharp about it: MCP does not do task planning. It does not do intelligent routing. It does not decide which tool to call. The LLM still does all of that, which means MCP inherits every weakness of the model it is attached to. If the model reasons poorly about tool selection, MCP makes that problem more reproducible but does not fix it.
One commenter in the original thread pointed out a common architectural confusion worth repeating: the Client is not an independent middle layer between the Agent and the tools. The Client is an internal component of the Host. The actual communication boundary is between Client and Server together as a pair, not between the Agent on one side and the Client as a standalone mediator on the other. Getting this wrong leads to designs where developers treat the Client as a place to put business logic, which it is not built for.
The Four Problems That Actually Bite You in Production
The original post listed four problems with MCP. They are not equally sharp, so let me rank them by how much they have actually cost teams shipping real agents.
Tool call overhead at scale. This is the one that hurts first. Every registered tool contributes its schema to the context on every turn, depending on host implementation. If your MCP server registers 20 tools and each schema averages 200 tokens, you are spending 4,000 tokens per turn on tool declarations before the model has seen any user input. At GPT-4o pricing that is not nothing across thousands of sessions. The fix is scope control: register only the tools relevant to the current task context, which requires either dynamic tool registration (not universally supported by hosts yet) or separate MCP servers scoped to specific workflows. Neither is free to implement.
Security surface on the server side. MCP servers execute real operations. A poorly sandboxed MCP server that exposes filesystem tools, shell access, or database writes is a straightforward attack surface if the prompt injection risk in the host is not managed. This is not unique to MCP, but the standardization of the protocol means that a compromised MCP server pattern is now more portable. The threat model for your server needs to assume adversarial inputs through the LLM layer, not just through normal API callers.
Cloud and distributed deployment friction. The reference implementations lean heavily toward local process communication. Running MCP servers in a distributed cloud environment, where the Host and Server are not on the same machine, requires either HTTP+SSE transport (which is supported but less mature in tooling) or building your own bridging layer. Teams that tried to lift a local MCP setup into a Kubernetes cluster without planning for this got surprised by latency and connection management complexity that the local setup had hidden.
Reasoning dependency. MCP exposes tools. It cannot make the model use them correctly. A model that hallucinates tool arguments, calls tools in the wrong sequence, or ignores tool output still does all of those things through MCP, just through a standardized channel. If you are evaluating MCP as a solution to flaky agent behavior, it is the wrong diagnosis. The protocol is not the problem in that case.
Why the USB-C Analogy Is Both Right and Dangerous
The "USB-C for LLMs" framing that circulates in these posts is accurate for one thing: interoperability. An MCP server you write today should work with any MCP-compliant host. That is genuinely useful. The ecosystem of pre-built MCP servers is growing fast enough that you can often grab a maintained server for Postgres, GitHub, or Slack rather than writing your own.
Where the analogy misleads is in implying that the connection is the hard part. With USB-C, if the cable fits, data flows. With MCP, a conformant connection to a capable tool still leaves you with a model that has to plan, sequence, and interpret correctly across multiple turns. The protocol handles the plumbing. The plumbing being clean does not make the rest of the agent reliable.
The teams getting the most out of MCP right now are the ones treating it as infrastructure to be kept boring: minimal tool registration per context, explicit scope boundaries on each server, server-side input validation that does not trust the model's argument formatting, and separate evaluation pipelines for tool selection quality that run independent of whether MCP itself is functioning. The protocol disappears into the background when it is working. The reasoning and planning problems are still front and center.
What This Means If You Are Building an MCP Server Today
On the server side specifically: design your tool surface area before you design your implementation. Every tool you register has a token cost on the client side even if it is never called. Group tools into servers by task domain, not by convenience of implementation. If you are building for a host that supports dynamic tool exposure, use it.
On the client/host side: if you control the host, implement lazy tool loading or tool relevance filtering before you hit the context limit wall. This is not in the base protocol, it is your responsibility as the host implementer.
On the reasoning dependency: build evals that specifically test tool selection accuracy and argument generation quality for your specific tools. Schema design matters here, clearer parameter names and tighter descriptions reduce model errors in argument generation, and that is entirely on you as the server author.
MCP solves a real standardization problem that was genuinely painful before it existed. It does not solve the hard parts of building reliable agents. The developers who ship the most stable systems seem to be the ones who figured that out before the first production incident rather than after.
How are you handling the token overhead from large tool registries in your current MCP setup, and has anyone found a clean pattern for dynamic scoping that works across multiple host implementations?
Top comments (0)