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.
Still don't get what's the advantage over just adding a special API key or a wrapper cli or whatever mechanism that achieves all of that without being a "protocol" and with all the context bloat. Like the github cli is a good example. You give it proper auth keys etc. and for sure there's some telemetry in there about usage as well. If there isn't then it's easy to do from the api side too.
Even if you don't own the code or infra, like say a frontend team who wants models to test out the backend apis and do something. Well in that case how do regular devs do it? Do they also get unfettered access in the past? Surely there's still some mechanism you can repurpose for agents to use?
I'm not trying to argue I'm just saying I didn't catch on the first time mcp was a thing and I still don't know what it's doing now.
If a full coding agent can access a CLI tool. that agent can almost certainly access the API keys being used by that tool. They can go as far as decompiling binaries, or rewriting them to log the key before it is used.
If you are worried about a prompt injected agent stealing your keys, that's a problem.
(There is a way around that: you can use an HTTP proxy that inserts those credentials but otherwise lives outside of the agent's realm of influence. MCP is a whole lot easier though.)
> If a full coding agent can access a CLI tool. that agent can almost certainly access the API keys being used by that tool.
So, don't do that then?
Why do you need to use a full coding agent as the interface between the model and the CLI tool?
A 10-line program can do the wrapping of any existing CLI program so that environment is not leaked to the model, while providing the CLI program with the environment as well as restricting what programs can be called to a whitelist.
If you CLI program is echoing its keys in the response, or the endpoint is echoing keys back, that's not a problem that can be solved with MCP anyway.
So you're building a custom harness here that provides tools, and you're wiring up your custom harness to effectively do a subprocess execution of a CLI script for every tool call the model request?
One reason to switch to MCP here would be to avoid the overhead of forking a new process for every tool call, and to enable maintaining state between tool calls.
(That performance overhead is so trivial as to not be worth caring about, but the state thing may be useful - keeping a stateful browser session running between tool calls is harder with a CLI, for example.)
> So you're building a custom harness here that provides tools, and you're wiring up your custom harness to effectively do a subprocess execution of a CLI script for every tool call the model request?
Well, yeah. Subprocess execution is on the order of double-digit milliseconds. The "wiring up" is maintaining a whitelist of what tool commands map to which executable. It's a lookup table with very little maintenance required.
> One reason to switch to MCP here would be to avoid the overhead of forking a new process for every tool call, and to enable maintaining state between tool calls.
I feel like I am taking crazy pills :-/
The overhead of forking, on the ancient machine I call my desktop, is at most double-digit milliseconds. The state isn't being tracked by the MCP server anyway, it'll be tracked by the harness and/or the model, no?
My main reason for adding MCP support is so that existing callers that want to use my WebApp(s) can just use it without needing any changes on their side.
IOW, I am going to add it at some point, but not for the reasons you give. I'll add it to be compatible.
You didn't address my comment about state. If you're driving something like Playwright you need a way to maintain state between tool calls.
(Oddly enough I did solve that with my own CLI tool for running browsers during my "who needs MCP" phase, but it's a bit of a nasty hack that involves leaving files with PIDs lying around: <a href="https://github.com/simonw/rodney#directory-scoped-sessions" rel="nofollow">https://github.com/simonw/rodney#directory-scoped-sessions and <a href="https://github.com/simonw/rodney/blob/a842432246f39775ccb14f0de72565b2c216b5b6/main.go#L81" rel="nofollow">https://github.com/simonw/rodney/blob/a842432246f39775ccb14f...)
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.
podocarp · · focus · HN ↗
Even if you don't own the code or infra, like say a frontend team who wants models to test out the backend apis and do something. Well in that case how do regular devs do it? Do they also get unfettered access in the past? Surely there's still some mechanism you can repurpose for agents to use?
I'm not trying to argue I'm just saying I didn't catch on the first time mcp was a thing and I still don't know what it's doing now.
simonw · · focus · HN ↗
If you are worried about a prompt injected agent stealing your keys, that's a problem.
(There is a way around that: you can use an HTTP proxy that inserts those credentials but otherwise lives outside of the agent's realm of influence. MCP is a whole lot easier though.)
lelanthran · · focus · HN ↗
So, don't do that then?
Why do you need to use a full coding agent as the interface between the model and the CLI tool?
A 10-line program can do the wrapping of any existing CLI program so that environment is not leaked to the model, while providing the CLI program with the environment as well as restricting what programs can be called to a whitelist.
If you CLI program is echoing its keys in the response, or the endpoint is echoing keys back, that's not a problem that can be solved with MCP anyway.
simonw · · focus · HN ↗
One reason to switch to MCP here would be to avoid the overhead of forking a new process for every tool call, and to enable maintaining state between tool calls.
(That performance overhead is so trivial as to not be worth caring about, but the state thing may be useful - keeping a stateful browser session running between tool calls is harder with a CLI, for example.)
lelanthran · · focus · HN ↗
Well, yeah. Subprocess execution is on the order of double-digit milliseconds. The "wiring up" is maintaining a whitelist of what tool commands map to which executable. It's a lookup table with very little maintenance required.
> One reason to switch to MCP here would be to avoid the overhead of forking a new process for every tool call, and to enable maintaining state between tool calls.
I feel like I am taking crazy pills :-/
The overhead of forking, on the ancient machine I call my desktop, is at most double-digit milliseconds. The state isn't being tracked by the MCP server anyway, it'll be tracked by the harness and/or the model, no?
My main reason for adding MCP support is so that existing callers that want to use my WebApp(s) can just use it without needing any changes on their side.
IOW, I am going to add it at some point, but not for the reasons you give. I'll add it to be compatible.
simonw · · focus · HN ↗
(Oddly enough I did solve that with my own CLI tool for running browsers during my "who needs MCP" phase, but it's a bit of a nasty hack that involves leaving files with PIDs lying around: <a href="https://github.com/simonw/rodney#directory-scoped-sessions" rel="nofollow">https://github.com/simonw/rodney#directory-scoped-sessions and <a href="https://github.com/simonw/rodney/blob/a842432246f39775ccb14f0de72565b2c216b5b6/main.go#L81" rel="nofollow">https://github.com/simonw/rodney/blob/a842432246f39775ccb14f...)
silbercue · · focus · HN ↗
[dead]
jimbokun · · focus · HN ↗
We have reached the point where we need to control agent access the same way we control human access to systems.