4 ms·

MCP is just a transport + wire format with request/response lifecycle and most importantly: tool-level authorization. The essay misses the biggest problem with

by pgt 1y ago

MCP is just a transport + wire format with request/response lifecycle and most importantly: tool-level authorization. The essay misses the biggest problem with MCP: 1. it does not enable AI agents to functionally compose tools. 2. MCP should not exist in the first place. LLMs already know how to talk to every API that documents itself with OpenAPI specs, but the missing piece is authorization. Why not just let the AI make HTTP requests but apply authorization to endpoints? And indeed, people are wrapping existing APIs with thin MCP tools. Personally, the most annoying part of MCP is the lack of support for streaming tool call results. Tool calls have a single request/response pair, which means long-running tool calls can't emit data as it becomes available – the client has to repeat a tool call multiple times to paginate. IMO, MCP could have used gRPC which is designed for streaming. Need an onComplete trigger. I'm the author of Modex[^1], a Clojure MCP library, which is used by Datomic MCP[^2]. [^1]: Modex: Clojure MCP Library – https://github.com/theronic/modex https://github.com/theronic/modex [^2]: Datomic MCP: Datomic MCP Server – https://github.com/theronic/datomic-mcp/ https://github.com/theronic/datomic-mcp/

keithwhor 1y ago
I mean you don’t need gRPC. You can just treat all tool calls as SSEs themselves and you have streaming. HTTP is pretty robust.
- pgt 1y ago
  HTTP Server-Sent Events (SSE) does not natively support batched streaming with explicit completion notifications in its core specification.
cruffle_duffle 1y ago
There are plenty of things out there that don’t use OpenAPI. In fact most things aren’t. Even if the universe was all OpenAPI, you’d still need a lower level protocol to define exactly how the LLM reaches out of the box and makes the OpenAPI call in the first place. That is what MCP does. It’s the protocol for calling tools. It’s not perfect but it’s a start.
- taeric 1y ago
  I mean... you aren't wrong that OpenAPI doesn't have universal coverage. This is true. Neither did WSDL and similar things before it. I'm not entirely clear on why it make sense to jump in with a brand new thing, though? Why not start with OpenAPI?
  - cruffle_duffle 1y ago
    Because OpenAPI doesn’t solve the problem that MCP does. How does the LLM and its host make tool calls? OpenAPI doesn’t solve that at all.
    - taeric 1y ago
      Most of the bookkeeping in how to make calls should be covered in the same details for how anything else makes a call? I'm not clear what makes this different? If necessary, you could add specific data types for this, but the general ideas are almost certainly close enough to there that a whole new thing doesn't bring in too much?
      - anon7000 1y ago
        Are you going to have an OpenAPI client for your local git CLI? Now every tool you might use needs an OpenAPI compliant HTTP server? Sure, if the problem is “how to get AI to talk to web servers,” I could understand this angle. But the problem space is bigger than that, and the goals are different. So having a more effective “protocol” makes sense
        taeric 1y ago
        Honestly, I could see a pretty easy use case for some OpenAPI endpoint definitions to be pass through to a local tool. As such, adding the ability to translate a URL to a CMD could be useful. Outside of that, most of the effort has a very 1:1 use. Response code would be exit code, of course. But describing the output would then be the same. The vast majority of an OpenAPI doc is for documentation purposes. And, I should add, I'm honestly not a huge fan of OpenAPI. I'm just guessing I will also not be a fan of MCP.
resters 1y ago
> 1. it does not enable AI agents to functionally compose tools. Is there something about the OpenAI tool calling spec that prevents this?
- pgt 1y ago
  I haven't looked at the OpenAI tool calling spec, but the lack of return types in MCP, as reported by Erik Meijers, makes composition hard. Additionally, the lack of typed encodings makes I/O unavoidable because the model has to interpret the schema of returned text values first to make sense of it before passing it as input to other tools. Makes it impossible to pre-compile transformations while you wait on tool results. IMO endgame for MCP is to delete MCP and give AI access to a REPL with eval authorized at function-level. This is why, in the age of AI, I am long dynamic languages like Clojure.
