Is the MCP Protocol Dying or Evolving?
 |
Is the MCP Protocol Dead or Just Growing Up?
This discussion has been going on among engineers since late 2024. But in March 2026, Perplexity CTO Denis Yarats said that he was backing away from it. Soon after, YC CEO Garry Tan also came out with criticism. He said that it was a huge memory hog and that he had created a replacement for it in just half an hour. With that, the talk spread everywhere that the MCP story was over.
| Key Takeaways: |
|---|
|
What is MCP? Why Did Everyone Go After It?
- Without MCP, it guesses the API and may fail
- With MCP, it follows a preset format and works correctly
When it first started, everyone was excited. Companies were racing to show that they were in it. MCP servers were very busy. SDK downloads were doubling every week. All the major companies, including OpenAI, Google, and Microsoft, were on board.
But when people started using it, situations changed.
Criticisms: Is it Just Noise or Valid?
- Context Window Usage: Just connecting three servers consumes a large portion of the available tokens. It was found that more than 72% of the memory is used for this before the work starts.
- Decreased Accuracy: When many tools are given at once, the AI’s attention shifts, and mistakes are made. Studies show that tool selection accuracy drops from 43% to below 14% as the number of tools increases.
- Difficulty in Testing: If there is a problem, it is very difficult to find it. If it is a normal command (CLI), we can test it directly in a terminal, but in this case, we have to debug the JSON-RPC layer and tool schemas.
But some see it differently. While it may not be enough for simple needs, MCP is the future for large companies. Because large projects need security and oversight rather than commands.
Many developers are expressing these views. Here are two such different opinions.
“Something goes wrong, and now I’m spelunking through JSON transport logs instead of just running the command myself. Debugging shouldn’t require a protocol decoder.”
— Eric Holmes, Infrastructure Engineer
“For enterprise and org-level use cases, MCP is the present and future, and teams need to be able to cut through the hype of the moment.”
— Charles Chen, Principal Software Engineer
Why CLI for Solo Developers?
CLI (Command Line Interface) is a great help for those who code alone. There is no doubt about it. Because these AI models we use have been trained on millions of documentation pages, shell scripts, and Stack Overflow discussions. We don’t need to explain anything in particular. These models already know what standard commands are and how they work. And if there is a cost to it, we only need to pay for it according to what we use (pay-per-token).
The Feishu (Lark) team at Bytedance has long recognized this. They have released an official Lark Agent CLI platform with over 200 commands and 22 agentic skills across many business areas, including Messenger, Docs, Base, Sheets, Slides, Calendar, Mail, Tasks, Meetings, and more.
Google has since made a similar move for Google Workspace CLI via the Gemini Tools update in late 2025. In short, this approach of combining CLI and context-aware skills is now catching on.
But here’s the twist…
If you have tools that are used only in your company, for example, a custom deployment API or data pipeline, this CLI magic won’t work there. Because the foundation model has no idea what these private tools are.
Whatever happens in the end, you’ll have to write documentation and JSON schemas about it all over again. Doing all this without a central control or a clear structure, like a unified protocol, can be a huge headache.
A Gentle Warning
There’s a common trend in the tech world. Once the hype dies down, it’s dead. MCP indeed has some issues right now, but that doesn’t mean it’s a total failure.
If you look at a lot of the current discussions, you’ll see that most of it is from individual developers speaking for their own convenience. These people may have a lot of influence on social media, but their words don’t necessarily reflect what a large engineering team needs.
For example, we saw the outages at Amazon’s AWS in early 2026. After that, they had to insist that changes made using AI be reviewed by senior engineers. It was a reminder that leaving AI agents without proper control at the organizational level can be a big deal. After the setback there, more oversight came, not less regulation.
In short, what can be done by one person in a controlled environment is not necessarily possible in a team of people with different skills. Especially when maintaining production-level software using AI!
Read: Who is Responsible for Testing AI-Generated Code?
Why Should Testers Care?
Testers are not just spectators in these discussions. In fact, we are right in the middle of it.
The concept of the MCP server is of great importance, given the way testing infrastructure is changing today. AI agents are now connecting to test automation platforms like testRigor to call external tools, check the environment, check test coverage, and trigger pipelines. The performance, reliability, and auditing of these agents depend on the protocol they use.
- Do we want local flexibility or a centralized structure?
- Do we prefer individual speed or enterprise standards?
Our MCP integration and function calling support in testRigor are built with this exact challenge in mind. The goal is to enable AI agents to interact with the testing infrastructure in an auditable and trustworthy manner. In the future, these protocol layers will determine testing quality.
Is MCP Really Dead?
- For Solo Developers: CLI + Skills is often better, offering zero-schema overhead and higher token efficiency for quick, local iterations.
- For Enterprise Teams: Remote MCP servers are better, providing security, multi-user authentication (OAuth 2.0), and centralized policy enforcement.
These two are not mutually exclusive, but rather tools that are suitable for each situation. So instead of asking “Is MCP dead?”, we should ask “Are we choosing the right one for our team?”
What is the current state of your team’s AI agent infrastructure? If your testing relies on external tools, it’s time to examine their reliability, observability, and the context tax they impose on your context window.
AI-native testing at testRigor supports these evolving standards by treating each command as a callable tool. Whether you are optimizing for speed with local CLI-driven iterations or scaling with enterprise-grade MCP servers for complex, multi-agent orchestration, testRigor ensures agents interact with your infrastructure in an auditable way.
Beyond the Hype: How MCP is Moving from Social Media Debate to Real-World Test Automation
By analyzing real-time telemetry information from command logs and network traces, testRigor provides only the right information (selective context). This helps reduce the context tax and make self-healing using AI more accurate.
| Achieve More Than 90% Test Automation | |
| Step by Step Walkthroughs and Help | |
| 14 Day Free Trial, Cancel Anytime |
