Overloading MCP’s Responsibilities
A prevailing critique centers on the excessive burden placed upon MCP. It’s argued that MCP’s primary function should be as a straightforward gateway, facilitating LLMs’ access to and interaction with external resources. Conceptualizing it as a mere ‘doorway’ or ‘bridge’ clarifies its intended purpose and inherent limitations.
Directly attributing problems such as accidental data exposure, prompt injection vulnerabilities, and deficiencies in cost control to MCP represents a misapplication of blame. These are challenges that developers must proactively address within their controlled environments. Regardless of the specific protocol employed, developers are responsible for implementing rate limits and meticulously monitoring usage. Drawing a parallel to blaming the road for speeding accurately illustrates the point – the infrastructure itself is not culpable for individual actions.
Ultimately, many of the concerns raised are facets of a broader issue: the inherent complexities of delegating tasks to AI agents. Developers must assume responsibility for diligently managing these challenges within the context of their specific applications, rather than expecting the API itself to provide a comprehensive solution.
The Double-Edged Sword of LLMs and Prompt Injection
Current discourse surrounding MCP often echoes warnings about the inherent dangers of sharp knives – potentially harmful if mishandled. Prompt injection, a significant concern, arises directly from the fundamental nature of LLMs themselves. Attempts to completely eliminate the risk of prompt injection may inadvertently degrade the very capabilities that render LLMs so valuable.
The concept of ‘control vs. data’ separation, a cornerstone of traditional systems, does not naturally translate to the architecture of LLMs. These models derive their power and generality precisely from their lack of this rigid separation. This inherent characteristic makes them vulnerable to prompt injection attacks, a vulnerability that is arguably intertwined with their core functionality.
While remote MCPs offered as a Service may indeed introduce risks, the root cause lies not with the protocol itself, but with the act of entrusting sensitive tasks to potentially untrusted third parties. An apt analogy is that of duct-taping a knife to an erratic Roomba – the danger isn’t inherent in the knife, but in the questionable decision to attach it to an unpredictable device.
Admonishments to ‘be careful’ or suggestions of protective gear, while technically sound, fail to address the central issue: the potentially ill-advised decision to combine a sharp, powerful tool with an uncontrolled system. This highlights the need for careful consideration of the trade-offs involved when deploying LLMs with access to external resources.
Scalability Challenges
Beyond security considerations, MCP faces fundamental limitations in scalability. The author emphasizes the inverse relationship between LLM reliability and the quantity of instructional context provided. This observation challenges the widely held belief that simply adding more data and integrations will automatically resolve existing problems. As the number of tools and integrations increases, an agent’s performance may actually degrade, while simultaneously increasing the computational cost associated with each request.
The author asserts that MCP’s scalability is capped at a certain threshold. Attempts to indiscriminately add an unlimited number of tools to an agent’s context will inevitably have a detrimental impact on its overall capabilities. This limitation is intrinsic to the very concept of MCP and warrants significantly more attention than issues such as authentication.
Users may eventually observe a decline in performance as they enable an increasing number of MCP servers, potentially leading to interference between them. This contrasts sharply with the behavior of typical package management systems, where non-interference is a fundamental and expected property.
The core issue with MCP lies in the discrepancy between its actual behavior and user expectations. It is crucial to acknowledge that MCP is not a plug-and-play solution that allows for the seamless integration of an unlimited number of tools without any associated consequences. Careful planning and resource management are essential for successful implementation.
Addressing Limitations with UI and Tool Management
One suggested approach to mitigating MCP’s limitations is through improvements to the user interface. If a tool is executed inadvertently, the UI should provide a straightforward and intuitive mechanism to disable it or modify its description to clarify its intended usage. Clear and accessible controls are essential for user empowerment and system safety.
The author also acknowledges that context growth can often lead to improved performance and enhanced real-world utility, directly contradicting the notion of a strictly negative correlation. However, they concede that in specific use cases, or with poorly designed contexts, performance degradation can indeed occur. The key is to carefully design and curate the context to maximize its effectiveness.
To address the problem of overwhelming choice among tools, a ‘divide and conquer’ strategy is proposed. This involves introducing a dedicated tool specifically designed to select the most relevant tools for a given task. This ‘tool-choosing tool’ could be implemented as another LLM call, tasked with returning a curated subset of available tools to the ‘parent’ agent. This layered approach introduces additional levels of indirection to manage the inherent complexity of the system.
However, the mere presence of tools within the context can significantly alter a model’s output. While contextually relevant tools (achieved through techniques such as Retrieval-Augmented Generation, or RAG) are undoubtedly beneficial, concealing all tools behind a generic ‘get_tools’ request can be detrimental to the model’s ability to effectively utilize them. A balance must be struck between managing complexity and ensuring accessibility.
MCP as a Transport and Authorization Layer
MCP’s primary function is that of a transport and wire format, incorporating a request/response lifecycle and focusing on authorization at the tool level. The essay argues that a fundamental problem with MCP is its failure to adequately facilitate the functional composition of tools by AI agents.
The author raises the question of whether MCP is truly necessary in the first place, given that LLMs already possess the inherent capability to interact with APIs that are documented using OpenAPI specifications. The missing piece of the puzzle, according to the author, is authorization – the ability to precisely control which APIs an AI agent is permitted to access. Instead of relying on MCP, the author proposes allowing AIs to make direct HTTP requests, while implementing authorization at the level of specific API endpoints. This approach aligns with the current trend of wrapping existing APIs with lightweight MCP tools.
One particularly frustrating aspect of MCP is its lack of native support for streaming tool call results. The single request/response interaction forces clients to repeatedly call tools for pagination, hindering the efficient execution of long-running processes. Implementing a streaming capability, perhaps leveraging gRPC, could significantly improve MCP’s overall efficiency.
The Ease of Exposing Sensitive Data
A significant concern associated with MCP is the potential for the inadvertent exposure of sensitive data. Furthermore, MCP does not inherently enhance the reliability of AI agents; it merely grants them access to a wider range of tools, which can paradoxically lead to a decrease in reliability under certain circumstances. Increased access requires increased vigilance.
The author explicitly states that they do not expect MCP to solve, or be held responsible for, all of these issues. Instead, they argue that MCP creates a larger attack surface for these problems, requiring both application developers and end-users to exercise increased vigilance and implement robust security measures.
Analogies and Urban Planning
The author employs the analogy of urban planning to illustrate the issues at hand. Comparing MCP to a six-lane city road with a 25mph speed limit highlights the disconnect between design and intended use. Simply imposing fines or implementing superficial ‘fixes’ does not address the underlying problem of poor design.
Effective urban planning involves designing roads in a manner that naturally encourages adherence to speed limits. Similarly, MCP should be designed to inherently mitigate potential risks, rather than relying solely on external controls and regulations. A proactive approach to risk management is essential.
LLMs Taking Unwanted Actions
The article shifts to a broader critique of protocols that empower LLMs to execute actions on external services. The author identifies a core problem: LLMs may autonomously take actions that users do not intend for them to take. They draw a distinction between actions that LLMs can execute independently and those that require explicit user prompting and confirmation.
While the ultimate vision may be to have LLMs autonomously manage entire businesses, the technology is not yet mature enough to support such a high degree of autonomy. Currently, users may not even want AIs to send emails without first reviewing the content. A graduated approach to autonomy is recommended.
The author rejects the proposed solution of prompting the user for confirmation before each action, citing the risk of users falling into a pattern of automatic confirmation (‘YOLO-mode’) when most tools appear harmless. This is likened to the psychological phenomenon of individuals spending more freely with credit cards than with cash – a problem rooted in human behavior, rather than in the underlying technology.
The Fundamental Question: Why Not Just Use APIs?
A recurring question in discussions surrounding MCP is the seemingly simple question of why not simply utilize APIs directly. The answer, it seems, is not so simple.
MCP enables LLM clients that users do not directly control (e.g., Claude, ChatGPT, Cursor, VSCode) to interact seamlessly with APIs. Without MCP, developers would be forced to build custom clients using LLM APIs, a significantly more expensive undertaking than leveraging existing clients with a subscription and training them to utilize specific tools. Cost-effectiveness and ease of integration are key benefits.
One developer shared their experience of building an MCP server to connect to their FM hardware synthesizer via USB, empowering AI-driven sound design capabilities. This highlights the potential for MCP to unlock new creative possibilities.
LLM Client Integration and Standardization
The core issue lies in the fact that not all LLM clients natively support direct API interaction, with ChatGPT custom GPT actions serving as a notable exception. Anthropic, Google, and OpenAI have collaboratively agreed to adopt MCP as a shared protocol, aiming to streamline the process for LLM-powered clients such as Claude, ChatGPT, and Cursor.
MCP simplifies the development process for those building LLM clients. If you intend for an LLM to interact with an API, you cannot simply provide an API key and expect it to seamlessly function – you must first create an Agent. Standardization efforts are crucial for interoperability.
MCP can be conceptualized as a standardized method for documenting APIs and describing how to invoke them, accompanied by standardized tooling to expose that documentation and facilitate the execution of calls. It provides just enough abstraction to wrap APIs without introducing unnecessary complication, but this very simplicity can also lead to users inadvertently ‘shooting themselves in the foot.’
The Efficiency and Reusability of MCP
Without MCP, developers would be required to repeatedly explain to the LLM how to use a specific tool each time it is invoked. This constant repetition carries the risk of the LLM failing to use the tool correctly, either due to forgotten information or non-standard API behavior.
This continuous explanation and duplication results in a waste of tokens within the context window, ultimately increasing costs and consuming valuable time. MCP streamlines this process by bundling all necessary information into a single package, making tool usage significantly more efficient and facilitating the sharing of tools across different contexts.
By informing an LLM provider ‘here is a tool that you can use,’ along with the associated API documentation, users can seamlessly reuse that tool across multiple chats without the need for repeated reminders. This also enables desktop LLM clients to connect to programs running locally, addressing the inherent challenges of OS-specific execution processes.
MCP and Local Resource Access
MCP facilitates seamless access to local resources, such as files, environment variables, and network access for LLMs. It is designed to be executed locally, granting the LLM carefully controlled access to these resources. Security considerations are paramount when granting access to local resources.
The standard LLM tool call ‘shape’ closely mirrors the MCP tool call ‘shape,’ making it a straightforward standard for connecting tools to agents. This consistency simplifies integration and reduces the learning curve for developers.
MCP acts as a bridge between the function calling schema exposed to the AI model and the underlying APIs. It translates function calls into tools, enabling seamless communication between the two.
If you are a tool provider, MCP offers a standardized protocol for AI agent frontends to connect to your tool, providing a consistent and reliable integration mechanism. This addresses the question of why the standard protocol cannot simply be HTTP and OpenAPI.
MCP is a meta-API that incorporates endpoints and their operational details into the specification, enabling LLMs to interact with them in a more effective and intelligent manner.
MCP in Specific Scenarios
MCP can effectively address issues that arise when users ask questions or are unsure which APIs to utilize. It can also process requests based on information contained within previous messages in the conversation. Contextual awareness is a key benefit.
One user shared their experience of attempting to retrieve a user’s ‘X’ and send it to a specific endpoint. They found that MCP was overkill for such a relatively simple task, indicating that it is not always necessary for basic API interactions. It’s important to choose the right tool for the job.
MCP is likened to a FastAPI web app framework for constructing software that can communicate over the network, specifically designed for agentic experiences. It can be viewed as ‘Rails-for-Skynet,’ providing a standardized framework for AI agent development. This analogy highlights its potential to accelerate development and promote best practices.
Concerns About Provider Control
Concerns exist that MCP is being promoted to increase provider-side control over the system. LLM providers might eventually restrict API access, similar to how Google made it more difficult to use IMAP/SMTP with Gmail. This raises concerns about vendor lock-in and the potential for limited access.
Using OpenAPI enables agents to retrieve API specifications directly from /openapi.json. This provides a degree of independence and control.
MCP enables quick interactions, allowing users to accomplish tasks in seconds, rather than spending considerable time preparing input data, sending it to the API, parsing the output, and repeating the process for each subsequent message. Efficiency is a key driver of adoption.
Sandboxing and Security Risks
One of the most significant issues is how the output from one MCP server tool can inadvertently affect other tools within the same message thread. This necessitates robust sandboxing between tools to prevent unintended consequences and maintain system integrity. Invariant labs have addressed this through the use of detailed tool descriptions, while others have utilized MCP resource attachments. The lack of effective sandboxing exacerbates the risks associated with prompt injection attacks.
This is compared to SQL injection – a system that is cobbled together, where vulnerabilities can be exploited at any point with minimal observability. Comprehensive security measures are essential.
The prompt interface itself is also susceptible to a form of SQL injection, as the model is unable to distinguish between trustworthy parts of the prompt and user-tainted input. Resolving this requires fundamental changes to encoding, decoding, and the underlying model training process.
This allows for both prompt injection and tool injection, potentially leading to the execution of untrustworthy and potentially malicious code. A multi-layered security approach is needed.
Containerization and Controlled Access
One developer created an MCP server that initiates a Docker container with project code mounted inside. This approach allows the LLM to access the entire Unix toolset and project-specific tooling within a securely sandboxed environment. Containerization provides a powerful mechanism for isolating and controlling access to resources.
This agentic workflow, driven through a chat-based interface, has proven to be more effective than traditional development methods. Chat-based interaction can streamline workflows and enhance collaboration.
The key principle is to grant MCP agents access to only what they absolutely need, and nothing more. Containerization and a transparent tool UX are both crucial for mitigating security risks. A least-privilege approach is essential for security.
Virtual Machines and Internet Access
Providing agents with a computer that has a minimal Linux installation (either as a VM or a container) can yield superior results, enabling them to fetch information directly from the internet. However, this raises significant security concerns regarding malicious instructions and the potential for data exfiltration. The benefits must be weighed against the risks.
Limiting access to a carefully curated list of trusted websites can mitigate some, but not all, of these risks. Even trusted sources can, inadvertently or maliciously, host harmful content. The trade-off between the likelihood of encountering malicious instructions and the productivity benefits derived from internet access must be carefully considered.
The differences between human employees and AI agents are substantial. Employees are legal persons, subject to laws and contracts, providing a degree of accountability. AI agents lack this legal framework, making trust more difficult to establish and maintain.
The Early Stages of MCP Development
MCP was only announced in November 2024, and the RFC is actively evolving. It is still in its formative stages.
Some view the entire AI personal assistant concept, including MCP, as fundamentally flawed from the outset. Skepticism is warranted, given the history of AI development.
The initial push for AI Assistants in the late 1990s and early 2000s failed because content aggregators with vertical integration and bulk buying power proved to be significantly more effective. This led to the rise of platforms such as Expedia and eBay. The lessons of history should inform current development efforts.
Multi-agent systems require programmers to influence the internal state of agents, a notoriously challenging programming task. Complexity can easily spiral out of control.
The Limits of Free Value
The desire to ‘rank results by parking availability’ highlights the challenge of accessing data that is typically behind paid APIs or ad-supported frontends. Companies are unlikely to freely provide access to their entire dataset through an open API. The economics of data access must be considered.
While not all companies will choose to integrate their data into AI agents, the potential for combining various tools to power sophisticated workflows remains a significant opportunity. Innovation often arises from the combination of existing technologies.
Companies that prioritize maintaining a strong data moat will likely resist new technologies that threaten to erode that moat. Data exclusivity is a powerful competitive advantage.
If booking.com were to offer an API, it would likely return the same results as their website, possibly formatted as JSON or XML.
Bypassing the Middleman
It makes little sense for a middleman like booking.com to willingly allow users to completely bypass their services. Disintermediation is a threat to existing business models.
However, individual hotels might find it beneficial to bypass booking.com, a middleman that they often dislike due to the high fees they charge.
A Deep Research AI could proactively scan for hotels based on specific criteria and interact directly with Hotel Discovery MCP servers run by individual hotels, bypassing the need to navigate booking.com’s complex interface and distracting advertisements. Direct interaction can offer significant advantages.
Practical Use Cases
MCP can facilitate tasks such as fetching logs from Elasticsearch or querying databases in a more structured and efficient way. Automation of common tasks is a key benefit.
The static nature of MCP server configuration, where adding new servers requires editing a .json file and restarting the application, can be limiting and cumbersome. Dynamic configuration would significantly improve usability.
Fine-Tuned Models
MCP can be viewed as asmall, fine-tuned model that possesses a deep understanding of numerous MCP tools and intelligently chooses the right tools for each specific conversation. Specialization can lead to improved performance.
Dynamically adjusting the available tools based on the current context might be necessary for certain scenarios. Context-awareness is crucial for optimal performance.
Open-Ended Conversations and Business Problems
MCP is well-suited for general, open-ended conversation systems where there is no predefined flow or structure. However, it is not a one-size-fits-all solution that is appropriate for every business problem. It is not intended to replace existing frameworks such as LangChain. It is important to choose the right tools for the task.
The alternative to MCP, an open community-driven standard, is a landscape of fractured, proprietary, and vendor-locked protocols. A flawed but evolving standard is preferable to having no standard at all. Open standards promote interoperability and innovation.
The best way to view MCP is as a shift from individual developers building client wrappers around APIs to API providers, or community-maintained wrappers building them. This creates a large toolbox of pre-built components, similar to NPM or PyPi. However, orchestration, security, and usage definition are still critical considerations. A robust ecosystem is essential for success.
The next generation of Langchains will undoubtedly benefit from this larger toolchest, but further innovation is still needed to address remaining challenges. Continuous improvement is crucial.
User-Specific Tools
In some cases, tools might be specifically tailored to a particular user’s data, such as tools for slicing and manipulating CSV files that have been uploaded by the user. Personalization is an important aspect of AI development.
One often overlooked issue is that MCP can inadvertently crowd the model’s context window with too many options, leading to decreased performance. Prioritization and metadata exposure are crucial for avoiding wasteful token usage and erratic model behavior. Context management is a critical aspect of performance optimization.
Standards and Evolving Technology
New standards emerge over time, and it has been so long since standards truly mattered that many have forgotten how they develop and evolve. Standards evolve over time to meet changing needs.
Downloading tiny server programs from random developers to add ‘tools’ to LLM clients can be a risky endeavor. Trust is paramount when integrating external code.
The issues raised are legitimate problems that the MCP ecosystem must actively address. Some solutions will be implemented within the MCP specification itself, while others will be addressed through external tools and best practices. A holistic approach is necessary.
Claude Code and Real-World Usage
There are contrasting opinions on the success of MCP in real-world deployments. Some have heard anecdotal accounts of companies successfully integrating with MCP, while others have heard from users who found it to be disappointing in practice.
This highlights the potential drawbacks of excessive hype and premature adoption. Managing expectations is crucial.
Some developers find that traditional HTTP APIs are superior to MCP for the vast majority of use cases. They argue that ‘tool’ usage essentially boils down to API endpoints that provide specific capabilities and functionality. Simplicity can often be a virtue.
APIs are not self-describing by default, representing a missed opportunity for proponents of REST and HATEOAS to showcase the benefits of their approaches. Improved API discoverability is a key goal.
MCP as a LangChain Alternative?
MCP has been described as having a ‘LangChain smell’ – failing to solve a pressing problem, being overly abstract in its design, and having difficulty explaining its core advantages in a clear and compelling manner. Communication is key to adoption.
Perhaps it needs to unequivocally state ‘END OF LINE’ and banish wannabe hackers to the game grid! A clear and concise vision is essential.
A key question is whether the ‘general’ Chatbot paradigm will persist, or whether it will be supplanted by more specialized approaches. Specialized apps with their own tightly integrated tools might not require MCP at all.
Conversely, as LLMs become increasingly capable, external tools might become less necessary. Why would you need an MCP to drive Photoshop when the LLM can simply edit the image directly, leveraging its inherent capabilities? The future is uncertain.
The sci-fi robot assistant dream may not materialize, and specialized language manipulation tools might ultimately prove to be more useful and practical. Focusing on concrete applications is essential.
The User Base and Security Awareness
The user base of MCP includes individuals with varying levels of technical expertise, making security issues particularly relevant. Raising awareness of security best practices is absolutely crucial for ensuring the safe and responsible use of the technology. Education is paramount.
Basing Xops on OpenRPC, which requires explicitly defining the result schema, helps to plan precisely how outputs connect to inputs, improving reliability for complex workflows. Precise specifications enhance reliability.
The technology is likely to evolve and settle over time, as new best practices emerge and the community gains more experience with its use. Continuous adaptation is essential.
Redundancy and Cloud Infrastructure
Some question the net gains of using MCP over the existing OpenAPI standard, viewing it as largely redundant and adding unnecessary complexity. Simplicity and efficiency are key goals.
What will the LLM utilize to call out to an OpenAPI system? How will it bind to the shell? How will the LLM’s host orchestrate that process? These are critical questions that must be addressed.
MCP provides a structured and standardized way for LLMs to make tool calls, simplifying the integration process and promoting interoperability.
MCP servers are already HTTP servers at their core. The underlying transport mechanism is well-established and widely understood.
The biggest advantage of MCP is for LLM providers such as OpenAI, rather than for individual application developers. It empowers LLMs to access and utilize external tools, thereby enhancing their capabilities.
LLMs are essentially brains without tools; tool calling empowers them to interact with the real world. However, with standard APIs, LLM providers often lack direct access to those tools. MCP grants them that access, positioning them as the primary gateway to the world of AI. Control is a key motivator.
CLI vs. API
Why not simply utilize the CLI (command-line interface) directly, given that LLMs are trained on natural language and CLIs are a common human-readable and writeable solution? The CLI offers a powerful and flexible interface for interacting with systems.
MCP emerged too quickly and requires more time to mature and refine its design. It lacks thorough vetting by a conventional standards body and is driven, in part, by the current hype surrounding AI. Patience is a virtue.
There is a noticeable lack of compelling real-world applications that demonstrably showcase the value of MCP. Practical applications are essential for driving adoption.
Key Applications of MCP
MCP is currently utilized in Claude Desktop and niche AI chat applications, code automation tools, and various agent/LLM automation frameworks. Its applications are still emerging.
It’s another rushed technology that will likely be discarded when the next hype-able acronym arrives, if history is any guide. The landscape of technology is constantly evolving.
There are fundamentally two types of language model tool calling protocols: the ones that people actively complain about, and the ones that nobody actually uses. The goal is to create a protocol that is both useful and well-received.
Anthropic developed this ‘standard’ in relative isolation, which has led to the identification of various security issues. Collaboration and open review are crucial for building robust standards.
JSON-RPC 2.0
MCP is built upon JSON-RPC 2.0, a lightweight protocol that enables communication between clients and servers using JSON (JavaScript Object Notation). This provides a foundation for interoperability and ease of implementation.
It feels like a centralized specification designed primarily for a specific ecosystem, while claiming universality without truly earning it through widespread adoption and community support. A truly universal standard must be broadly accepted and implemented.
MCP is powerful enough to accomplish useful tasks, which inherently raises security concerns. The more powerful the tool, the greater the potential for misuse.
It is not a mature standard and was not originally designed with security as a paramount concern. Security must be a core design principle.
While recommendations for security best practices do exist, they are often not rigorously enforced or widely implemented. Consistent and enforced security practices are essential.
Langchain and Tool Calling
Langchain is one of many frameworks that implement the ‘tool calling’ pattern, providing a mechanism for LLMs to interact with external tools and services.
MCP is a specification that governs how external information enters a language model’s context window, encompassing tool calling, templated input, cancellation mechanisms, progress tracking, and the statefulness of tool servers. It provides a comprehensive framework for managing external interactions.
It helps to standardize numerous details, ensuring that any assistant/integration combination is compatible and interoperable. Interoperability is a key goal of standardization.
While MCP has legitimate shortcomings and areas for improvement, critics should strive to refine their arguments and offer constructive feedback. Constructive criticism is essential for progress.
Authentication is absolutely crucial and should not have been omitted from the initial version of the specification. Security must be a primary concern from the outset.
There are simply too many complexities inherent in the design and implementation of MCP. Simplicity is a virtue, and unnecessary complexity should be avoided whenever possible.