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.
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
[^2]: Datomic MCP: Datomic MCP Server – https://github.com/theronic/datomic-mcp/
Previous thoughts on MCP, which I won't rehash here:
- "MCP is a schema, not a protocol" – https://x.com/PetrusTheron/status/1897908595720688111
- "PDDL is way more interesting than MCP" – https://x.com/PetrusTheron/status/1897911660448252049
- "The more I learn about MCP, the less I like it" https://x.com/PetrusTheron/status/1900795806678233141
- "Upon further reflection, MCP should not exist" 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
I don't know if it's taboo to link to twitter, but I ain't gonna copypasta all that.
I hadn't heard of PDDL before but to save others the click on x.com, this is the Xeet:
> This PDDL planning example is much more interesting than what MCP purports to be: https://en.wikipedia.org/wiki/Planning_Domain_Definition_Lan...
> Imagine a standard planning language for model interconnect that enables collaborative goal pursuit between models.
> Maybe I'll make one.
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.
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
- [^2]: https://modelcontextprotocol.io/specification/2025-03-26
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.
And this why I call it EEE: if Anthropic had simply added HTTP API endpoints with auth, everyone would have copied it, and Anthropic would have no control over the spec, which can keep future contenders out.
The MCP spec is a moat, and we’ve seen this movie before, whether they intended it to be or not. I use it, but I don’t have to like it, i.e. MCP should not exist.
As previously stated [^1], OpenAI can one-up them by simply supporting any API endpoint + auth and it would be way more powerful, no moat to defend against startups. No VC-funded corp can resist a moat.
[^1]: 2025-03-06: https://x.com/petrustheron/status/1897760788116652065?s=46
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.
AI can read docs, Swagger, OpenAI and READMEs, so MCP adds nothing here. All you need is an HTTP client with authorization for endpoints.
E.g. in Datomic MCP[^1], I simply tell the model that the tool calls datomic.api/q, and it writes correct Datomic Datalog queries while encoding arguments as EDN strings without any additional READMEs about how EDN works, because AI knows EDN.
And AI knows HTTP requests, it just needs an HTTP client, i.e. we don't need MCP.
So IMO, MCP is an Embrace, Extend (Extinguish?) strategy by Anthropic. The arguments that "foundational model providers don't want to deal with integration at HTTP-level" are uncompelling to me.
All you need is an HTTP client + SSE support + endpoint authz in the client + reasonable timeouts. The API docs will do the rest.
Raw TCP/UDP sockets more dangerous, but people will expose those over MCP anyway.
[^1]: https://github.com/theronic/datomic-mcp/blob/main/src/modex/...
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?
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.
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?
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
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.
> 1. it does not enable AI agents to functionally compose tools.
Is there something about the OpenAI tool calling spec that prevents this?
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.
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.
HTTP Server-Sent Events (SSE) does not natively support batched streaming with explicit completion notifications in its core specification.