If it greatly facilitates the connection between the LLM and the applications of the real world, the MCP still has great progress to make.
If it has become popular in the many demonstrations of solopreneurs on social networks, the use of MCP in the professional framework is still confidential. Scalability, security, maturity … Here are the main limits.
Scalability constraints
This is the great limit of the protocol. And Justin Spahr-Summers, member of the anthropic technical staff recognizes it without any detour: “MCP is currently a stateful protocol, which is limiting for server-free deployments, creating an obstacle to its wider adoption.” Very concretely, each interaction between the LLM and a tool via MCP is based on a persistent session, which prevents any flexible distribution of requests between several servers. It is therefore impossible to deploy MCP in a Serverless environment. Each client must be, by design, connected to the same server on the whole of its session. Maintaining the context which therefore increases the server on the resources, especially in a wide deployment with many users.
Similarly, the size of the LLM context windows being finished, using several tools simultaneously within the same conversation (example: Google Calendar, Gmail, File Reader …), it is easy to quickly reach the limit (200,000 tokens for Claude 3.7 Sonnet). Even if the window is not entirely reached, overloaded windows often give rise to degraded performance. The arrival of context windows to 10 or 100 million tokens (and even possibly infinite) could however partially solve the problem. However, there will still be many optimizations of inference to limit high -context usage costs.
Finally, due to constraints of material resources and the many iterations between the model and the tools, the MCP often requires greater latency than a simple and well -optimized API call.
A lack of maturity, and therefore of adoption
Unveiled less than a year ago by Anthropic, the Context Protocol model remains little adopted by the industry. If there are a few official MCP servers (Azure, AWS, Cloudflare, Elevenlabs, Stripe, etc.), the majority of developments come from the community. Few are the big publishers to deploy time and money, for the moment. On the MCP client side, Claude Desktop is still one of the main entrance doors. OPENAI supports for example only the protocol via its SDK agents before a deployment in the Desktop application. Finally, Hugging Face recently offers a local customer to support their local inference. Customer implementations that are still too few and dismiss many developers of third -party solutions.
On the model side also, the choices are few. For effective use, MCP requires robust LLM, with the Calling function. In other words, the model must have been specifically trained (tuning instruction) to respond to the expected format and avoid errors. The start-up Giskard has also unveiled, in its flagship benchmark, a classification of models that best respond with the tools. And the latter are not legion: only four out of 17 models tested obtain a score of 75% or more (including a majority of anthropic models, quite logically). A lack of mature development on the server side, customer and model which still prevents many companies from embarking on the MCP.
Security limitations
This is the other major limitation of the MCP, security. Alternative and third -party MCP servers pose serious security problems, whether locally or in the cloud. Local, even if the server code is accessible in open source, a flaw may have been slipped voluntarily or not, directly exposing the data entered by the user and the other connected tools in the session. The explosion of amateur servers accentuates this phenomenon as much as it is impossible to review code on all open source servers.
According to a report by Hiddenlayer (specializing in AI cybersecurity), 16 servers publicly highlighted on the official protocol page contained one or more safety flaws. The latter could have involuntarily created prompt injection into the model and potentially exfiltrate data. On the remote server side, the problem is even more blatant: without access to the server code, it is necessary to trust its publisher 100%, in reverse of the Zero Trust procedures.
Finally, the MCP is still limited in its ability to be audited. Indeed, the protocol does not natively offer tools for monitoring interactions between the model and the different servers. It thus appears complex to go up the production chain in the event of a major incident or even a simple technical problem.
Despite everything, the MCP remains the most promising track of the moment to easily use real world applications with LLM. Its adoption should grow in the coming months. Over the updates, the protocol could support the Serverless (with current experiments), and new explanatory tools. On the security component, MCP has just received the support of OAUTH 2.0 to secure authentication between servers and customers.
