Guillaume Lebedel · · 9 min 
MCP: What's Working, What's Broken, and What Comes Next (what a year in production has taught us)
Table of Contents
In November 2024, Anthropic open-sourced the Model Context Protocol. Within a year, it became the standard for connecting AI models to external tools: 97 million monthly SDK downloads, 10,000+ active servers, and adoption by OpenAI, Microsoft, and Google.
The fundamental question persists: is MCP the right abstraction? Debate continues across Hacker News, Reddit, and developer blogs — some view it as AI tooling’s future, others as over-engineered middleware destined for obsolescence.
StackOne has spent a year building MCP servers, debugging authentication flows, and observing spec evolution. Here’s what works, what remains broken, and what comes next.
The Evolution of Model Context Protocol
MCP began as an experiment rather than finished product. The original specification provided simple JSON-RPC over Server-Sent Events with basic tool definitions. Security incidents forced authentication maturity. Enterprise adoption exposed multi-tenant gaps. When Asana launched their MCP integration, researchers discovered a “Confused Deputy” vulnerability where servers cached responses without re-verifying tenant context.
Scale broke the original transport — SSE worked locally but failed handling thousands of concurrent production connections. Streamable HTTP replaced it. The ecosystem needed discovery; by early 2025, thousands of community servers scattered across npm, PyPI, and GitHub repositories prompted the Registry launch.
What MCP Gets Right in 2025
Discovery is useful: AI agents ask “what can you do?” and receive structured answers immediately — no hardcoded lists or stale documentation.
The abstraction fits simple cases: Connecting Claude to Notion or letting GPT-4 read GitHub issues becomes much simpler than building custom integrations.
Vendor neutrality matters: The same MCP server works with Claude, GPT-4, Gemini, and local models.
What’s Still Missing in the Model Context Protocol
MCP Authentication Is Still a Mess
The specification technically supports OAuth 2.1, but SDKs and reference implementations assume servers are also authorization servers. Enterprise IdP integration (Okta, Azure AD) requires workarounds. Token lifecycle management proves particularly painful when using third-party authorization — complex token mapping and tracking become necessary.
MCP Multi-Tenant Support Is Bolted On
MCP was designed for single-user, local deployment. Enterprise SaaS requires multi-tenant infrastructure where many users share resources while accessing only their data. The protocol lacks native tenant isolation concepts. Teams must build their own solutions for:
- Tool visibility (which tools can users see?)
- Permission boundaries (what actions are permitted?)
- Data isolation (preventing cross-tenant leaks)
The Asana vulnerability was a Confused Deputy attack: the server trusted cached context without re-verifying who was asking. MCP’s spec doesn’t prevent this. You have to build tenant isolation yourself.
MCP Admin Controls Don’t Exist
Deploying AI agents to teams requires administration controls: which MCP servers can users connect, what tools are allowed per user or role, and how do you audit agent actions? MCP offers no answers.
MCP Tool Discovery Needs Work
The Registry helps clients find servers, but there’s no standard for agents discovering tools within sessions based on context. “I’m working on a Jira ticket” should automatically surface relevant tools. “I’m in a code review” should show a different set. Applications must embed this logic themselves.
MCP Notifications Are Immature
MCP operates on request-response: clients ask, servers answer. Real integrations need push capabilities — new emails arrived, builds finished, PR comments posted. While specification hooks exist, implementation guidance remains thin and tooling support inconsistent.
What Developers Say About MCP
The developer sentiment on MCP is… mixed. Reddit threads and GitHub discussions paint a picture of genuine frustration alongside cautious optimism.
On server quality: “95% of MCP servers are utter garbage.” That’s a real quote from the MCP subreddit, and it reflects a common complaint. The barrier to publishing an MCP server is low. The barrier to publishing a good one is much higher.
On token overhead: Before Code Mode, developers complained about context windows filling up with tool definitions. Loading 50 tools meant burning 100K+ tokens before the conversation started. This was a real blocker for complex workflows.
On security: Security researchers found prompt injection vulnerabilities in early MCP implementations: tool poisoning, sandbox escapes, the usual suspects when a new protocol meets production traffic. The spec has improved, but the ecosystem of community servers hasn’t fully caught up.
On the hype cycle: “MCP is either the future of AI tooling or an elaborate over-engineering exercise.” Fair. The protocol adds abstraction between models and tools. That abstraction has costs. Whether it’s worth it depends on your use case.
MCP is far from perfect today. It needs significant work around safety, security, and governance to be enterprise-ready. But the trajectory matters: every major pain point from the first year — auth, transport, discovery — has been addressed in subsequent spec revisions. Community adoption tells the real story. Teams shipping MCP in production are increasingly positive, and with each release, there are fewer skeptics and more believers.
The Next Evolution: Code Mode
This is where it gets interesting. The debate isn’t “MCP vs no MCP.” It’s how agents should call MCP tools.
The traditional approach: load all tool definitions into context, let models pick which tool to call, feed results back through the model. This works, but it’s expensive. Thousands of tools means hundreds of thousands of context tokens just for definitions.
The emerging approach: Code Mode. Instead of calling tools directly, the agent writes code that calls tools. Cloudflare’s Agents SDK converts MCP schemas into TypeScript APIs. The LLM writes await mcp.notion.createPage({ title: "..." }) instead of emitting special tool-calling tokens.
Why does this matter?
- Context overhead: All tool definitions loaded upfront (150K+ tokens for large toolsets)
- Intermediate results: Every tool output passes back through the model
- Control flow: Loops and conditionals require multiple model roundtrips
- Training data: LLMs have seen less tool-calling syntax than real code
- On-demand discovery: Tools loaded only when needed (2K tokens vs 150K)
- Local execution: Filter and aggregate data before returning to model
- Native control flow: Loops, conditionals, error handling run as code
- Better performance: LLMs are better at writing TypeScript than tool-calling tokens
Anthropic’s research shows this approach reduces token usage by 98.7%.
Code Mode doesn’t replace MCP. It makes MCP more efficient by having agents write code that calls MCP tools.
What Needs to Happen for MCP Enterprise Adoption
- First-class multi-tenant support: Tenant isolation, per-user permissions, and admin controls should be protocol-level concepts.
- Better IdP integration: SDKs should assume enterprise auth as default.
- Context-aware discovery: Agents see relevant tools based on current context.
- Unified observability: Standard ways to trace agent actions, log decisions, and audit behavior.
The Linux Foundation Move: Too Early?
November 2025 brought Anthropic’s donation of MCP to the Linux Foundation’s Agentic AI Foundation, framing it as vendor-neutral governance ensuring long-term future.
The concern: MCP isn’t ready for stasis. Foundation governance slows development — that’s intentional. But MCP still contains fundamental gaps: multi-tenancy, admin controls, context-aware discovery, real-time notifications. These aren’t edge cases; they’re enterprise blockers.
Foundation governance means committees, consensus, and careful deliberation. Protocol evolution follows agreement speed, not need speed. Competitors with centralized control iterate faster and ship features quicker.
Is Anthropic stepping back because they know MCP won’t be the winner?
The handoff signals MCP serves some use cases, not universal AI-tool interaction. By transferring to the Foundation, Anthropic focuses on making Claude better without managing a protocol potentially capturing only part of the market.
MCP might become the USB-C of AI tooling: widely adopted, good enough for most cases, but not the only connector. Or it may ossify while something more nimble emerges.
Where We’re Betting: MCP vs Code Mode
Both paths coexist:
MCP for structured, high-trust integrations: Enterprise workflows requiring explicit permissions, audit logs, and vendor-neutral tooling.
Code Mode for exploratory, developer-centric use cases: When agents need flexibility and broader system access is acceptable.
Winners won’t choose sides — they’ll understand when to use which approach.
The Missing Layer: Agent Skills for MCP
MCP provides technical plumbing connecting models to tools but doesn’t specify when to use which tools or how to combine them for specific outcomes.
Skills fill this gap as the abstraction layer making MCP usable: they encapsulate MCP servers and tools into outcome-oriented packages without overloading context.
The Agent Skills specification defines skills as reusable capability modules. Drop a skill file and agents gain new domains: code review patterns, deployment workflows, research methodologies. Skills specify which MCP servers to use, what tools to invoke, and how to combine them.
Skills prove interesting for two reasons:
Use-case framing: MCP describes tools technically; skills describe outcomes. Agents reason better about outcomes than API specifications.
Context isolation: Agents with 50 MCP servers face 50 competing tool definitions. Skills load only what’s relevant — activate deployment skills, get deployment tools only. The rest stays out of context until needed.
Skills won’t replace MCP; they make it more accessible. MCP provides standard interfaces; skills provide higher-level composition making those interfaces useful.