pgt 1y ago
Previous thoughts on MCP, which I won't rehash here: - "MCP is a schema, not a protocol" – https://x.com/PetrusTheron/status/1897908595720688111 https://x.com/PetrusTheron/status/1897908595720688111 - "PDDL is way more interesting than MCP" – https://x.com/PetrusTheron/status/1897911660448252049 https://x.com/PetrusTheron/status/1897911660448252049 - "The more I learn about MCP, the less I like it" https://x.com/PetrusTheron/status/1900795806678233141 https://x.com/PetrusTheron/status/1900795806678233141 - "Upon further reflection, MCP should not exist" https://x.com/PetrusTheron/status/1897760788116652065 https://x.com/PetrusTheron/status/1897760788116652065 - "in every new language, framework or paradigm, there is a guaranteed way to become famous in that community" – https://x.com/PetrusTheron/status/1897147862716457175 https://x.com/PetrusTheron/status/1897147862716457175 I don't know if it's taboo to link to twitter, but I ain't gonna copypasta all that.
- kiitos 1y ago
  MCP is literally defined as a protocol. It doesn't have anything to say about the transport layer, and certainly doesn't mandate stdio as a transport. > The main feature of MCP is auth MCP has no auth features/capabilities. I think you're tilting at windmills here.
  - pgt 1y ago
    I regret to inform you that you are the victim of quality control, Sir @kiitos: 1. MCP specifies two transport layers: stdio/stdout + HTTP w/SSE [^1] 2. MCP specifies JSON-RPC as the wire format [^2]. In my opinion, this is a schema on top of a pre-existing RPC protocol, not a new protocol. I implemented the stdio transport, the JSON-RPC wire format & Tools support of the spec in Modex[^3]. - [^1]: https://modelcontextprotocol.io/docs/concepts/transports https://modelcontextprotocol.io/docs/concepts/transports - [^2]: https://modelcontextprotocol.io/specification/2025-03-26 https://modelcontextprotocol.io/specification/2025-03-26 - [^3]: https://github.com/theronic/modex https://github.com/theronic/modex
  - pgt 1y ago
    Re: Auth, you are correct that MCP does not specify auth (aside from env vars for e.g. API keys which is host-specific – another gripe of mine). However, practically the host (e.g. Claude Desktop by Anthropic) asks for permission before calling specific MCP tools. It is not part of the MCP spec, but it's part of most host implementations of MCP and one of the big practical reasons for MCP's existence is to avoid giving models carte blanche HTTP access. IMO this should be part of the MCP spec, e.g. "you can call this GET /weather endpoint any time, but to make payments via this POST /transactions request, ask for permission once or always." Aside: just because someone "defines <X> as something" does not make it true.

by pgt 1y ago

keithwhor 1y ago

I mean you don’t need gRPC. You can just treat all tool calls as SSEs themselves and you have streaming. HTTP is pretty robust.

pgt 1y ago
HTTP Server-Sent Events (SSE) does not natively support batched streaming with explicit completion notifications in its core specification.

cruffle_duffle 1y ago

There are plenty of things out there that don’t use OpenAPI. In fact most things aren’t. Even if the universe was all OpenAPI, you’d still need a lower level protocol to define exactly how the LLM reaches out of the box and makes the OpenAPI call in the first place. That is what MCP does. It’s the protocol for calling tools. It’s not perfect but it’s a start.

