3 ms·

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 t

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?

gmueckl 5d ago
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.
- lelanthran 5d ago
  > 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.
- datsci_est_2015 5d ago
  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.
  - gmueckl 5d ago
    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.
    - datsci_est_2015 5d ago
      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.
_heimdall 5d ago
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.
- bastawhiz 5d ago
  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.
  - _heimdall 5d ago
    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.
    - bastawhiz 5d ago
      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.
deleted 5d ago
[deleted]
berkes 5d ago
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.

gmueckl 5d ago

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.

lelanthran 5d ago
> 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.
datsci_est_2015 5d ago
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.
- gmueckl 5d ago
  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.
  - datsci_est_2015 5d ago
    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.

_heimdall 5d ago

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.

bastawhiz 5d ago
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.
- _heimdall 5d ago
  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.
  - bastawhiz 5d ago
    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.

deleted 5d ago

[deleted]

berkes 5d ago

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.