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.
You hobble the expressiveness of the LLM and reduce its capability.
Think of an agentic harness as like a kind of body for the LLM. It gives it primitive inputs (read_file, web_search or whatever) and primitive outputs (edit file, respond to user, etc). Give it a command line environment (in a locked down sandbox, with as few or as many tools as you prefer), and you've given it a toolbox. It can do a whole lot more, faster and more efficiently. It can compose tools together. It makes fewer transcription errors manually shifting data around. It can tame verbosity with good protections in the harness and access to grep, sed and awk.
It's really up to you how useful you want your agent to be.
Someone can be OpenAI/Anthropic/whomever.
If you don't have something running somewhere, you don't have an agent, you don't have a harness. You've got a token generator, an LLM from the 2024 era.
That's where you are completely wrong. The point of MCP is that you can have an agent and a harness without running raw CLI or Python commands. Very common for relatively lightweight loads that involve shuffling data around between APIs, often run in a tiny serverless task.
Sure, you have an LLM which can invoke functions. I will say that without storage and composition, you're asking for hallucination. LLMs are not deterministic and while they're good at regurgitating text - you can see how replies in an instruct model are structurally keyed off the question - they will rephrase, adjust, "correct" data they're schlepping from one call result to another call input. And one noisy MCP call and there goes your context.
You could build something with storage and composition out of MCP functions, but come on, have you seen how LLMs - particularly budget LLMs - try and invoke functions reliably? The amount of retries you have to hide, feedback you need to send back to the LLM about what it did wrong. Parameters get replaced with synonyms, arrays are passed for singular arguments and vice versa, structured inputs are flattened, etc.
So maybe you fine tune on interactions with your subset of MCPs, to improve reliability. But all you end up doing is reinventing a Unix-like command line, poorly.
Firecracker micro-VMs, gVisor, wasm sandboxes. There are ways to make this work that aren't heavyweight. Giving LLMs tools that they've seen how to use millions of times in training corpora just works better.
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.
barrkel · · focus · HN ↗
viccis · · focus · HN ↗
barrkel · · focus · HN ↗
Think of an agentic harness as like a kind of body for the LLM. It gives it primitive inputs (read_file, web_search or whatever) and primitive outputs (edit file, respond to user, etc). Give it a command line environment (in a locked down sandbox, with as few or as many tools as you prefer), and you've given it a toolbox. It can do a whole lot more, faster and more efficiently. It can compose tools together. It makes fewer transcription errors manually shifting data around. It can tame verbosity with good protections in the harness and access to grep, sed and awk.
It's really up to you how useful you want your agent to be.
viccis · · focus · HN ↗
barrkel · · focus · HN ↗
If you don't have something running somewhere, you don't have an agent, you don't have a harness. You've got a token generator, an LLM from the 2024 era.
viccis · · focus · HN ↗
barrkel · · focus · HN ↗
You could build something with storage and composition out of MCP functions, but come on, have you seen how LLMs - particularly budget LLMs - try and invoke functions reliably? The amount of retries you have to hide, feedback you need to send back to the LLM about what it did wrong. Parameters get replaced with synonyms, arrays are passed for singular arguments and vice versa, structured inputs are flattened, etc.
So maybe you fine tune on interactions with your subset of MCPs, to improve reliability. But all you end up doing is reinventing a Unix-like command line, poorly.
Firecracker micro-VMs, gVisor, wasm sandboxes. There are ways to make this work that aren't heavyweight. Giving LLMs tools that they've seen how to use millions of times in training corpora just works better.