ejholmes

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.

Silly. All it needs is docs. No need to overcomplicate it.

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.

I always get a kick out of seeing MCP wrappers around CLI’s.

Great read. Thanks for sharing. 100% agree, `—json | jq` is where it’s at.

You're right, but it still doesn't mean MCP was a good design even in that space. We could've done better.

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.

> both are a method of tool calling, it does not matter which format the LLM uses for tool calling as long as it provides the same capabilities.

MCP tool calls aren't composable. Not the same capabilities. Big difference.

Neato! https://github.com/vercel-labs/agent-browser is a similar take here, and much better than the playwright MCP.

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.

Author here! Biggest difference is composition. MCP tools don't chain (there's people trying to fix that, but it's still true right now).

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”.

I wrote more about this in https://twitter.com/vesirin/status/1026807849970614273?s=21. Vulnerabilities in package managers is a scary thing.

If you have a recent MacBook, use https://github.com/ntrippar/sekey for SSH keys. Private key is stored in the built-in HSM (Secure Enclave) and access is controlled by biometrics (TouchID). You can do the same with a Yubikey, but it’s not quite as good because a) you can lose your Yubikey easily and b) there’s no biometrics.

Private keys stored on filesystems is an antipattern.

How does this differ from the existing "Message deletion/retention" feature that was present before this? Did the existing feature delete messages, but not keys? Is the old feature and the new feature combined, or are they still separate?

> Most important concept #1: DAG

Yes! Thank you! This needs to be banged into peoples heads when talking about build systems. Every time you add an edge, you're automating an otherwise manual task. Very important realization.

Been using (and paying for) Dashlane for a couple years now. I love it. The things I like the most:

1. Supports TouchID on my newer MacBook. 2. Supports generating OTP's, stored alongside the credentials.

Not sure if the competitors have these also. In general though, I've been a super happy Dashlane user.

Also https://github.com/remind101/ssm-env (pretty similar)

The first example uses recursive make, breaking the graph :(.

I'm not saying you can't use make (we did use make before we switched to walk), it's just more painful for non C/C++ build systems. All we really want from a build systems, is a generic tool for describing, and walking, a graph of dependencies.

https://github.com/ejholmes/walk can do most of this FWIW.

> That's probably very subjective, I find JavaScript, C++, PHP or Perl much worse :-)

Oh definitely. I actually like Makefile's, but in my experience, more teams have a deep familiarity with some programming language, than with Makefile syntax. I haven't met very many people who have read the GNU make manual, and know all the idiosyncracies around Makefile syntax.

Good question. It's not a concern of walk(1) itself, since it's impossible to generalize for every use case. walk(1) _always_ executes the target, but the target itself can decide whether it actually needs to do work. For a C project, you would just do something like this: https://github.com/ejholmes/walk/blob/master/test/111-compil....

That's a trivial example using mtime. You could replace it with a hash function if you wanted.