Let's be honest - everyone is talking about Model Context Protocol (MCP) as if it's the next big revolution in AI. Tech blogs are buzzing, conferences are filled with MCP panels, and developers are rushing to implement it. But here's my take: MCP isn't such a big deal. It's just another protocol in the evolution of agent tools.
Don't get me wrong - agent tools themselves are a huge deal and present significant security risks. But is MCP overhyped? Not necessarily. It's one implementation, one step in a much longer and evolutionary path. But we should also focus on how agent autonomy is increasing and what that means for developers and security professionals.
In this article, I'll take you through MCP, discuss the real risks of agent tools (regardless of protocol), and explore where we're headed next with protocols like x402, which are currently flying under the radar but might actually be more revolutionary. I'll share both the developer perspective and the security angle—two stories that need to be told together to understand the full picture.
The Developer Story: Evolution of Agent Tools
Let's rewind a bit and look at how we got here. In the old days (and by old, I mean just a couple of years ago), if you wanted your AI agent to use some tool - let's say a web search capability - you needed to create an account with a provider, put in your credit card, get an API key, and then write custom code to integrate that specific tool. Each tool required its own custom connection, its own dependencies, and its own integration code. It was a mess of spaghetti code and configuration.
Then came MCP. Suddenly, all these servers could align to a common protocol for communication. Now I can have one MCP client with API keys for each tool. Is it better? Absolutely. Is it revolutionary? No, but it’s important and effective progress. I still need to configure each tool in my MCP client, which is a lot of overhead. It's way better than writing custom code or installing dependencies for each tool, but it's just one step in the evolution, not the destination.
What MCP really did was standardize how agents talk to tools. That's useful, but it's not the game-changer everyone makes it out to be. It's just a natural progression in how we build agent systems. The real story is about increasing agent autonomy, not about the specific protocols they use to communicate.
Think about it this way: an LLM on its own is autonomous in a limited sense - it can generate text, but that's about it. Add
But even with MCP, I'm still the bottleneck. I have to configure all those tools, manage all those API keys, and decide which tools the agent can access. The next evolutionary step is removing that bottleneck, and that's where things get really interesting.
The Security Story: The Real Risks of Agent Tools
Here's where things get serious. From a security perspective, it's not MCP itself that's the problem - it's the scale that agents can now achieve. And every step up in this scale means exponentially more risk. We're not talking about 10% more risk, we're talking about 10 times more risk with each evolutionary step.
When my agent goes to the web, there are tons of risks out there. But the real danger is that the agent brings all those risks back home - all the misinformation, the prompt injection vulnerabilities, the biases, both the security and safety issues. Then it makes decisions based on that potentially compromised information about what to do with my databases, my systems, my business.
Let me give you a concrete example of what can go wrong. Say I have an agent that can access our company's database through a tool like Redash. I ask it to go to a Wikipedia page about some topic, pull information, understand how it works, and then create a Jira ticket based on that information, pulling some relevant data from our database.
Sounds innocent, right? But what if someone has inserted hidden content in that Wikipedia page? Content you won't even see as a human because it's hidden behind text, using emojis or invisible characters. The agent might see and process this hidden content, which could contain malicious instructions. Suddenly, my agent is running code on my servers—potentially malicious code—all because it visited a webpage.
This isn't a theoretical risk. This is happening right now. And it's not MCP that's the problem - it's the fact that agents can now access tools at all. MCP just standardizes how they do it.
Think about it like this: if you have two employees, you can train them to be security-conscious. If you send them an email with cute cats and puppies but containing malware, they probably won't click on it. If you have 100 employees, one will probably click on it. With agents, we're heading toward having an infinite number of "employees" - the chance that one of them gets compromised approaches 100%.
The more autonomous our agents become, the more this risk increases. And protocols like MCP are just accelerating this trend by making it easier to connect agents to more tools.
Beyond MCP: The Next Evolution in Agent Protocols
While everyone's obsessing over MCP, there's something even more interesting happening that's flying under the radar. After MCP flourished, it inspired more protocols like A2A (Agent-to-Agent) and
So, what is x402? It's a protocol developed by Coinbase that helps agents access APIs and agent tools with a "pay as you go" model. Think of it as the HTTP moment for payments - a standard for internet-native payments that could change everything about how agents operate.
Here's why it matters: With x402, instead of configuring each MCP server and tool individually, you can just give your agent money and let it find and use the tools it needs. It's a massive leap forward in agent autonomy.
The protocol is built on USDC, a cryptocurrency stablecoin that's always worth exactly one US dollar. Unlike Bitcoin with its volatility, USDC maintains a consistent value, making it perfect for automated, programmatic payments. This means agents can make real-money transactions in the world without human intervention.
This protocol actually existed before in a primitive form, but it was poorly implemented, so nobody used it. Now, Coinbase has fixed it, built it on crypto, and major players like Stripe, Anthropic, and AWS are getting involved. It's a big deal, even if most people haven't realized it yet.
From a developer's perspective, this changes everything. Instead of the current headache of configuring each tool in my MCP client, I can just fund my agent and let it handle the rest. It becomes more autonomous, more capable, and closer to a human assistant than ever before.
Let me put this into perspective: an LLM is autonomous, but it can only write text. An agent with RAG can read your data. An agent with tools can take actions like searching the web or sending emails. But an agent with x402 can find and use tools you never even configured for it. Each step brings us closer to truly autonomous systems that can operate independently in the world.
Balancing Innovation and Security
So, where does this leave us? We have MCP, which is useful but overhyped. We have emerging protocols like x402 that could fundamentally change how agents operate. And we have serious security concerns that grow with each step toward greater autonomy.
The reality is that we need everyone to be aware and start working on security processes now, not after the next big breach happens. But here's the key: security can't block innovation. We can't just throw up our hands and say "this is too dangerous" because the technology is moving forward whether we like it or not.
What we need are automated security processes that don't slow down development. Tools that automatically approve or disapprove agent actions based on risk profiles. Systems that can detect when an agent has too much permission and suggest separating it into different agents with more limited access. Scanners that can identify potentially malicious MCP servers before they're integrated.
If your agent has access to both web browsing and your database, that's a risk vector. Maybe those functions should be handled by separate agents that communicate with each other through controlled channels. If your agent can execute code and also has payment capabilities, that's another risk vector that might need to be separated.
The future I see is one where security is built into the development process from the beginning, including the application’s prototyping, not bolted on as an afterthought. We have automated tools that help developers make secure choices without slowing them down, where we can embrace the power of increasingly autonomous agents while mitigating the very real risks they present.
MCP isn't the revolution - it's just one step in an ongoing evolution. The real revolution is happening in how we think about agent autonomy and how we secure these increasingly powerful systems.
The future of agent tools is incredibly exciting, but it's also fraught with risk. Let's make sure we're talking about both sides of that coin, not just the shiny new protocols that make for good conference presentations.
- Written by Bar-El Tayouri, Head of Mend AI at Mend.io
