The premise of the article is that the Model Context Protocol (spelling it out to emphasize the core purpose) is inefficient in its current form. We can agree to that.
Now, does it mean agents don't need a protocol to connect to a server and discover its capabilities, tools, and distributed skills? I disagree.
> Agents with terminal access can replace most MCP servers
What should all other agents that don't have terminal access do?
Aside from the actual protocol, it makes a lot of sense to have a standardized, discoverable protocol.
Because the alternative, as proposed in the article, is that an agent researches an API/CLI/UI, builds software to interact with it, and then runs that. Every time again.
Not only very inefficient, it's unpredictable, and often slow.
Just last week I had an MCP that was down (my mistake) and the agent "decided" that in order to finish my request, it needed to create a python script, refactor that, debug that, and then use that, so it could access my notes (Joplin) over the API and write it's weekly update markdown there. Somehow the thread produced a python tool with over 400 lines of code, five files. It, at some point, even considered putting all that in a git repo. And went on a side-quest to run docker containers.
With the MCP, this job typically takes between $0.05 (Mistral) or $0.90 (Claude Opus). It now cost me $17.00. It took nearly 30 minutes. To write a note in Joplin!
MCPs, or any de-facto standard/pre-known protocol, makes operating on external tools and resources cheaper, faster and above all more predictable.
The scripts that were generated included code to determine if joplin was running, and to launch it if not. It included a proxy server, that would listen on a localhost:xxxx and if a HTTP request came in, this proxy would auto-launch joplin and then forward the request/response. It then included quite some code to de/serialize json to/from datatypes.
Part of this "overengineering" came from a "skill" that claude found globally which I wrote for myself when working on a few python tools. The skill required strict typing, demanded refactoring, insisted on doing everything over http (and not local commands).
Basically, the agent could not perform its task over an MCP and should've stopped. But I suspect either tuning or some system-prompt made claude go on instead. It decided to use python, and then found my "requirements for when writing python", followed that, and burned a lot of tokens to make one or two HTTP requests.
docheinestages · · focus · HN ↗
Now, does it mean agents don't need a protocol to connect to a server and discover its capabilities, tools, and distributed skills? I disagree.
> Agents with terminal access can replace most MCP servers
What should all other agents that don't have terminal access do?
berkes · · focus · HN ↗
Because the alternative, as proposed in the article, is that an agent researches an API/CLI/UI, builds software to interact with it, and then runs that. Every time again. Not only very inefficient, it's unpredictable, and often slow.
Just last week I had an MCP that was down (my mistake) and the agent "decided" that in order to finish my request, it needed to create a python script, refactor that, debug that, and then use that, so it could access my notes (Joplin) over the API and write it's weekly update markdown there. Somehow the thread produced a python tool with over 400 lines of code, five files. It, at some point, even considered putting all that in a git repo. And went on a side-quest to run docker containers.
With the MCP, this job typically takes between $0.05 (Mistral) or $0.90 (Claude Opus). It now cost me $17.00. It took nearly 30 minutes. To write a note in Joplin!
MCPs, or any de-facto standard/pre-known protocol, makes operating on external tools and resources cheaper, faster and above all more predictable.
berkes · · focus · HN ↗
The scripts that were generated included code to determine if joplin was running, and to launch it if not. It included a proxy server, that would listen on a localhost:xxxx and if a HTTP request came in, this proxy would auto-launch joplin and then forward the request/response. It then included quite some code to de/serialize json to/from datatypes.
Part of this "overengineering" came from a "skill" that claude found globally which I wrote for myself when working on a few python tools. The skill required strict typing, demanded refactoring, insisted on doing everything over http (and not local commands).
Basically, the agent could not perform its task over an MCP and should've stopped. But I suspect either tuning or some system-prompt made claude go on instead. It decided to use python, and then found my "requirements for when writing python", followed that, and burned a lot of tokens to make one or two HTTP requests.