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.
I feel like this would build a false sense of security.
Authentication and access controls must be able to withstand an agent with full shell access. And auditing must be on the server side to provide a full picture of all activity from all clients, whether human or agent.
We must treat agents as clever humans and secure and audit data access accordingly. The era of thinking we can handle agent access to sensitive information differently from human access has passed.
My point about MCPs here is that they provide a way to make those secrets and API keys deterministically inaccessible to the agents - even agents that's have a shell execution environment.
That's the opposite of a false sense of security.
just use an api gateway (ie., a reverse proxy for apis), eg., envoy. This should also be connected to observability and finops style management anyway rather than leaving it to model providers.
I noticed the security aspect to be one of the main selling points in corporations for going MCP (and one aspect that is underrepresented here).
However, maybe I'm missing something but how is defining access rights in an application layer the agent has access to more secure than defining the access rights at the target application itself?
Sure, hiding the filesystem via encapsulation tricks is one way to go. But what is the real-world usage-style of this vs. all MCP usages? I'd wager 1-10% are spending this extra effort, while 90% of users basically run shims so that they can expose APIs to their LLMs, for which they have no/bad access rights management.
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.
jimbokun · · focus · HN ↗
Authentication and access controls must be able to withstand an agent with full shell access. And auditing must be on the server side to provide a full picture of all activity from all clients, whether human or agent.
We must treat agents as clever humans and secure and audit data access accordingly. The era of thinking we can handle agent access to sensitive information differently from human access has passed.
simonw · · focus · HN ↗
That's the opposite of a false sense of security.
mjburgess · · focus · HN ↗
woodpanel · · focus · HN ↗
However, maybe I'm missing something but how is defining access rights in an application layer the agent has access to more secure than defining the access rights at the target application itself?
Sure, hiding the filesystem via encapsulation tricks is one way to go. But what is the real-world usage-style of this vs. all MCP usages? I'd wager 1-10% are spending this extra effort, while 90% of users basically run shims so that they can expose APIs to their LLMs, for which they have no/bad access rights management.