Over the past period, many people have asked me for my views on MCP (Model Context Protocol, a data interaction protocol that provides context information to large models). My answer is that it is similar to an API but more flexible: because APIs are usually provided by the service provider (officially), MCP is more like a "plug-in" or "mod" (it can be used without the service provider's consent; the term "game cheat/plug-in" is actually more appropriate).
On the surface, through MCP, external information can be provided to the model as context at a very low cost. Conversely, the model can directly operate or change the provider of the external information (which could be an application, an operating system, or any other carrier).
A game plug-in is probably the most suitable way to explain MCP: through the plug-in (MCP), real-time information in the game can be given to the model. After analysis, the model sends instructions back to the plug-in, and the plug-in then controls the game to execute those instructions.
So, what is the role of MCP? It provides a standard data interaction method (protocol). As long as you follow the protocol, you can achieve functional expansion quickly and at a low cost.
Therefore, three questions: Who wants to use MCP? Is there a barrier to entry for MCP? What is the fatal flaw of MCP?
1. Who wants to use MCP?
Model users and model or tool providers.
Through MCP, users can complete various tasks within a model application. For example, one could browse and organize local files within the Claude app, or interact with tools like Figma or Blender. The benefits are obvious: first, there is no need to switch applications; second, the cost of use is extremely low (users only need to pay the monthly subscription fee for applications like Claude, rather than paying by usage through model API calls).
For model providers (such as Claude) and tool providers (such as Cursor), this clearly turns their applications and tools into traffic portals. Of course, the trade-off is that the more plug-ins integrated, the stronger the user stickiness, but the more money Claude and Cursor lose. This is why Claude introduced a $100/month subscription option, and Cursor is "striving" to guide users toward "usage-based billing" (for example, by slowing down the response speed of the Claude model for monthly subscription users).
2. Is there a barrier to entry for MCP?
It is perhaps the one with the lowest barrier to entry among all the widely circulated English acronyms we've heard (to be safe, let's say "one of the lowest").
Even as the developer that released this protocol specification, Anthropic (the parent company of the Claude model) hasn't established any real barriers, or rather, it hasn't done the work that would actually constitute a high barrier.
3. The fatal flaw of MCP: Security
Game developers spare no effort in cracking down on "plug-ins." The most important reason is, of course, that they destroy the game's "economic system" and undermine the foundation of the ecosystem's balance. However, another equally fatal reason is security.
MCP is similar to an API, but it is not an API. The biggest difference is that an API is provided by the application and service provider. Security requirements are aligned with the provider's interests, so providers will spare no effort to ensure security while protecting the interests of both users and themselves.
The biggest characteristic of MCP not being an API is that MCP is "ownerless." You can download a piece of code from GitHub, deploy an MCP, and open a "backdoor" for your own operating system—or you can build one yourself. Yes, the protocol is standard, but its usage is extremely "free."
In fact, the very existence of MCP demands maximum freedom of use.
Behind this lies a massive security flaw. While security relies heavily on technology, the most important link in any security system is "subject responsibility."
MCP is "ownerless." In a standalone environment, it is like opening a bunch of "backdoors" on a local machine that can freely control the machine. In an internet environment, it means various pieces of sensitive information are flying everywhere—if not fully exposed, then at least half-exposed.
And this is almost unsolvable.
I always applaud "outside-the-box" technical ideas; as soon as MCP came out, I knew it was a good thing. However, I also feel angry and helpless regarding the promotion that ignores "user suitability," especially the "hype" from various self-media outlets.
To get back to the point, the most important factor in the development of AI remains the progress of base models. The reason large models are shocking is that in the digital world after the Transformer, machines have their own "worldview" and operational logic. Those crude methods of interfacing the real world with them might all be wrong, or even harmful.
A previous example was "thinking models": "humans are too conceited," thinking that by telling the model their own problem-solving process, the model could then "think independently." As I've said before, that digital world is one we don't understand, so we naturally cannot force our processes upon the machine.
The current example might be MCP—charging ahead without considering any risks or principles of suitability.