MCPs Won't Scale Your Engineering Org

MCP has 10,000 public servers, 97 million monthly SDK downloads, and backing from Anthropic, OpenAI, Google, Microsoft, and the Linux Foundation. Every major AI coding tool supports it natively. The protocol went from 50 servers at launch in November 2024 to near-universal adoption in 18 months.

Perplexity's CTO Denis Yarats announced at Ask 2026 in March that the company is moving away from MCP internally. Y Combinator CEO Garry Tan called it trash and built a CLI replacement in 30 minutes. Eric Holmes published “MCP is dead. Long live the CLI” to 400 points on Hacker News.

The protocol is winning adoption and losing the practitioners trying to run it at scale. That disconnect tells you something important about what MCP actually is, and what it is not.

MCP is a connectivity protocol. It solves tool integration. It does not solve the coordination, governance, and context problems that actually prevent engineering organizations from scaling AI adoption. Treating it as though it does is the mistake that will cost engineering orgs the next two years.

What MCP actually is

MCP's own documentation describes it as “an open standard that enables developers to build secure, two-way connections between their data sources and AI-powered tools.” That is an accurate description. It standardizes the JSON-RPC interface between an AI agent and external tools. Tool discovery, invocation, and streaming.

Think of it as USB-C for AI tools. Before MCP, every AI client needed a custom connector for every tool. MCP provides one standard interface. Cursor, Claude Code, Copilot, Gemini, and ChatGPT all speak the same protocol to external services. That is genuinely valuable. USB-C is genuinely valuable.

“My understanding of what MCP is: it's just a standard on how to provide tools/functions to LLMs to call. What those functions are, what they do, and what else happens when they're called is out of scope. To me MCP is literally plumbing between black boxes.”

— Hacker News commenter, HN thread on MCP

That commenter understood MCP better than most of the market does. MCP is plumbing. Good plumbing. Plumbing that was needed. But the confusion starts when “context” in the name gets interpreted as organizational intelligence, and “protocol” gets interpreted as architecture.

What the market thinks MCP is

The market treats MCP as the answer to multi-agent coordination. Connect enough tools via MCP, the thinking goes, and your AI engineering workflow will scale. Give agents access to everything through a standard protocol, and the coordination problem solves itself.

It does not. 86% of organizations now rely on AI agents in daily operations, according to the Dataiku/Harris Poll Global AI Confessions Report. Yet most lack the orchestration and governance infrastructure to manage them at scale. Agents operate on fragmented data, duplicate work across teams, and produce outputs that no one can audit end to end. 75% of data leaders say trust in AI agent deployments is a concern.

MCP connects agents to tools. It says nothing about which agent should work on which task, what risk level a change carries, whether two agents are about to create conflicting changes, or what your architecture decisions were six months ago. The protocol delivers context to a model. It does not determine what context matters, how it should be governed, or how to maintain organizational memory across sessions.

Five things MCP cannot do

The gap between MCP-as-protocol and MCP-as-organizational-solution is specific. These are the five capabilities engineering organizations need to scale AI adoption, none of which MCP provides or intends to provide.

1. Persistent organizational context. Every AI session is stateless. MCP can deliver data to an agent, but it cannot maintain architecture decisions, incident history, coding standards, or team ownership across sessions. Your agent starts as a stranger every time, regardless of how many MCP servers you connect.

2. Cross-agent coordination. Two agents working via MCP can produce syntactically valid but semantically incompatible changes. Stanford and SAP's CooperBench showed two frontier AI agents collaborating hit a 25% success rate, roughly 50% lower than a single agent doing both tasks alone. More connections do not produce better coordination.

3. Governance and policy enforcement. MCP's OAuth support handles authentication. It does not handle authorization governance, risk assessment, audit trails, or policy enforcement. CData's analysis notes that “MCP's scope is currently limited to discovery and invocation, omitting crucial aspects like tool governance, versioning, or lifecycle management.”

