And with the cynicism out of the way, what an insightful and refreshing article!
I'm considering migrating, but time is limited and I'd love to avoid a dead-end if I can :p
MCP has very little utility outside of LLMs. The article begins by saying "but what if we remove the AI", then goes back on that thesis by saying "but if there was an AI between these things, then it becomes a universal plugin system". Which is true, but its missing the critical bit: The AI itself is the universal plugin system, not MCP. And, beyond that, its not even the AI: Its natural language. Language is the universal plugin system.
Its not unbelievable that there exists an alternate reality where the Anthropic researchers that invented MCP instead simply leveraged a slightly extended form of OpenAPI specs. The only functional difference is that MCP was a stdin/stdout format first, and added HTTPS later, but sister problems in this domain like LSP just skipped stdin/stdout and went straight to locally-hosted HTTPS anyway. What matters isn't MCP, OpenAPI, or anything like that; what matters is the LLM itself, its tool calling capability, and the tool calling harness. The catalogue of available tools can be in any format; and, truly, the LLM does not care what format its in.
1. No one asserted that MCP's key innovation was its format. In fact, what I strongly, almost explicitly implied with my previous comment is that MCP has made no key innovations beyond its marketing system (which does matter and has forced a lot of companies who would never have operated in this space to make an MCP system, and that is good. I like MCP.).
2. MCP is fundamentally bidirectional, not unidirectional. Its a schematized request-response protocol that defines a ton of the same primitives that OpenAPI defines, like available RPC methods, authorization, request parameters, and response schemas [1]. Of course, OpenAPI goes beyond that into HTTP-specific characteristics like status codes, and MCP goes beyond that into LLM-specific characteristics like a prompt catalogue.
3. I'm not aware of any problem domain outside of LLMs that is adopting MCP. In fact, its adoption even within the world of LLMs has been lackluster at best [2].
[1] https://modelcontextprotocol.io/docs/learn/architecture#data...
I've reread the article a couple times and I can't see where it says that you need to use an LLM to make it universal. I'm going to go so far as to say that it doesn't say that.
As developers, we often want everything to be rich, verbose, and customizable — but the reality is that for most users (and now for AIs acting on their behalf), simplicity wins every time. It’s like designing a great UI: the fewer ways you can get lost, the more people (or models) can actually use it productively.
If MCP ends up nudging the ecosystem toward small, well-defined, composable capabilities, that’s a win far beyond just “AI integration.”
Snark aside it's, autonomous agents were one of the more interesting justifications for web APIs back in the day. I don't think people necessarily envisioned LLMs but some sort of agent you could send off to grab data or book flights or whatever. Specs like WSDL do what MCP does today letting the autonomous system figure out how to use a service.
Oh well, schemas and the ability to do browser-native style transforms were lame! Lets transition to YAML so no one can say "no" to Norway.
The other issue is that you cannot think of MCP servers as universal pluggable systems that can fit into every use-case with minimal wrapping. Real world scenarios require pulling a lot of tricks. Caching can be done at higher or lower level depending on the use-case. Communication of different information from the MCP server also is different depending on the use-case (should we replace these long IDs for shorter IDs that are automatically translated to longer ones). Should we automatically tinyurl all the links to reduce hallucination? Which operations can be effectively solved with pure algorithms (compress 2-3 operations into one) because doing this with LLMs is not only error-prone but also not optimal (imagine using LLM to grep for strings in many files one by one using tool calls rather than using grep to search for strings - not the same)
There are so many things to consider. MCP is nice abstraction but it is not a silver bullet.
Speaking from experience with actual customers and real use-case.
Not only that, apparently we finally got Jini and Agent Tcl back!
https://www.usenix.org/conference/fourth-annual-usenix-tcltk...
https://www.eetimes.com/jini-basics-interrelating-with-java/
cranberryturkey•2h ago
I built it and have added several modules, but I'm always looking for people to add more modules. See ./mcp_modules in the root folder.
fxwin•1h ago
Also doesn't really seem to relate to the OP beside the term 'MCP' in the title
cranberryturkey•41m ago