alt Hacker NewsMCP: An (Accidentally) Universal Plugin System
Comments
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.”
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.
Everyone keeps rediscovering OS IPC extensions via RPC.
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/
This is Web 2.0. You're in the process of rediscovering mashups. Before it was SOAP and REST/HTTP and now it's...well, it's still kind of REST/HTTP because MCP is JSON-RPC. There was this brief, beautiful period where every "learn to code" book ended with a couple of chapters of how to make your app do google searches and throw the results into a word graph or something before all the big tech companies locked that sort of access down.
Weirdly, I'm a little optimistic that it might work this time. AI is hot, which means that suddenly we don't care about IP anymore, and if AIs are the ones that are mostly using this protocol, providers will perhaps be in less of a rush to block everybody from doing cool things.
MCP is just JSON rpc with one useful command (list-tools). Turns out that's probably all we ever needed.
The more I look into MCP, the less I understand the hype. It's an OK API that describes how to fetch list of tools and resources and retrieve them, somehow this is supposed to be the standard for AI and environment communication, and...that's it? Am I missing something vital there?
How long before companies start closing this "loophole"?
And with the cynicism out of the way, what an insightful and refreshing article!
This is not a novel take, but what's arguably even more universal is cli access to a service.
I have a lot more luck integrating service specific cli's with Claude than trying to use MCPs. As an additional bonus, AI tools instantly know how to troubleshoot issues with them, filter or transform the output and compose them into bigger workflows with scripting.
I've been doing some really fun things with MCP
First of all I think this kind of localhost/stdio MCP is kind of not 'The Way' besides for playing around. I've been working on SSE/remote/cloud-based MCP
Here's a fun example: https://x.com/firasd/status/1945233853414826060
("my landing page is in a text editor with iframe preview. I ask Claude to edit it—the doc gets transcluded into the AI chat, gets surgically edited. I reload. (All on mobile!)")
I'm working on a starter template like a DevTools MCP that people can deploy on Cloudflare and oAuth with their github account and it provides tools like url_fetch for people to use privately in their AI chats/tools. First I have to figure out the oAuth stuff myself but will make it a public repo after that and post on here
PS. I also think tool use is really underrated and stuff like MCP unlocks a kind of agentic behavior 99% of AI users have never seen.
Previous discussion (43 days ago, 355 comments):
> 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.
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
Made a similar comment [1] a while back. Universal, open APIs might be one of the best things to come out of this AI wave.
how does this hypeblog spam keep getting to the top?
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...
MCP has barely given me satisfactory results. LLMs just keep fighting with it and fill up a lot of their context.
Would be great if we don’t repeat the same mistake over and over again by making security a subsequent feature
I'm a well-designed hole. Put something here.
You asked for it.
MCP "universal plugin system" claims are oversold. It is really just a standardized tool calling for AI agents. If you are not building agents that need to dynamically discover and choose tools, traditional APIs are simpler and better.
The "system integration" benefits only matter when you have an LLM in the loop making decisions about which tools to use.
> "Your car doesn't care if you're charging a phone or running a personal pizza oven. The hole is the same size. The power is there."
This is an inadvertently great and amusing analogy, because it shows how people can assume something about an API's capabilities without actually trying it.
A 12V battery car battery can't power a pizza oven. It can barely boil water in a special rice cooker - very very slowly. And it risks depleting the battery and not being able to start your car.
Like a new API, people get excited about what it can do, but the reality is very different.
I have a portable fan with a power bank that charges over USB with a USB-micro plug. For some reason I can't fathom, it's an absolute power hog. I've killed my van's battery using it for just a few hours. (In theory it should be using at max 2.5W, but that's not the point).
Again, that shows how trying to extend an APIs design can have unexpected side effects which tax the system in ways that are hard to predict.
MCP has a lot of excitement around it now, but it will inevitably reach its limits. The lesson is to test your system under load before assuming anything.
There's nothing about "model" in MCP at all, they're just json rpc ?
Accidentally? Generic interoperability was the whole point of mcp, it was not an accident.
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.
checkout my MCP server platform: https://github.com/profullstack/mcp-server
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.
[dead]
[dead]
I’m just getting into MCP (building my own server and trying some canned ones), and one thing I’ve noticed — some servers seem to devour your context window before you’ve even typed a single token / question.
My favorite example is the public Atlassian one — https://www.atlassian.com/blog/announcements/remote-mcp-serv...
Even with Claude or Gemini CLI (both with generous limits), I run out of context and resources fast.
With local LLMs via LM Studio? Forget it — almost any model will tap out before I can get even a simple question in.