A Response to My MCP Blog
A Response to My MCP Blog
When I posted my blog to Hacker News, I didn’t expect it to get the response it did. Many people responded, and it was awesome to see how wrong people thought I was. Even Simon Willison took the time to point out I was wrong, and as a reader of his blog, it was a cool moment for me.
Coming back to the reason for this response, I will die on the hill that we should completely get rid of the Model Context Protocol (MCP), and most serious enterprises and users should start working on integrating well-built CLIs using their existing APIs over trying to build out MCP servers for their agents and products. Most of the pushback i recieved was to do with short term issues, while I am trying to make a argument for long term foundation of our agentic ecoystem. My previous blog was not polished as much as it could have been, and I aim to address that in this blog.
What People Pushed Back On
There were a lot of comments, but I think there were a few key areas of pushback on my opinion.
I think, rightly, people pointed out MCP is almost necessary for anything on-device where we can’t reasonably expect agents to have access to REPLs (read-eval-print loops) or shell-based execution environments. As an aside, a few hours after my post, Tobi Lutke of Shopify tweeted:
He talked about the MCP vs. CLI debate. He mentioned that it’s the wrong debate to have, and that we should really be talking about giving agents the capability for tool composition, but he also mentions that CLI + Bash does this already.
Another thing I didn’t think about, because usually I have my coding agents install my MCP servers for me, is the actual configuration of MCP servers and what it looks like when we switch over to CLIs. How do we make sure that agents still have access to the tools?
I concede these are problems, but not as large as people are making them out to be. Some of the most popular product releases recently, like Meta’s Muse or SpaceX AI’s GrokBot, run on the cloud. They provide agents with their own memory, storage, and compute. Even a browser for them to use. Completely isolated sandboxes that the agents can do whatever they want in. The power that giving agents access to their own computer is undeniable, and my assumption is that in the future we will be doing most, if not all, AI-based compute on the cloud. I think a lot of the productivity apps are just data-access interfaces with APIs; AI agents can call the APIs directly to get the info they need, and they do do that right now. We may never be able to shake MCP on-device, but I think it’s largely not going to matter.
Security concerns were also a major point of pushback. Simon Willison rightly pointed out that leaving secrets in the environment is a huge concern, and yeah this is a problem but not so big as people are really making it out to be. Some local MCP setups, require API keys in configration files, which agents with shell access could read. Other setups have systems to keep creds out of reach from agents, but that setup is not a pre requisite of MCP, we can easily do this for CLIs as well. A CLI can be just as secure as MCP. The protcol itself mentions that it cannot enforce authentication and its a responsibility of the implementer / user.
Audit and Logging concerns were next. I think any arguments involving audit logging and observability, in favor of MCP servers, are poorly thought out at best, and disingenuous at worst. Observability—logging, metrics, and tracing—is largely the responsibility of the API/MCP provider, in my opinion. Unless I’m running a custom MCP server that is designed to run on my device, I expect that if a third-party API provider cares, they will provide their own observability. I may not be understanding fully, but I don’t see why the MCP protocol offers anything better in this domain. We don’t need a whole new protocol for it.
The final area was to do with token wastage. I think this is reasonable, but we’re heading for a world where tokens become too cheap to meter, especially for all the common day-to-day use cases. At this point, most of us in the Western world don’t think about individual units of electricity or data usage; we can safely assume that we have practically infinite, and I see tokens being no different in the near term. New open-weight models are months behind and magnitudes cheaper. Token usage matters today, but I don’t think it is a good reason to keep MCP servers around forever.
Some More Reasons That MCP Is Bad
Since my last blog, I have had more thoughts on why the MCP protocol is a bad system for both MCP server providers and consumers.
If we look at it, MCP servers are effectively injecting tool instructions into an agent’s context (not maliciously, hopefully at least) and changing the way it behaves. Any updates that the provider makes can change how a consumer’s agent behaves, and vice versa, a consumer could change their prompts and make the MCP servers less effective. It’s a very unstable system if we think about it; there are sources of inconsistency across both provider and consumer.
MCP server providers end up building monitoring infrastructure and evaluation infrastructure to make sure that agents are able to use their servers properly. This isn’t even counting new model releases, which could change agent behavior entirely. I think the labs have done a pretty good job, and models have gotten smarter, so this isn’t an issue, but in my honest opinion, providers shouldn’t really need to have this responsibility of making sure, effectively, their tool instructions perform well. They should be providing data and tool definitions, including schemas. The agent owner should be responsible for fine-tuning and making sure that their external tools are used properly.
What Do We Do About It
I’ve mostly talked about what’s wrong with the current system but have not put forward any solutions. This was a common piece of criticism in my last post. To be honest, I didn’t think I had to. But to clear it up, here is what I think we need to do.
MCP Server Providers
They need to stop providing MCP servers. Build CLIs. Use common engineering practices to implement audit logging, observability, access control, and short-lived tokens for authentication. This will drastically reduce the scope of work they are doing, allowing them to focus on core product over building another access layer.
MCP Server Consumers
Consumers will need sandboxes that handle CLI isntallation, permissions and credentials themselves. For example if i want to give my agent access to Stripe’s API, i let it access the CLI installed on my machine, where i have a proxy running. My agent sees random tokens in the environment, but when the call is made, my proxy overrides it. I know Infisical has an agent-proxy product that does something similar as well. People are looking into this problem, and I am confident that it will be solved.
A cool thing that Muse is doing is the Secure Credentials system. They use credential surrogation to make sure that agents never see those credentials. I think this is a good system.
Hopefully, at the OS level, we see platforms release these types of proxy systems, which can automatically proxy calls with authentication credentials as the agent makes external calls. I imagine this will be one of the primitives that gets rolled out everywhere.
Wrapping Up
It was great seeing everyone tear apart my blog. It really sharpened my opinion, forced me to consider where I was wrong. I still maintain that directionally, I believe I am correct about MCPs, but at this point they have become embedded into our ecosystem, where I don’t think they will be removed quite so easily.