taeric 1y ago
I mean... you aren't wrong that OpenAPI doesn't have universal coverage. This is true. Neither did WSDL and similar things before it. I'm not entirely clear on why it make sense to jump in with a brand new thing, though? Why not start with OpenAPI?
- cruffle_duffle 1y ago
  Because OpenAPI doesn’t solve the problem that MCP does. How does the LLM and its host make tool calls? OpenAPI doesn’t solve that at all.
  - taeric 1y ago
    Most of the bookkeeping in how to make calls should be covered in the same details for how anything else makes a call? I'm not clear what makes this different? If necessary, you could add specific data types for this, but the general ideas are almost certainly close enough to there that a whole new thing doesn't bring in too much?
    - anon7000 1y ago
      Are you going to have an OpenAPI client for your local git CLI? Now every tool you might use needs an OpenAPI compliant HTTP server? Sure, if the problem is “how to get AI to talk to web servers,” I could understand this angle. But the problem space is bigger than that, and the goals are different. So having a more effective “protocol” makes sense
      - taeric 1y ago
        Honestly, I could see a pretty easy use case for some OpenAPI endpoint definitions to be pass through to a local tool. As such, adding the ability to translate a URL to a CMD could be useful. Outside of that, most of the effort has a very 1:1 use. Response code would be exit code, of course. But describing the output would then be the same. The vast majority of an OpenAPI doc is for documentation purposes. And, I should add, I'm honestly not a huge fan of OpenAPI. I'm just guessing I will also not be a fan of MCP.

resters 1y ago

> 1. it does not enable AI agents to functionally compose tools. Is there something about the OpenAI tool calling spec that prevents this?

pgt 1y ago
I haven't looked at the OpenAI tool calling spec, but the lack of return types in MCP, as reported by Erik Meijers, makes composition hard. Additionally, the lack of typed encodings makes I/O unavoidable because the model has to interpret the schema of returned text values first to make sense of it before passing it as input to other tools. Makes it impossible to pre-compile transformations while you wait on tool results. IMO endgame for MCP is to delete MCP and give AI access to a REPL with eval authorized at function-level. This is why, in the age of AI, I am long dynamic languages like Clojure.

pgt 1y ago

Previous thoughts on MCP, which I won't rehash here: - "MCP is a schema, not a protocol" – https://x.com/PetrusTheron/status/1897908595720688111 https://x.com/PetrusTheron/status/1897908595720688111 - "PDDL is way more interesting than MCP" – https://x.com/PetrusTheron/status/1897911660448252049 https://x.com/PetrusTheron/status/1897911660448252049 - "The more I learn about MCP, the less I like it" https://x.com/PetrusTheron/status/1900795806678233141 https://x.com/PetrusTheron/status/1900795806678233141 - "Upon further reflection, MCP should not exist" https://x.com/PetrusTheron/status/1897760788116652065 https://x.com/PetrusTheron/status/1897760788116652065 - "in every new language, framework or paradigm, there is a guaranteed way to become famous in that community" – https://x.com/PetrusTheron/status/1897147862716457175 https://x.com/PetrusTheron/status/1897147862716457175 I don't know if it's taboo to link to twitter, but I ain't gonna copypasta all that.

kiitos 1y ago
MCP is literally defined as a protocol. It doesn't have anything to say about the transport layer, and certainly doesn't mandate stdio as a transport. > The main feature of MCP is auth MCP has no auth features/capabilities. I think you're tilting at windmills here.
- pgt 1y ago
  I regret to inform you that you are the victim of quality control, Sir @kiitos: 1. MCP specifies two transport layers: stdio/stdout + HTTP w/SSE [^1] 2. MCP specifies JSON-RPC as the wire format [^2]. In my opinion, this is a schema on top of a pre-existing RPC protocol, not a new protocol. I implemented the stdio transport, the JSON-RPC wire format & Tools support of the spec in Modex[^3]. - [^1]: https://modelcontextprotocol.io/docs/concepts/transports https://modelcontextprotocol.io/docs/concepts/transports - [^2]: https://modelcontextprotocol.io/specification/2025-03-26 https://modelcontextprotocol.io/specification/2025-03-26 - [^3]: https://github.com/theronic/modex https://github.com/theronic/modex
- pgt 1y ago
  Re: Auth, you are correct that MCP does not specify auth (aside from env vars for e.g. API keys which is host-specific – another gripe of mine). However, practically the host (e.g. Claude Desktop by Anthropic) asks for permission before calling specific MCP tools. It is not part of the MCP spec, but it's part of most host implementations of MCP and one of the big practical reasons for MCP's existence is to avoid giving models carte blanche HTTP access. IMO this should be part of the MCP spec, e.g. "you can call this GET /weather endpoint any time, but to make payments via this POST /transactions request, ask for permission once or always." Aside: just because someone "defines <X> as something" does not make it true.