Live data from Hacker News

MCP: An (Accidentally) Universal Plugin System

worksonmymachine.substack.com

181–190 of 366 posts

Re: MCP: An (Accidentally) Universal Plugin System

#181
post #10

I don't want to sound like a skeptic, but I see way more people talking about how awesome MCP is rather than people building cool things with it. Reminds me of blockchain hype. MCP seems like a more "in-between" step until the AI models get better. I imagine in 2 years, instead of using an MCP, we will point to the tool's documentation or OpenAPI, and the AI can ingest the whole context without the middle layer.

Me and my colleagues are building cools stuff with it. I see many examples of truly useful things being build today.

Re: MCP: An (Accidentally) Universal Plugin System

#182
post #135
post #101

Earlier quoted context omitted.

That's likely because OG devs have been seeing the hallucination stuff, unpredicability etc. and questioning how that fits with their carefully curated perfect system What blocked me initially was watching NDA'd demos a year or two back from a couple of big software vendors on how Agents were going to transform enterprise ... what they were showing was a complete non-starter to anyone who had worked in a corporate be…

How does MCP solve any of the problems you mentioned? The LLM still has to access your data, still doesn't know the difference between instructions and data, and still gives you hallucinated nonsense back – unless there's some truly magical component to this protocol that I'm missing.

The information returned by the MCP server is what makes it not hallucinate. That's one of the primary use cases.

Re: MCP: An (Accidentally) Universal Plugin System

#183
post #10

I don't want to sound like a skeptic, but I see way more people talking about how awesome MCP is rather than people building cool things with it. Reminds me of blockchain hype. MCP seems like a more "in-between" step until the AI models get better. I imagine in 2 years, instead of using an MCP, we will point to the tool's documentation or OpenAPI, and the AI can ingest the whole context without the middle layer.

> MCP seems like a more "in-between" step until the AI models get better. I imagine in 2 years, instead of using an MCP, we will point to the tool's documentation or OpenAPI, and the AI can ingest the whole context without the middle layer.

I doubt the middleware will disappear, it's needed to accomdate the evolving architecture of LLMs.

Re: MCP: An (Accidentally) Universal Plugin System

#184
post #130
post #73

Earlier quoted context omitted.

For each tool you get the human description as well as a JSON schema for the parameters needed to call the function.

You're getting an arbirary string back though...

how else would you describe an arbitrary tool?

Re: MCP: An (Accidentally) Universal Plugin System

#185
post #10

I don't want to sound like a skeptic, but I see way more people talking about how awesome MCP is rather than people building cool things with it. Reminds me of blockchain hype. MCP seems like a more "in-between" step until the AI models get better. I imagine in 2 years, instead of using an MCP, we will point to the tool's documentation or OpenAPI, and the AI can ingest the whole context without the middle layer.

I can't believe there isn't a universal "api/firewall" by now. You know like a middle program that can convert any input api to any output api. With middleware features like logging/firewall/stateful denial and control.

Once cryptocurrency was a thing this absolutely needed to exist to protect your accounts from being depleted by a hack. (like via monthly limits firewall)

Now we need universal MCP API to allow both programmatic and LLM to the same thing. (because apparently these AGI precursors arent smart enough to be trained on generic API calling and need yet another standard: MCP?)

Re: MCP: An (Accidentally) Universal Plugin System

#186
post #89
post #22

I agree with the article, and I love how the author is (mis-)using MCP. I just want to rephrase what the accident actually is. The accident isn't that somehow we got a protocol to do things we couldn't do before. As other comments point out MCP (the specificaiton), isn't anything new or interesting. No, the accident is that the AI Agent wave made interoperability hype, and vendor lock-in old-fashioned. I don't know h…

The main benefit is not that it made interoperability fashionable, or that it make things easy to interconnect. It is the LLM itself, if it knows how to wield tools. It's like you build a backend and the front-end is not your job anymore, AI does it. In my experience Claude and Gemini can take over tool use and all we need to do is tell them the goal. This is huge, we always had to specify the steps to achieve anythi…

