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?
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.
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?
_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.