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.
Even if your agent has internet access, why waste tokens having it re-discover and re-implement its own API client each time? It doesn't make any sense.
yeah MCP contains a provision for some blocktext for instructions. If your MCP has walls of text in those instructions, it will burn more tokens that a terse MCP.
For me, I have a service that has multiple vectors of what would be called an API - PowerShell Modules, WMI, RESTFUL Web Services, some are available, some can do some things, some are more direct, some are not allowed with enterprise security etc.
Either way, I don't do what you suggest. I have self-learning rules and have the models build a well-rounded API engine once, then re-use it with query scripts through skills. Its portable and flexible in many environments.
Making the model use curl is even stupider. It still needs to do the same amount of work to lookup and understand the API contracts (assuming those are even public). But now it also needs to juggle the auth flows and marshalling at the tool call level.
You said ""re-implements an API client" which means you either don't know what curl is or don't know what an api client is. So I'd chill on calling things "stupider" when you don't have a strong grasp on the words you're using.
What is "implementing".... I'd define it as "figuring out the workflow, and storing it in a way that allows reuse". This could be a program written in assembly, or rust, or even python. Or it could be a shell script that calls curl. Or it could just be a set of tokens in the current session. Outside of the computer it could even be a set of processes people do, or a mechanical device.
If it's just a set of tokens in the current session, well then next session it has to figure out the workflow, and then store it in a way to use in the next session.
Nonsense, curl is a tool for executing a single http request.
Many apis require several requests to get things done. (one to auth, one or more to fecth resource ids, one or more to modify resources, etc).
That would be a series of curl calls with logic applied to the output of each call to curl. An api client just does those things in a single function call. The steps are the same, but in one case the AI has to figure out each curl call and implement the logic, rather than just call the function.
By your logic 'ls' is a file manager, 'grep' is a search engine, and 'echo $X >> /proc/sys/$Y' is a settings manager.
It makes sense though. It's the same logic that allows you to say promting an AI with "do a simple thing for me" makes you a programmer, and prompting an AI with "what is an api" allows makes you knowledgable about computers.
In your mind, is netcat also an API client? When normal people talk about api clients, they're referring to an sdk or a cli which provides a simpler interface for a specific API.
Sure, but if you have a staff of 10000, you're doing this 10000 times. Unless you share that in a common place, and now you're re-inventing the thing we're claiming not to need.
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.
0x696C6961 · · focus · HN ↗
marcelo-earth · · focus · HN ↗
deadbabe · · focus · HN ↗
0x696C6961 · · focus · HN ↗
cowmix · · focus · HN ↗
When I use the Atlassian CLI vs their MCP server, I tend to see something like half the token burn with the CLI with more accurate results.
That could be an Atlassian issue but that's the results I'm seeing.
dnautics · · focus · HN ↗
dnautics · · focus · HN ↗
0x696C6961 · · focus · HN ↗
dnautics · · focus · HN ↗
[deleted] · · focus · HN ↗
[deleted]
0x696C6961 · · focus · HN ↗
dnautics · · focus · HN ↗
athrowaway3z · · focus · HN ↗
Not sure whats the norm nowadays, but it used to be MCP descriptions were loaded in from the start.
In any case, to be cheaper the `cli --help` command needs to more noisy than the json description.
Finally, and the really big one: cli can be composed with `grep`, `jq` , etc.
hypercube33 · · focus · HN ↗
Either way, I don't do what you suggest. I have self-learning rules and have the models build a well-rounded API engine once, then re-use it with query scripts through skills. Its portable and flexible in many environments.
0x696C6961 · · focus · HN ↗
mexicocitinluez · · focus · HN ↗
Is using curl considered re-implementing your own api client each time?
0x696C6961 · · focus · HN ↗
mexicocitinluez · · focus · HN ↗
sophacles · · focus · HN ↗
If it's just a set of tokens in the current session, well then next session it has to figure out the workflow, and then store it in a way to use in the next session.
Seems like maybe you should take your own advice.
mexicocitinluez · · focus · HN ↗
> Seems like maybe you should take your own advice.
Seems like maybe if you have to use your own custom definition of a word in order to support a point you might not have one. lol.
sophacles · · focus · HN ↗
Many apis require several requests to get things done. (one to auth, one or more to fecth resource ids, one or more to modify resources, etc).
That would be a series of curl calls with logic applied to the output of each call to curl. An api client just does those things in a single function call. The steps are the same, but in one case the AI has to figure out each curl call and implement the logic, rather than just call the function.
mexicocitinluez · · focus · HN ↗
Irony died in this comment thread.
sophacles · · focus · HN ↗
It makes sense though. It's the same logic that allows you to say promting an AI with "do a simple thing for me" makes you a programmer, and prompting an AI with "what is an api" allows makes you knowledgable about computers.
0x696C6961 · · focus · HN ↗
mexicocitinluez · · focus · HN ↗
And When "normal" people talk about api clients? lol This site is wild.
0x696C6961 · · focus · HN ↗
jimbokun · · focus · HN ↗
estetlinus · · focus · HN ↗
0x696C6961 · · focus · HN ↗
nitwit005 · · focus · HN ↗