No, MCP's have NOT won (Yet)
#33 | With all the frenzied articles on MCPs, I think it is important to reflect on the current limitations - developer experience, application deployment and security.
I find much of the MCP conversation very puzzling. On one hand, there are articles that make broad claims like “Why MCP Won” but on the other hand, there are almost no examples of 3rd party demos or production apps where the MCP infrastructure is integrated into workflows with clear benefits over existing approaches.
The typical influencer material - Holy ship MCP servers are exploding my cursor work.. blah … does not count here.
There seems to be a clean split between two types of developers - developers who have tried to build an MCP server/client and integrated it to solve a concrete/valuable problem as part of their own workflow (and are incensed!). And those who have not (e.g, just read posts, or used existing MCPs in a tool like Cursor or Windsurf, or similar influencer material, or are attracted to the promise of the idea).
TLDR;
MCP is a great idea, but the reality is that it is early and rife with challenges:
Developer Experience Limitations: The complexity of implementing MCP servers is substantial, with basic examples requiring hundreds of lines of code and limited testing options.
Deployment and Integration Constraints: MCP clients must run within host applications, creating technical hurdles with performance impacts and transport compatibility issues.
Security Considerations: Building secure MCP-integrated applications requires addressing multiple threat vectors, from token theft to prompt injection attacks, especially critical as the protocol gains wider adoption.
I write all of this with humility knowing that the MCP protocol is early and any of the criticisms here will be likely addressed (see the MCP roadmap).
For context, I contribute to the AutoGen library (a framework for building multi-agent apps) and I spent sometime reviewing how well we can integrate MCPs into agentic workflows built with AutoGen. I wrote about the challenges there, but feel it might be easier to discuss as a topic of its own.
Developer Experience Issues
The current complexity in expressing your business functions as an MCP server is non trivial (the basic example for an MCP tool to fetch a web page is 300 LOC in the official MCP sample). Also most of the documentation does not cover integration with custom workflows (what many developers need to do), but integration with apps like cursor or Claude Desktop.
Today, to build an MCP tool, you will need to use the TypeScript or Python SDK (substantial work), bundling as an npm or PyPI package, or bundling as a local binary with absolute path references - none of which create a streamlined development workflow.
Testing options for MCP tools are severely limited. Cryptic error messages, including environment and setup issues with node, uv etc which are required by the sdks.
IMO, developer experience really matters.
In fact, the historically, the standards that have won are not necessarily the ones that have the strongest technical story - it is the one that was easiest (developer experience) to use (REST vs SOAP, Python vs others for datascience).
Deployment Compatibility Requirements
There are two potential camps for integrating MCPs into deployed apps, each with distinct engineering challenges:
Apps that enable Bring Your Own MCP (Claude Desktop, Cursor, etc.). This assumes there is a user actively importing their own MCP from some source and your app provides the infrastructure to spin up the server (execute some uv or npx command) and a client within your host app then talks to this server. Note here that Desktop apps typically have more permissions, e.g., thread creating, spinning up processes, writing to stdio and will likely run with the elevated permissions of the logged-in user (assumes user supervision). This extends the security threat model—any arbitrary MCP server may behave in arbitrary ways. Engineering complexity here centers on process management, error handling for unpredictable server behavior, and security sandboxing for untrusted MCPs.
API with MCP Client Bundled. Think of a typical service e.g., Grammarly that provides text editing services who want to replace their grammar correction service with a more agentic workflow and now will call a set of internal tools via MCP clients. There is no human intervention here and the API will likely run in some constrained microservice environment with restrictions on transports supported. This approach faces different engineering complexities around performance optimization in constrained environments, transport protocol limitations, and scaling for high-throughput services.
In both cases, MCP clients must run within a host application. Many host app environments (especially for deployed APIs) are pretty stringent and proposed transports like stdio (which is used by most of the examples) will just not work. This embedded design introduces significant technical challenges. As I've pointed out previously, "The MCP client operates within your host application, which can affect your app's performance and stability. This embedded design may introduce latency and cause threading conflicts when your application uses asynchronous processing."
Documentation Biased Toward Existing Products
A significant criticism of MCP IMO is that its documentation heavily focuses on integration with Claude Desktop, which is not what most developers need or what system builders require. The bulk of examples showcase existing integrations rather than helping developers build their own host applications.
As developers trying out a new protocol, we typically expect clear tutorials with copy-pastable code, instructions to run local versions, and examples showing integration into our own host applications.
Security Concerns
I am not a security expert, but the effort to build a truly secure app that integrates MCPs is non-trivial. All existing security threat models apply, and more, especially when using 3rd party MCP servers that "triage" calls with user auth tokens on your applications' behalf.
Some example 3rd party security issues include:
Token Theft: If an attacker obtains OAuth tokens stored by MCP servers, they could create their own server instance using this stolen token, potentially accessing sensitive information across multiple services [3].
Server Compromise: MCP servers represent high-value targets because they typically store authentication tokens for multiple services, creating a "keys to the kingdom" scenario if breached [3].
Prompt Injection Attacks: MCP creates new attack vectors through indirect prompt injection in AI interfaces, where seemingly innocent messages could contain embedded commands that trigger unauthorized actions [3].
Excessive Permission Scope: The centralization of multiple service tokens creates unprecedented data aggregation potential and privacy risks [3].
These are not new, but I increasingly get the sense that many “vibe coding” engineers may need to be reminded of this.
If you are an experiences engineer, I’d like to reiterate that much of what is in this section is not new. However AI, and MCPs make coding (vibe coding and all) more accessible - meaning there are many developers that may not intuitively see potential security issues. Good tools and protocols should make security and easy, perhaps built in feature.
Not Dismissing MCP's Potential
To be clear, MCP represents a step in the right direction. It creates a standardized interface between AI agents and various services, a centralized solution for delivering LLM tools.
I certainly see the benefits of a protocol with respect to software delivery e.g., a developer creates an MCP server and the same thing can be delivered to all users of client apps that support MCP (e.g., Claude Desktop, Windsurf, Cursor etc). Ofcourse, this requires that the client apps have done the work to support MCP, and the developers/users can install the mcp server correctly, edit json files here and there etc. The effort matrix changes for building and then integrating MCP servers into developer apps that run in constrained deployment environments.
What Would Make MCP Truly Shine
For MCP to fulfill its potential, we probably will need:
Real-world integration examples: Practical demonstrations showing MCP servers solving actual tasks within common frameworks (e.g., a complete tutorial building an MCP server and using it in a Chainlit app). These should include comparison baselines using pure Python scripts, clearly highlighting any benefits that justify MCP's added complexity and deployment requirements.
Additional production-ready transports: Alternatives to stdio and SSE (with examples) that work well in containerized and enterprise environments with better connection management etc. There are probably good reasons why this is not done yet, but making this clear would be useful.
Function-first development model?: Simple decorators to easily convert existing business logic to MCP endpoints with automatic schema generation and proper error handling?
Security implementation patterns: Reference implementations for secure token handling, clear guidance on permission scoping, and threat modeling / mitigation strategies. Many of the users of MCP will be new to engineering and less familiar with security.
Conclusion
I think MCPs are a step in the right direction... but claims that "MCP has Won" in its current state just feel off. The protocol shows promise, but requires significant improvement in developer experience, security, and usability before it can become the standardized "USB-C for AI" that it aspires to be.
The "MCP has won" arguments in this article start a valuable conversation, but paint a limited picture. Several things left me unsatisfied. First, it focuses on social proof/inertia - GitHub stars and social buzz as metrics for winning - good indicators of momentum, but not the full story. Next, conspicuously absent is any discussion of developer experience (experience for those who have tried building, no using an MCP server?), deployment challenges (stdio transport won't work in many production environments), or security considerations (token theft, server compromise risks).
My experience trying it out and running into these practical limitations certainly suggests it is premature to declare victory, IMO.
The MCP roadmap looks promising - there is some early discussion on auth/authorization and a few other important bits that inspire hope.
Finally, I'd like to offer sincere kudos to the team working on MCP (in my experience, it's usually a small group working incredibly hard). Your contributions are actively shaping this space, and this clearly represents a tremendous amount of work. This entire post is meant to provide constructive feedback (see the section on what would make MCP shine), with genuine appreciation for everything you've accomplished so far!
References:
Great read! Thank you for sharing!
Reminiscent of adoption trajectories of standards like REST/SOAP etc