> This article entirely misses the value that MCP brings today.

Well, me too. I see the only advantage over a CLI app being an agreed-upon convention for syntax (not semantics).

I have a CLI interface to my webapp, not an MCP.

> If you want to operate something that's less YOLO than that, you'll find yourself wanting:

> 1. Control over exactly which external services it can access

Access control is not built into my CLI, it's built into the WebApp.

> 2. A way to handle authentication that doesn't allow the agent to directly access API keys

My CLI takes credentials from the environment, which it uses to talk to endpoints. The caller sets the environment, then calls the CLI program. The caller provides no way for anyone sending it input (the Model) to request or retrieve environment variables.

> 3. A sensible UI to allow users to connect and authenticate further services

The parts of my WebApp that relays or re-requests to other third-party services handles access control.

> 4. Strong audit logging for what's going on

Not sure what this is supposed to mean: the WebApp already has auditing logs.

> MCP makes all of that so much easier to provide.

Sure; I'm considering writing a purely deterministic shim for MCP around my CLI. The semantic/information is the same, the only difference is syntactical in nature.

> Thinking MCP is obsolete because full coding agents don't need it misses out on all of the other things we might want to build.

It may as well be; coding agents are at one end of the control spectrum - run in bash, do anything/everything (so they can leak credentials to the model, or the harness). But a CLI app doesn't have to allow bash. My "harness" (using the term very loosely) can securely call other programs without giving its own caller a RCE via bash.