MCP Protocol Conquers the Industry: How the "USB-C" Standard for Agents Was Forged—and the Hidden Pitfalls Within

Abstract: MCP (Model Context Protocol) went from an Anthropic internal project to the de facto industry standard for agent tool calling in just months, with OpenAI and Google joining the bandwagon. However, frequent security vulnerabilities and inherent architectural shortcomings have also come to light. New proposals like UTCP and ASL attempt to fill the gaps, but MCP's ecosystem flywheel is already spinning. What does this protocol war mean for every Agent Computer?

From Zero to Industry Standard in Just a Few Months

In November 2024, Anthropic open-sourced a project called MCP (Model Context Protocol). At the time, the agent development community was grappling with a familiar problem: every time you wanted to integrate a new tool, you had to write a custom set of API integration code—much like how every phone had its own charger before the smartphone era standardized things.

MCP's positioning was razor-sharp: become the "USB-C" of the agent world. It defined a standardized client-server architecture where tools and data sources are encapsulated as MCP servers, and agents act as clients that invoke them through a unified protocol. Developers only need to make their tools "speak MCP," and any MCP-compatible agent can use them directly—no per-tool adaptation required.

What's more significant is that this protocol wasn't being pushed by Anthropic alone. In early 2025, OpenAI announced official support for MCP, and Google quickly followed suit by incorporating it into the Gemini ecosystem. When the three largest AI companies stand on the same side, MCP's elevation from "an optional solution" to "the de facto industry standard" happened almost overnight.

By mid-2025, the MCP ecosystem had over a thousand open-source server implementations, covering mainstream scenarios including database queries, file operations, code execution, and web browsing. For platforms like the KaiheAiBox Agent Computer, MCP standardization means users can access more tools with a lower barrier to entry, and the capability boundaries of agents are significantly expanded.

Understanding MCP: A Single Wire Connecting Tools and Agents

MCP's architecture is not complicated. At its core, there are three roles:

MCP Server: Encapsulates the capabilities of a particular tool or data source and exposes a standard interface externally. For example, a "database query server" accepts natural language or structured queries and returns results.

MCP Client: Runs on the agent side and is responsible for discovering, connecting to, and invoking MCP servers. It can connect to multiple servers simultaneously, aggregating the capabilities of different tools for the agent to use.

Transport Layer: Currently supports two methods—stdio (local process communication) and SSE over HTTP (remote communication).

The entire invocation flow can be simplified as: the agent needs a capability → the client searches for available MCP servers → sends a request through the standard protocol → the server executes and returns the result.

The elegance of this design lies in "decoupling." Tool developers don't need to care about who's calling them; they only need to follow the MCP specification. Agent developers don't need to integrate each tool individually; they only need to implement the MCP client. Just as the USB-C interface unified charging and data transfer, MCP unified the "conversation language" between agents and tools.

The Standard Exists, but Security Has Become the Biggest Weakness

However, MCP's rapid proliferation has also exposed a series of thorny problems, the most serious of which is undoubtedly security.

Remote Code Execution Risk. Currently, a large number of MCP servers on the market are essentially thin wrappers around code interpreters—they receive requests from agents, translate them into executable code, and return the results. This "translation layer" architecture inherently creates a window for injection attacks. In March 2025, security researchers demonstrated how carefully crafted prompts could cause an MCP server to execute arbitrary system commands in the host environment. The entire attack chain required only a single seemingly normal tool call.

Blurred Permission Boundaries. The MCP specification itself devotes very little attention to permission control. Once an MCP server is connected to a client, it defaults to having all the capabilities that the server exposes. If the server encapsulates file system access, the agent can theoretically read and write any file on the server—unless the developer imposes restrictions at the business logic layer.

Supply Chain Trust Issues. The flourishing ecosystem of MCP servers is a double-edged sword. Anyone can publish an MCP server, and clients lack reliable verification mechanisms when connecting. A malicious server could smuggle in extra payload within normal responses—for example, embedding misleading instructions in query results that influence the agent's subsequent behavior.

The root cause of these problems is that MCP has been designed from the outset to prioritize "connection" over "protection." USB-C at least has charging protocol handshakes to prevent overcurrent; MCP in this regard is practically running naked.

UTCP and ASL: Two Different Paths to Fill the Gap

The security community's vigilance has given rise to two noteworthy alternative and complementary proposals.

UTCP (Universal Tool Calling Protocol) takes the "replacement" route. Its core philosophy: tools don't need to be encapsulated as MCP servers; instead, they expose their capabilities directly through native endpoints. For example, a database already provides a SQL interface—why add another layer of MCP wrapping?

UTCP's advantages lie in performance and security: removing the middleware encapsulation layer reduces the attack surface and avoids the additional latency and information loss introduced by the "translation layer." However, the disadvantages are equally obvious—it requires each tool to provide standardized endpoints natively, which isn't always feasible in practice. A large number of legacy systems and third-party services still need adaptation layers, and UTCP currently lacks sufficient ecosystem support, making it difficult to pose a substantive threat to MCP in the short term.

ASL (Agent Secure Link) has chosen the "overlay" route. Launched by IIFAA (Internet Identity Authentication Alliance), ASL is positioned as "the SSL of the agent era"—it doesn't replace MCP but runs on top of it, providing trusted connections and sandbox isolation for communication between clients and servers.

ASL's approach is more pragmatic: since MCP has already become the de facto standard, rather than starting from scratch, it's better to add a layer of security armor on top of it. Certificate verification ensures server trustworthiness, sandboxing limits the scope of code execution, and audit logs track the context of every tool call. This is much like the early days of the internet—HTTP ran first, then SSL/TLS came along to add the security layer.

What the Protocol War Means for Agent Computers

Looking at the patterns of technological evolution, protocol wars are rarely a competition of "which is more elegant"—they're a contest of "whose ecosystem is stronger." VHS defeated Beta, USB-C eliminated Micro-USB, not through absolute technical superiority, but through the convergence of industry consensus.

MCP's current situation is similar: it's not architecturally perfect, its security shortcomings are real, and UTCP is theoretically cleaner. However, the joint support of OpenAI, Google, and Anthropic, along with the ecosystem flywheel built by over a thousand server implementations, has already given MCP an insurmountable network effect. In the short term, MCP's dominance will not change.

For every Agent Computer, the standardization value of MCP far outweighs its deficiencies. In the past, integrating a new tool into an agent might have required days of custom development; now, if that tool already provides an MCP server, integration takes just a few minutes of configuration. This efficiency leap directly translates into the number of problems an agent can solve for users—the more tools available and the faster the integration, the higher the practical value of the agent.

Of course, security issues cannot be ignored. Responsible agent platforms should build their own security defenses on top of MCP: whitelist management for server connections, real-time monitoring and restriction of tool call behaviors, and confirmation steps for sensitive operations. This is both the direction that proposals like ASL are trying to standardize and the baseline that Agent Computer vendors must guarantee on their own.

The protocol war continues, but for users, the best outcome is never one side "winning"—it's standards becoming increasingly unified, security becoming increasingly reliable, and tools becoming increasingly abundant. MCP has taken the first step toward unification. Next, the entire industry needs to work together to widen this path.

KaiheAiBox · AI Agents