I think that's a fair argument. I'd push back a bit on that being unique to MCP. Agent browser (https://github.com/vercel-labs/agent-browser) handles persistent sessions just fine as a CLI.
Funny. Dealing with Kubernetes is my day job, and I can be equally critical of it. Pointing out absurdities is how we make things better, and that’s ok.
But they're not token efficient. Take the terraform example from the post. Plan JSON is massive. You're not saving tokens by using a Terraform MCP and shoving an entire plan into context. Composition allows for efficient token use.
Thanks for reading! And yes, if anyone takes anything away from this, it's around composition of tools. The other arguments in the post are debatable, but not that one.
I get it. This is coming from a place where I see MCP's being adopted, where CLI is (in my opinion) better. Particularly where you're already in a CLI environment, and tool composition is necessary. I'm sure there's plenty of folks that aren't operating in that environment.
Hi friends! Author here. This blew up a bit, so some words.
The article title and content is intentionally provocative. It’s just to get people thinking. My real views are probably a lot more balanced. I totally get there’s a space where MCP probably does actually make sense. Particularly in areas where CLI invocation would be challenging. I think we probably could have come up with something better than MCP to fill that space, but it’s still better than nothing.
Really all I want folks to take away from this is to think “hmm, maybe a CLI would actually be better for this particular use case”. If I were to point a finger at anything in particular, it would be Datadog and Slack who have chosen to build MCP’s instead of official CLI’s that agents can use. A CLI would be infinitely better (for me).
This will hopefully become obsolete in the near future. If you're on a recent MacBook (with TouchID), using the current version of Chrome, and using a website that supports the new WebAuthn standard (e.g. GitHub) then you get this for free; you can authenticate through TouchID.
Obviously, depends on your threat model. I'd argue that being physically coerced ends up being a pretty low risk for most people. If you're just looking for something better than storing private key material on a hard disc, sekey is a pretty great alternative to using Yubikey + GPG.
If you have a newer MacBook with TouchID, you can get similar benefits using https://github.com/sekey/sekey. Arguably better, because access is backed by biometrics (TouchID) so it's "something you are" (fingperint) + "something you have" (laptop) and quite a bit simpler than setting up GPG backend SSH keys.
I know this was probably well intentioned, but I can't shake the irony of how overly complex and over-engineered this is. If you're just starting out, please, please, please don't do this.
It's a pretty scary prospect, to the point that I have to imagine it's already happening to some degree. If a nation state wants a backdoor, what better way than to bribe the cash-strapped OSS maintainer of that little project that every company depends on.
It’s a pretty unfortunate state of affairs. Google/Microsoft/Amazon should be throwing money at these projects. It’s in their best interest if they use it.
General rule of thumb for secure package distribution:
1. Is the identifier mutable? Make sure it points to a content addressable identifier (SHA2), and sign that link.
2. Is it a content addressable identifier? Nothing to do.
When it comes to signing in git, signing tags is usually where you see the most value (mutable identifier that points to a git tree, which is content addressable).
You’re just trying to improve the trust in saying “Hey, v1.2 is this SHA digest”.