Image by Editor
Introducing MCP
The success of standards often hinges on adoption rather than technical superiority. The Model Context Protocol (MCP), introduced by Anthropic in late 2024, recognized this principle. It addressed the fundamental challenge of enabling artificial intelligence (AI) models to interact with external tools. The protocol’s straightforward design fostered rapid implementation, and its clear benefits fueled demand. Within a few months, MCP achieved the network effects necessary to become an industry standard. However, as Sebastian Wallkötter, an AI researcher and data engineer, highlighted in a recent discussion, this quick adoption has brought forth significant questions regarding security, scalability, and the appropriateness of AI agents for all solutions.
Wallkötter offers a distinct viewpoint on these topics. His 2022 PhD from Uppsala University focused on human-robot interaction, exploring natural collaboration between robots and humans. Subsequently, he moved into commercial AI, developing large language model (LLM) applications and agent systems. His experience spans academic research and practical deployment, offering valuable insights into AI systems’ technical potential and real-world limitations.
Why MCP Won The Standards Race
The Model Context Protocol addressed a seemingly simple challenge: establishing a standardized method for AI models to interact with tools and services. Prior to MCP, each LLM provider and tool developer needed to create bespoke integrations. MCP introduced a universal language for these interactions.
Wallkötter explained that the protocol focuses on tool calling. An agent or LLM is designed to interact with applications like Google Docs, calendar apps, or GitHub.
MCP’s success reflects similar stories of platform standardization. Much like Facebook gained critical mass when its user base grew sufficiently to make the network valuable, MCP reached a point where providers adopted it due to user demand, and users sought it because providers supported it. This network effect propelled its adoption globally, without noticeable regional differences between US and European implementations.
The rapid adoption surprised many. Major platforms integrated MCP support within months of its October 2024 launch. Wallkötter believes the initial drive came from developers recognizing its practical utility. He described the dynamic: “Once MCP becomes widely used, all providers support it. Therefore, developing an MCP server ensures compatibility with all models. Conversely, if everyone has an MCP server, supporting it offers extensive compatibility.” The protocol quickly transitioned from a technical specification to an industry standard.
The Security Blind Spot
Despite its swift adoption, the initial MCP specification contained notable shortcomings. Wallkötter pointed out that developers soon uncovered a critical vulnerability: “The first MCP version lacked any authentication. This meant anyone globally could access and operate any MCP server, which clearly posed risks.”
The authentication problem is more intricate than conventional web security. MCP involves three entities: the user, the LLM provider (e.g., Anthropic or OpenAI), and the service provider (e.g., GitHub or Google Drive). While traditional web authentication effectively manages two-party interactions, MCP necessitates considering all three simultaneously.
Wallkötter elaborated on the complexity: “Which component authenticates what? Is it Anthropic communicating with GitHub that is being authenticated? Or is it the user who is actually authenticating?”
Autonomous agents further complicate this scenario. If a user directs a travel agent to book a trip, and the agent then interacts with multiple MCP servers without direct user supervision, determining responsibility for those actions becomes unclear. Is it the agent’s developer, or the user who initiated the request? This issue presents technical, legal, and ethical challenges that the industry is still addressing.
The Prompt Injection Problem
Beyond authentication, MCP deployments encounter another security issue without a definitive solution: prompt injection. This vulnerability enables malicious actors to manipulate AI behavior by creating inputs that bypass the system’s original instructions.
Wallkötter likened this to an earlier web security problem. He observed, “It somewhat resembles the old SQL injection era.” In the early days of the web, developers often combined user input directly into database queries, which allowed attackers to insert harmful SQL commands. The remedy involved separating query structure from data, employing parameterized queries that treated user input as data, not executable code.
Wallkötter proposed a similar solution: “The prompt itself would be sent first, followed by all the data intended for different parts of the prompt. A system would then preprocess this data before it reaches the LLM, checking for prompt injection attempts.”
Despite this potential method, a universally adopted solution is not yet available. LLM providers strive to train models to prioritize system instructions over user input, but these protections are still incomplete. Wallkötter admitted, “There are always workarounds because no method is entirely foolproof.”
The prompt injection issue impacts reliability in addition to security. When an MCP server provides data that becomes part of the LLM’s context, this data might contain instructions that alter the intended behavior. An AI agent following a specific workflow could be disrupted by unforeseen content in a response. Until this vulnerability is resolved, autonomous agents functioning without human supervision pose intrinsic risks.
The Tool Overload Trap
MCP’s simplicity inadvertently leads to a challenge. The ease of integrating new tools often results in developers incorporating numerous MCP servers into their applications. This proliferation demonstrably reduces performance.
Wallkötter noted that “suddenly, 40 or 50 percent of the context window is occupied by tool definitions from the outset.”
Every tool needs a description detailing its function and parameters for the LLM. These descriptions use up tokens within the context window, which is the finite space where the model stores all pertinent information. If tool definitions consume half of the available context, the model has less capacity for conversation history, retrieved documents, or other vital data, leading to predictable performance degradation.
Beyond context window limitations, an excessive number of tools can confuse the model. Current LLMs find it difficult to differentiate between similar tools when given many options. Wallkötter mentioned, “The current internet consensus suggests that around 30 tools is the practical limit,” indicating the point where model performance significantly declines.
This constraint has architectural consequences. Developers must decide whether to create a single large agent with broad capabilities or several smaller agents with specialized tool sets. The decision partly hinges on context needs. Wallkötter provided a striking comparison: “Most effective agents today have about 200,000 tokens in their context window, which is roughly equivalent to the entire novel Pride and Prejudice.”
This “Jane Austen metric” offers an understandable scale. If an agent requires extensive business context, formatting rules, project history, and other background data, this accumulated information can rapidly consume a significant portion of the available space. Incorporating 30 tools on top of such context might render the system ineffective.
The solution frequently involves thoughtful agent architecture. Instead of a single, all-encompassing agent, organizations could deploy specialized agents for specific tasks: one for travel planning, another for email management, and a third for calendar coordination. Each agent would maintain a focused tool set and clear instructions, thereby avoiding the complexity and confusion of an overly broad general-purpose agent.
When Not To Use AI
Wallkötter’s background in robotics offers a unique perspective for assessing AI implementations. His PhD research on humanoid robots highlighted a recurring difficulty: identifying stable applications where humanoid designs genuinely outperformed simpler options.
He described humanoid robots as being in an “unstable equilibrium,” a physics concept. A perfectly balanced upright pendulum could theoretically stay upright indefinitely, but even a slight disturbance would cause it to fall. Humanoid robots encounter similar issues. Despite their intriguing nature and impressive capabilities, their complexity is often hard to justify when simpler alternatives are available.
Wallkötter questioned the necessity of the humanoid configuration, stating, “You can remove the legs and replace them with wheels. Wheels are significantly more stable, simpler, cheaper to construct, and more robust.”
This line of reasoning directly applies to contemporary AI agent deployments. Wallkötter recently observed a sophisticated AI coding system featuring an agent specifically tasked with identifying unreliable tests within a codebase.
Wallkötter recounted asking, “Why use an agent and an AI system with an LLM to determine if a test is unreliable? Couldn’t you simply run the test ten times and see if it both fails and passes, which defines an unreliable test?”
This trend is prevalent throughout the industry. Teams often deploy AI for problems that have simpler, more dependable, and more economical solutions. The appeal of advanced technology can overshadow straightforward alternatives. An LLM-based solution might consume substantial computing resources and still sometimes fail, whereas a deterministic method could resolve the issue immediately and reliably.
This insight goes beyond individual technical choices to broader strategic considerations. MCP’s adaptability simplifies the integration of AI capabilities into existing workflows. However, this ease can result in automatic AI adoption without thoroughly evaluating whether AI genuinely adds value for a particular task.
Wallkötter posed the question of whether AI is truly the optimal path or merely a trendy technology applied indiscriminately. This question warrants careful thought before allocating resources to AI-driven solutions.
The Job Market Paradox
The discussion unveiled an unforeseen perspective on AI’s effect on employment. Wallkötter initially thought AI would enhance, not replace, workers, consistent with historical technological shifts. However, recent observations have made this view more complex.
Wallkötter conceded, reflecting on his prior forecasts. When AI first captured widespread attention, an industry adage circulated: “AI won’t replace you; a person using AI will.” Wallkötter initially agreed, drawing comparisons to past technology adoption patterns.
Wallkötter observed that historical resistance to new technologies, like the typewriter, eventually gives way to widespread adoption. He noted, “Fast forward a few decades, and everyone uses computers.”
This cycle of initial opposition followed by universal acceptance appeared to extend to AI. The crucial difference lies in whether the automated work belongs to a fixed or expandable pool. Software engineering exemplifies the expandable category. Wallkötter explained, “Previously, if you received a ticket from your system, you would program the solution, submit a merge request, and then move to the next ticket. That process can now be expedited, allowing for more tickets to be completed.”
The time saved on maintenance tasks does not remove the need for engineers. Instead, it alters their time allocation. He observed, “All the time saved from reduced maintenance can now be dedicated to innovation. This results in a shift in time spent between innovation and maintenance, with the innovation pool expanding.”
Customer support, however, presents a contrasting scenario. Wallkötter explained, “There’s a finite number of incoming customer cases, and most companies don’t typically innovate in their customer support approach. Their goal is resolution, enabling customers to find answers and have positive interactions with the company. That’s generally the extent of it.”
The difference is clear. In customer support, the workload is dictated by incoming requests, not by team size. If AI can efficiently manage these requests, the outcome is straightforward: “Where four people were once needed, now there’s only work for one.”
This distinction between expandable and fixed workloads could determine whether roles are displaced or transformed. This pattern extends beyond these two instances. Roles where increased efficiency generates opportunities for more valuable work seem more robust. Conversely, roles with externally limited work volume and no emphasis on innovation face higher risks.
Wallkötter’s updated viewpoint recognizes a more intricate reality than simple narratives of augmentation or replacement. The key is not whether AI replaces or augments jobs, but which specific characteristics of a role dictate its future. This necessitates evaluating the nature of the work, the limitations on its volume, and whether efficiency improvements lead to expanded opportunities or a reduction in staffing requirements.
The Path Forward
MCP’s swift adoption highlights the AI industry’s demand for standardization and interoperability. The protocol effectively resolved a genuine issue with enough simplicity to foster broad implementation. However, the difficulties arising from this adoption reveal the field’s nascent stage in crucial aspects.
Security issues related to authentication and prompt injection demand foundational solutions, not merely incremental fixes. The industry must create strong frameworks capable of managing the distinct three-party interactions of AI agents. Without such frameworks, enterprise deployments will involve considerable risks.
Both the tool overload issue and the fundamental question of AI application highlight the need for more rigorous system design. The ease of adding tools should not lead to their indiscriminate inclusion. Organizations ought to assess whether AI offers substantial benefits over simpler options before adopting intricate agent architectures.
Wallkötter’s viewpoint, shaped by his experience in both academic robotics and commercial AI development, stresses the significance of identifying “stable use cases” instead of pursuing technological prowess for its own sake. The precarious balance of humanoid robots serves as a warning: impressive abilities hold little value without practical applications that warrant their complexity and expense.
As MCP continues to evolve, with Anthropic and the wider community tackling security, scalability, and usability issues, the protocol will probably remain a core component of AI tooling. Its effectiveness in resolving these challenges will greatly impact the speed at which AI agents transition from experimental use to dependable business infrastructure.
The discussion ultimately circles back to a straightforward yet profound question: Is building something with AI always the right choice, simply because it’s possible? Answering this requires an honest evaluation of alternatives, careful consideration of costs and benefits, and resisting the urge to apply fashionable technology to every problem. MCP offers robust capabilities for integrating AI with the world. Employing these capabilities judiciously requires the same meticulous engineering that brought the protocol into existence.