4. Risk calibration. Not all changes carry the same risk. A documentation update and a payments service refactor require different levels of human oversight. MCP provides no mechanism for classifying changes by risk or routing review effort accordingly. Every change goes through the same pipe.

5. Organizational memory. Why did the team reject that approach last quarter? What caused the incident in service X? Which areas of the codebase are fragile? This knowledge exists in Slack threads, postmortems, and engineers' heads. MCP has no mechanism to accumulate, structure, or surface it across agent sessions.

The governance inversion

There is a deeper architectural problem with MCP that the five-point list above does not fully capture. MCP is agent-invoked. The agent decides when to call an MCP server, which server to call, and what to do with the response. That design choice has a consequence most people miss: if you encode policy into an MCP server, you are trusting the governed entity to enforce its own governance.

Say you want to enforce a rule: “All changes to the payments service require a security review before merge.” In an MCP world, the agent has to discover that this policy exists (via tool descriptions consuming tokens), decide on its own to invoke it at the right moment, call the correct MCP server with the right parameters, and then actually comply with the response. Every step of that chain is probabilistic. The agent might not discover the policy. It might decide the policy does not apply. It might call the server incorrectly. It might ignore the result.

This is not governance. It is a suggestion. Real governance is external. It is applied to the agent by a layer above it, not discovered by the agent at its own discretion. The building inspector does not ask the contractor to read the code and self-certify. The inspector gates the work independently.

The cost compounds too. Every MCP tool definition the agent must consider adds tokens. More policy servers means more tool descriptions in the context window, which means higher cost per invocation and less room for actual work. You pay more for the agent to think about governance and get less reliable enforcement in return. An orchestration layer above the agent enforces policy without consuming the agent's context window or relying on its judgment about when to comply.

The pattern we keep repeating

Every infrastructure category follows the same arc. A connectivity standard arrives, gets conflated with the full solution, and then reality forces an orchestration layer into existence above it.

Docker solved container packaging and portability. It worked on one machine. It did not handle scaling, self-healing, load balancing, multi-node scheduling, or rolling updates. Kubernetes emerged to solve orchestration at scale. The Borg, Omega, and Kubernetes paper in ACM Queue notes: “Container management per se was just the beginning of an environment.”

REST standardized how services communicate. It did not solve circuit breaking, retries, mTLS, observability, traffic routing, or rate limiting. Service meshes emerged as the coordination layer above the connectivity protocol.

USB standardized physical device connectivity. It did not handle device management, driver coordination, power management, or security policies for peripheral access. The operating system provides the orchestration layer above the physical connection.

MCP is at exactly this moment. The connectivity standard is adopted. The market is discovering that connecting things is the easy part. Coordinating them at scale, with governance and reliability, is the actual engineering challenge. That challenge lives above the protocol layer.

Evidence from the field

The DORA 2025 report found that AI adoption continues to have a negative relationship with software delivery stability. 90% of developers use AI at work. 80%+ report increased individual productivity. Organizational delivery metrics remain flat or declining. Google's researchers put it directly: “AI's primary role in software development is that of an amplifier. It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones.”

Connecting more tools via MCP does not fix dysfunctional coordination. It amplifies it. More tools means more output. More output without coordination means more coordination waste.

The technical limitations are concrete. Cloudflare found that for their 2,594-endpoint API, native MCP tool definitions would consume 244,000 to 1,170,000 tokens before the agent processes any user input. Their “Code Mode” workaround reduces this by 244x. Perplexity's CTO cited 72% context window consumption before any conversation begins. Julien Simon documented seven MCP servers consuming 67,300 tokens, a third of a 200,000-token context window, on tool metadata alone.

“The problem is not that we have too many tools. The problem is that we are treating a transport layer like it is intelligence.”

— “MCP Is a Transport Layer Pretending to Be a Brain,” DEV Community

