Live data from Hacker News

MCP: An (Accidentally) Universal Plugin System

worksonmymachine.substack.com

201–210 of 366 posts

Re: MCP: An (Accidentally) Universal Plugin System

#201

I know this is nit-picky and not really relevant to the actual meat of the story, but a toaster (outside of a gag gift or gimmick) cannot run on USB-C since your typical toaster draws ~1kW and USB-C power spec tops out at 240W.

I assumed they were controlling the toaster over usb c or getting some data from it, interfacing with it, rather than actually powering it!

> But it worked, and now Rex's toast has HDMI output.

> Toaster control protocols? Rex says absolutely.

Re: MCP: An (Accidentally) Universal Plugin System

#202
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…

Reminds me of the days of Winsock.

For those that don't remember/don't know, everything network related in Windows used to use their own, proprietary setup.

Then one day, a bunch of vendors got together and decided to have a shared standard to the benefit of basically everyone.

https://en.wikipedia.org/wiki/Winsock

Re: MCP: An (Accidentally) Universal Plugin System

#203
post #156

Earlier quoted context omitted.

> The main difference between MCP and REST is `list-tools`. > REST APIs have 5 or 6 ways of doing that You think nobody's ever going to publish a slight different standard to Anthropic's MCP that is also primarily intended for LLMs?

Why would they? I'm sure the "Enterprise" folks are putting together some working group to develop ANSI-xyzzy standard for Enterprise operability which will never see the light of day.

Because they genuinely think it'll work better, because they think it will build brand awareness/moat, because they're upset MCP comes from a competitor

Re: MCP: An (Accidentally) Universal Plugin System

#204
I believe Microsoft's usual "Embrace, Expand, Extinguish" strategy is at work here. For system stability and security reasons, you wouldn't actually want agents to dynamically discover tools without proper governance. Alternatives like PydanitcAI are lost in this steady MCP noise maintained by Microsoft - their "Embrace" phase for MCP, declared during Build 2025 event. Anthropic released this open standard with weak tooling and no governance for the specs, making it easy for Microsoft to dominate.

The next step would be Microsoft attempting to make their registry the de facto choice for developers and extending with Windows-specific verbs.

Then, by controlling what's considered "secure", they can marginalize competitors.

Re: MCP: An (Accidentally) Universal Plugin System

#205
post #69
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?

Nobody remembers the semantic web anymore

It was supposed to be Web 3.0, but then Web3 happened.

In all seriousness though, I think HN has a larger-than-average amount of readers who've worked or studied around semantic web stuff.

Re: MCP: An (Accidentally) Universal Plugin System

#206

Earlier quoted context omitted.

so... is this OpenAPI then?

OpenAPI doesn't have a baked in discoverability mechanism. It isn't compatible with LLMs out of the box. It is a lower level abstraction. I don't want to write a blob of code that talks to an Open API service every time I want to do something with an LLM.

>OpenAPI doesn't have a baked in discoverability mechanism.

Well, Swagger was there from the start, and there's nothing stopping an LLM from connecting to an openapi.json/swagger.yaml endpoint, perhaps meditated by a small xslt-like filter that would make it more concise.

Re: MCP: An (Accidentally) Universal Plugin System

#207

Earlier quoted context omitted.

But you're describing it in a way that is useless to anything but an LLM. It would have been much better if the description language had been more formalized.

The description includes an input and output json schema.

Only input, not output.

https://modelcontextprotocol.io/specification/2025-03-26/ser...

Re: MCP: An (Accidentally) Universal Plugin System

#208
post #196

Earlier quoted context omitted.

If this then that - a zapier type glue provider.

Minor chronological point but Zapier is an IFTTT-type glue provider. IFTTT was announced Dec. 14, 2010 and launched on Sept. 7. 2011. Zapier was first pitched Sept. 30, 2011 and their public beta launched May 2012.

And to answer the obvious next question: yes, there is an MCP for IFTTT https://mcp.pipedream.com/app/ifttt

Re: MCP: An (Accidentally) Universal Plugin System

#209

Earlier quoted context omitted.

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?

From my perspective, remote MCP servers are gradually becoming the norm for external services.

Re: MCP: An (Accidentally) Universal Plugin System

#210
post #176

Earlier quoted context omitted.

So the whole point of the article is that an API is an API and anything can call an API?

There is a long tail of applications that are not currently scriptable or have a public API. The kind that every so often make you think "if only I could automate this instead of clicking through this exact same dialog 25 times" Before, "add a public API to this comic reader/music player/home accounting software/CD archive manager/etc." would be a niche feature to benefit 1% of users. Now more people will expect to h…

That's not where the money is. It's in adding a toll charge for tokens to talk to widely used APIs.
Post reply on HN