This article entirely misses the value that MCP brings today.
Sure, there's almost no reason to use MCPs if you are running a full-blown terminal agent (Claude Code, Codex, Meta Muse, OpenClaw etc) with unfettered internet access - just let it call APIs directly.
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
2. A way to handle authentication that doesn't allow the agent to directly access API keys
3. A sensible UI to allow users to connect and authenticate further services
4. Strong audit logging for what's going on
MCP makes all of that so much easier to provide.
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.
> 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.
So you've built your own agent harness that allows the model to call only your CLI but doesn't allow the model to run "env" and view the environment variables itself?
Sounds to me like MCP with a slightly different interface.
> So you've built your own agent harness that allows the model to call only your CLI but doesn't allow the model to run "env" and view the environment variables itself?
Yes, with the difference being it can call other CLIs, just not arbitrary CLIs.
> Sounds to me like MCP with a slightly different interface.
It is, except that it is not limited to being called from harnesses. Also usable from bash (automated scripts), or even humans if hey want to run it on the command-line.
TBH, my webapp(s) had this prior to 2020, because it made automation simpler so I could write shell scripts to do various things on the WebApp.
I did end up building my own CLI for calling MCPs, mainly to better understand the protocol but also to make them easier for me to interactively debug: <a href="https://github.com/simonw/mcp-explorer" rel="nofollow">https://github.com/simonw/mcp-explorer
simonw · · focus · HN ↗
Sure, there's almost no reason to use MCPs if you are running a full-blown terminal agent (Claude Code, Codex, Meta Muse, OpenClaw etc) with unfettered internet access - just let it call APIs directly.
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
2. A way to handle authentication that doesn't allow the agent to directly access API keys
3. A sensible UI to allow users to connect and authenticate further services
4. Strong audit logging for what's going on
MCP makes all of that so much easier to provide.
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.
lelanthran · · focus · HN ↗
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.
simonw · · focus · HN ↗
Sounds to me like MCP with a slightly different interface.
lelanthran · · focus · HN ↗
Yes, with the difference being it can call other CLIs, just not arbitrary CLIs.
> Sounds to me like MCP with a slightly different interface.
It is, except that it is not limited to being called from harnesses. Also usable from bash (automated scripts), or even humans if hey want to run it on the command-line.
TBH, my webapp(s) had this prior to 2020, because it made automation simpler so I could write shell scripts to do various things on the WebApp.
simonw · · focus · HN ↗