Security research makes the production-readiness gap worse. 43% of tested MCP implementations had command injection flaws. 30% were vulnerable to SSRF. The Cloud Security Alliance documented 200,000 vulnerable instances across a supply chain of 150 million+ package downloads. Enterprise readiness is listed as the fourth and final priority in MCP's 2026 roadmap, described as “the least defined of the four priorities.”

Even if every one of these issues were fixed tomorrow, MCP would still be plumbing. A perfectly secure, efficient, scalable connectivity protocol still does not tell your organization which agent should work on which task, what risk level a change carries, or what your architecture decisions were six months ago.

What actually scales engineering orgs

The research paper “The Novelty Bottleneck” (arXiv, 2026) puts it clearly: “AI agents make large teams less efficient, not more. Each person commands agents that amplify their throughput, but this amplified output increases the integration burden on every other team member.” This is Brooks' Law for the AI era. More agents connected via MCP means more coordination needed, not less.

What scales is what has always scaled complex systems: an orchestration layer above the connectivity layer. The coordination bottleneck is not a connectivity problem. It is a problem of context, governance, and workflow coordination.

Context infrastructure gives agents organizational memory: architecture decisions, incident history, ownership, coding standards. Agents stop starting as strangers and start producing architecturally coherent output. Governance infrastructure classifies changes by risk and routes review effort accordingly. Low-risk changes ship without blocking on senior reviewers. High-risk changes go to the right human with structured context. Orchestration infrastructure coordinates parallel agent work so sessions do not duplicate or conflict, and workflows are explicit and auditable rather than black-box LLM decisions.

“Coordination, not raw coding ability, is a central bottleneck for multi-agent software development.”

— Khatua et al., CooperBench, Stanford/SAP (2026)

Augment Code's analysis identified the same pattern: “The reason individual AI productivity does not produce 10x engineering organizations is coordination drag: review, governance, and execution systems do not scale at the rate developers now generate code.”

The companies building MCP gateways with governance layers are proving this thesis from the other direction. Companies like Stacklok are adding registries, RBAC, and audit logging on top of MCP. That is the pattern: the orchestration and governance layer above the connectivity standard. MCP alone is insufficient. Everyone building on top of it knows this.

The practitioner verdict

The backlash is not about whether MCP works as a protocol. It works. The backlash is about the gap between what MCP is and what the market expects it to be.

Eric Holmes, in his viral “MCP is dead” post, cited brittle initialization, all-or-nothing permissions, and authentication that conflicts with enterprise SSO. Julien Simon, formerly of AWS and Hugging Face, published two pieces arguing MCP ignores 40 years of RPC best practices. His recommendation for production-scale work: “Use function calling, direct APIs, or CLIs.”

Cybersecurity leader Chenxi Wang put it precisely: “If skills are invoked outside any control plane, then governance fails. You enforce governance by moving control up: from protocol layer to agent execution.”

The practitioners hitting limits are the ones trying to run production workloads at scale. Individual developers connecting a tool in their IDE are fine. The disconnect between those two experiences is the entire story: MCP is a developer tool protocol being asked to serve as enterprise infrastructure. It was never designed for that. It should not be expected to become that.

MCP will survive as plumbing

MCP will likely remain the dominant agent-to-tool connectivity standard. It deserves to. The Linux Foundation governance, multi-vendor support, and developer adoption are real. The protocol solved a real problem: the M-by-N integration matrix between AI clients and external tools.

But TCP/IP won too. It did not make distributed computing easy. That required decades of additional infrastructure built on top. Docker won. It still needed Kubernetes. REST won. It still needed service meshes.

The organizations waiting for MCP to become the operating system for AI engineering will keep waiting. The organizations that recognize it as the connectivity layer and build the orchestration, governance, and context infrastructure above it will ship at AI speed while the rest are still debugging tool connections.

The orchestration layer above MCP is the infrastructure category being defined right now. The protocols are settled. The plumbing works. The question that remains is coordination, and that is an entirely different class of problem.