The way the function is described to the LLM matter. Even when the parameters are the same and the effect is the same the title and description can fundamentally influence how the task is performed.
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.
pjmlp · 7m ago
Everyone keeps rediscovering OS IPC extensions via RPC.
Not only that, apparently we finally got Jini and Agent Tcl back!
I think MCP is awesome, mainly because it forces devs to design the simplest possible tools/APIs/functions so even an average-performance LLM can use them correctly to get things done.
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.”
turlockmike · 21m ago
MCP is just JSON rpc with one useful command (list-tools). Turns out that's probably all we ever needed.
> MCP thinks it's for giving context to AI models. But really? It's just a really good protocol for making things talk to other things.
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.
radixdiaboli · 20m ago
> but if there was an AI between these things, then it becomes a universal plugin system
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.
827a · 14m ago
I agree, the article does explicitly say that; the thesis of the article and the information it presents to support that thesis are entirely at odds. That's what I'd argue this is a poor article, just an advertisement for the world's eighty-sixth todo app; yet it keeps getting re-posted here.
ethan_smith · 20m ago
MCP's key innovation isn't the format but its unidirectional, stateless design pattern that makes it fundamentally easier to implement than bidirectional protocols like OpenAPI, which is why it's gaining traction as a universal connector beyond just LLM contexts.
827a · 2m ago
I really don't know where you're coming from with that statement.
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].
I love that MCP servers are rediscovering the old idea of public web APIs mash-ups from the early days of Web 2.0. Of course we don't need any icky XML with its namespace and schemas. Just some vibe-heavy JSON.
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.
shredprez · 1h ago
Has anyone tried Basement's typed xmcp framework [1]? I rolled my own mcp server implementation earlier this summer and it works but it's very basic.
I'm considering migrating, but time is limited and I'd love to avoid a dead-end if I can :p
How long before companies start closing this "loophole"?
And with the cynicism out of the way, what an insightful and refreshing article!
ecocentrik · 49m ago
If MPC develops as an open standard and this "loophole" gains enough popularity, then companies can only really limit access to their services. This seems like a generally good thing that will enhance automation. Does it really matter if the automation comes from agents, hard coded software or a combination of the two?
behnamoh · 1h ago
Is it just me who absolutely hates this much hype around AI while still getting value from AI models? I get it, MCP is useful, but it's neither new nor safe and well thought-out. It feels like everyone now has to write a mandatory MCP article...
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
I'll be honest i read your repository's README.md and still have no idea what this is supposed to be. The tagline sounds like it's for implementing MCP servers, but the endpoints specified further down aren't part of MCP but something more specific (to MCPs serving a language model? Why would we serve them like that?)
Also doesn't really seem to relate to the OP beside the term 'MCP' in the title
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/
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.”
https://news.ycombinator.com/item?id=44404905
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.
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.
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...
[2] https://modelcontextprotocol.io/clients
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.
I'm considering migrating, but time is limited and I'd love to avoid a dead-end if I can :p
[1] https://github.com/basementstudio/xmcp
And with the cynicism out of the way, what an insightful and refreshing article!
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.
Also doesn't really seem to relate to the OP beside the term 'MCP' in the title