I don't understand what you mean.

> It (the main benefit?) is the LLM itself, if it knows how to wield tools.

LLMs and their ability to use tools are not a benefit or feature that arose from MCP. There has been tool usage/support with various protocols and conventions way before MCP.

MCP doesn't have any novel aspects that are making it successful. It's relatively simple and easy to understand (for humans), and luck was on Anthropic's side. So people were able to quickly write many kinds of MCP servers and it exploded in popularity.

Interoperability and interconnecting tools, APIs, and models across providers are the main benefits of MCP, driven by its wide-scale adoption.

Re: MCP: An (Accidentally) Universal Plugin System

#187

Earlier quoted context omitted.

My understanding was that the discoverable part of HATEAOS was meant for machine to machine. Actually all of REST is machine to machine except in very trivial situations. Not sure I'm understanding your point in hypermedia means there is human in the loop. Can you expand?

H in HATEOAS stands for "hypermedia". Hypermedia is a type of document that includes hypermedia controls, which are presented by the hypermedia client to a user for interaction. It's the user who makes decision what controls to interact with. For example, when I'm writing this comment, HN server gave a hypermedia document, which contains your comment, a textarea input and a button to submit my reply, and me, the huma…

So that's not my understanding. Hypermedia, as I understand it, are embedded links in responses that present possible forward actions.

They are structured in a way that machine program could parse and use.

I don't believe it requires human-in-the-loop, although that is of course possible.

Re: MCP: An (Accidentally) Universal Plugin System

#188
post #44
post #22

I agree with the article, and I love how the author is (mis-)using MCP. I just want to rephrase what the accident actually is. The accident isn't that somehow we got a protocol to do things we couldn't do before. As other comments point out MCP (the specificaiton), isn't anything new or interesting. No, the accident is that the AI Agent wave made interoperability hype, and vendor lock-in old-fashioned. I don't know h…

Remember Web 2.0? Remember the semantic web? Remember folksonomies? Mash-ups? The end of information silos? The democratizing power of HTTP APIs?Anyone? Anyone?

Yahoo Pipes, XMPP, self-hosted blogs, RSS-based social networks, pingbacks; the democratized p2p web that briefly was. I bet capitalism will go 2 for 2 against the naive idealism that gatekeepers will stop gatekeeping.

Re: MCP: An (Accidentally) Universal Plugin System

#189
post #44

Earlier quoted context omitted.

Remember Web 2.0? Remember the semantic web? Remember folksonomies? Mash-ups? The end of information silos? The democratizing power of HTTP APIs?Anyone? Anyone?

Yes. Pieces of all of those things surround us now. And where we are wrt locking and interop is far beyond where we were when each of those fads happened. Mcp is a fad, it’s not long term tech. But I’m betting shoveling data at llm agents isn’t. The benefits are too high for companies to allow vendors to lock the data away from them.

> Mcp is a fad, it’s not long term tech

One that won't be supported by any of the big names except to suck data into their walled gardens and lock it up. We all know the playbook.

Re: MCP: An (Accidentally) Universal Plugin System

#190

I've thought of this as well but in reality, aren't MCP servers mostly just clients for pre existing APIs? For example, the Kagi MCP server interacts with the Kagi API. Wouldn't you have a better experience just using that API directly then? On another note, as the number of python interpreters running on your system increases with the number of MCP servers, does anyone think there will be "hosted" offerings that jus…

My understanding is MCP = original APIs + 1 more API The additional API is /list-tools And all the clients consume the /list-tools first and then rest of the APIs depending on which tool they want to call.

Yes. But in order to do that you run the MCP server for that API locally. Is it really worth doing that just to have the additional /list-tools, when it is otherwise basically just a bridge/proxy?
Post reply on HN