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?
Also, terminal access is extremely powerful on its own. Why should an agent even get access to that? I see it as a potential violation of least privileges.
> Also, terminal access is extremely powerful on its own. Why should an agent even get access to that? I see it as a potential violation of least privileges.
When even the official software from the token providers have never had human eyes on 800kSLoC, I'm afraid that ship has sailed: the principle of least privileges has already been ravaged to hell and back.
Sealing a pin-prick hole in a dam wall is pointless if half the dam has already been washed away.
Why trust any user with access to any terminal? UNIX solved this decades ago. It’s just we’re all learning to be sysadmins for the most creatively destructive and persistent set of users of all time.
UNIX didn't really solve this scenario. Yes, you can limit what local files a user has access to. But with web applications and cloud services being so ubiquitous, the local boundaries are pretty much meaningless. Forcing an agent through an MCP is a way to grant access to remote services while still restricting how the network access can be used.
Network administrators also solved these things, e.g. you can limit what websites a virtual machine is allowed to access.
Now, if you’re letting your agents abuse network traffic there becomes a point where you’re criminally liable. Unfortunately the current US government has no interest in prosecuting such abuse.
Maybe I overestimate the ability for corporate network administrators to block and detect access to certain websites from within their networks, like adult websites. My understanding was that there’s no way to circumvent those network controls.
What you're describing, though, is that agents need a REST API. And I meant true REST rather than the JSON RPC APIs we've been building for 20+ years now.
Had we not abandoned REST we'd still have APIs that are self documenting and typed/schemaed. Bonus if browsers still supported XSLT, that same API could have been written in XML and only browsers wanting a visual representation would load HTML templates while agents could stick with the raw XML.
Sure, it needs a REST API. And you need docs for the API. Not just per endpoint but how to accomplish tasks with the API in the context of the application it supports.
But you don't want to just give any old agent raw curl access, so now you've got to provide a special client that can call just the APIs /endpoints that they're supposed to be able to. And it needs to know what the agent shouldn't be able to do as well. And it also needs to be able to handle things like auth, because you don't want the average person (or the agent!) handling bearer tokens. And you probably want a layer in between that validates everything against an OAS so the agent can't make invalid requests.
And now you've effectively just reinvented the good parts of MCP with extra tokens.
You're starting too recent though. MCP is attempting to recreate the good parts of REST APIs circa 25 years ago.
Soap was a pain and a lot of people didn't like XML, but they solved exactly these problems.
With MCP we're effectively trying to bolt those features onto a platform that fundamentally doesn't support it. Where as with XML/XSLT we could have a single XML endpoint + XSLT templates for converting that into HTML for browsers. Instead we now have modern web frameworks building RPC calls right into the bundle/build step, splitting state and rendering across both client and server, and have to stand up a new API context for agents that needs documentation and maintenance to keep parity with new features.
This isn't a problem that existed 25 years ago. You could expose SOAP and give an agent WSDL. You could give it OpenAPI and JSON. That's just not the problem.
Agents emit tool calls as JSON. Calling a REST API means emitting a JSON tool call that invokes a HTTP client with all the desirable properties (schema checking, safe auth) and none of the undesirable ones (raw key handling, arbitrary endpoint access). Then the response gets wrapped in JSON and returned to the LLM. That's not an MCP thing, that's a model thing.
MCP says "instead of http_post with a bunch of arguments that need to be correct, call get_weather with a zip code". And then it makes principled choices for how get_weather and its schema is defined. That's literally the whole point.
Even if you wanted to use WSDL to accomplish this, you either have to unwind how literally every function calling implementation of every model works today and teach them how to read WSDL and speak XML (and deal with all the other problems, like auth), or you avoid the two layers of indirection and define a system that works with what exists today, and that solution ends up looking very MCP-shaped.
You might say "well you could just have a little script/xslt that does the translation". That's exactly what a local MCP server is.
I'm not aware of anything that makes the models prefer JSON though, that's an implementation decision from whomever implemented the transport mechanism.
LLMs will happily work with XML, including to understand data schemas and discover available actions that can be taken.
No, that's wrong. The models have special syntax for function calls. They're not simply regular responses, they're special message types. You're partially right though: most models don't output or accept JSON, they have their own syntax internally. But that syntax is different for every model, and all the tools that invoke the models have parsers that convert it to the standard JSON+JSONSchema format. That's what vLLM and llama.cpp (or your tool of choice) are doing.
But that's irrelevant, because it's the tool call. The tool call is what invokes the HTTP client, not what's in the request payload. It could be asn.1 or RDF or TOML. JSON just happens to be convenient and universally supported. MCP could easily be implemented on literally anything you throw at it: that's an internal detail to your agent harness. That's not the point.
MCP is the OAS/WSDL/whatever contract described as tool calls instead of as network requests that the agent has to construct from scratch. Its whole purpose is to eliminate the whole layer of indirection.
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?
gmueckl · · focus · HN ↗
lelanthran · · focus · HN ↗
When even the official software from the token providers have never had human eyes on 800kSLoC, I'm afraid that ship has sailed: the principle of least privileges has already been ravaged to hell and back.
Sealing a pin-prick hole in a dam wall is pointless if half the dam has already been washed away.
datsci_est_2015 · · focus · HN ↗
gmueckl · · focus · HN ↗
datsci_est_2015 · · focus · HN ↗
Now, if you’re letting your agents abuse network traffic there becomes a point where you’re criminally liable. Unfortunately the current US government has no interest in prosecuting such abuse.
gmueckl · · focus · HN ↗
datsci_est_2015 · · focus · HN ↗
_heimdall · · focus · HN ↗
Had we not abandoned REST we'd still have APIs that are self documenting and typed/schemaed. Bonus if browsers still supported XSLT, that same API could have been written in XML and only browsers wanting a visual representation would load HTML templates while agents could stick with the raw XML.
bastawhiz · · focus · HN ↗
But you don't want to just give any old agent raw curl access, so now you've got to provide a special client that can call just the APIs /endpoints that they're supposed to be able to. And it needs to know what the agent shouldn't be able to do as well. And it also needs to be able to handle things like auth, because you don't want the average person (or the agent!) handling bearer tokens. And you probably want a layer in between that validates everything against an OAS so the agent can't make invalid requests.
And now you've effectively just reinvented the good parts of MCP with extra tokens.
_heimdall · · focus · HN ↗
Soap was a pain and a lot of people didn't like XML, but they solved exactly these problems.
With MCP we're effectively trying to bolt those features onto a platform that fundamentally doesn't support it. Where as with XML/XSLT we could have a single XML endpoint + XSLT templates for converting that into HTML for browsers. Instead we now have modern web frameworks building RPC calls right into the bundle/build step, splitting state and rendering across both client and server, and have to stand up a new API context for agents that needs documentation and maintenance to keep parity with new features.
bastawhiz · · focus · HN ↗
Agents emit tool calls as JSON. Calling a REST API means emitting a JSON tool call that invokes a HTTP client with all the desirable properties (schema checking, safe auth) and none of the undesirable ones (raw key handling, arbitrary endpoint access). Then the response gets wrapped in JSON and returned to the LLM. That's not an MCP thing, that's a model thing.
MCP says "instead of http_post with a bunch of arguments that need to be correct, call get_weather with a zip code". And then it makes principled choices for how get_weather and its schema is defined. That's literally the whole point.
Even if you wanted to use WSDL to accomplish this, you either have to unwind how literally every function calling implementation of every model works today and teach them how to read WSDL and speak XML (and deal with all the other problems, like auth), or you avoid the two layers of indirection and define a system that works with what exists today, and that solution ends up looking very MCP-shaped.
You might say "well you could just have a little script/xslt that does the translation". That's exactly what a local MCP server is.
_heimdall · · focus · HN ↗
LLMs will happily work with XML, including to understand data schemas and discover available actions that can be taken.
bastawhiz · · focus · HN ↗
But that's irrelevant, because it's the tool call. The tool call is what invokes the HTTP client, not what's in the request payload. It could be asn.1 or RDF or TOML. JSON just happens to be convenient and universally supported. MCP could easily be implemented on literally anything you throw at it: that's an internal detail to your agent harness. That's not the point.
MCP is the OAS/WSDL/whatever contract described as tool calls instead of as network requests that the agent has to construct from scratch. Its whole purpose is to eliminate the whole layer of indirection.
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.
[deleted] · · focus · HN ↗
[deleted]