Live data from Hacker News

MCP: An (Accidentally) Universal Plugin System

worksonmymachine.substack.com

21–30 of 366 posts

Re: MCP: An (Accidentally) Universal Plugin System

#21
post #4

I don’t want to undermine the author’s enthusiasm for the universality of the MCP. But part of me can’t help wondering: isn’t this the idea of APIs in general? Replace MCP with REST and does that really change anything in the article? Or even an Operating System API? POSIX, anyone? Programs? Unix pipes? Yes, MCP is far simpler/universal than any of those things ended up being — but maybe the solution is to build simp…

MCP is not REST. In your comparison, its more that MCP is a protocol for discovering REST endpoints at runtime and letting users configure what REST endpoints should be used at runtime.

Say i'm building a app and I want my users to be able to play spotify songs. Yea, i'll hit the spotify api. But now, say i've launched my app, and I want my users to be able to play a song from sonofm when they hit play. Alright, now I gotta open up the code and do some if statements hard code the sonofm api and ship a new version, show some update messages.

MCP is literally just a way to make this extensible so instead of hardcoding this in, it can be configured at runtime

Re: MCP: An (Accidentally) Universal Plugin System

#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 how long it'll last, but I sure appreciate it.

Re: MCP: An (Accidentally) Universal Plugin System

#23
post #4

I don’t want to undermine the author’s enthusiasm for the universality of the MCP. But part of me can’t help wondering: isn’t this the idea of APIs in general? Replace MCP with REST and does that really change anything in the article? Or even an Operating System API? POSIX, anyone? Programs? Unix pipes? Yes, MCP is far simpler/universal than any of those things ended up being — but maybe the solution is to build simp…

honestly, yes - but MCP includes a really simple 'reflection' endpoint to list the capabilities of an API, with human readable docs on methods and types. That is something that gRPC and OpenAPI and friends have supported as an optional extension for ages, but it has largely been a toy. MCP makes it central and maybe that makes all the difference.

At a previous job most of our services supported gRPC reflection, and exploring and tinkering with these APIs using the grpc_cli tool was some of the most fun I had while working there. Building and using gRPC services in golang left a strong positive impression on me.

Re: MCP: An (Accidentally) Universal Plugin System

#24

Earlier quoted context omitted.

MCP without AI is just APIs. MCP is already a useless layer between AIs and APIs, using it when you don't even have GenAI is simply idiotic. The only redeeming quality of MCP is actually that it has pushed software vendors to expose APIs to users, but just use those directly...

And that’s the whole point - it’s APIs we did not have. Now app developers are encouraged to have a public, user friendly, fully functional API made for individual use, instead of locking them behind enterprise contracts and crippling usage limits.

Right, but we would have had them even if MCP did not exist. The need to access those APIs via LLM-based "agents" would have existed without MCP.

At work I built an LLM-based system that invoke tools. We started before MCP existed, and just used APIs (and continue to do so).

Its engineering value is nil, it only has marketing value (at best).

Re: MCP: An (Accidentally) Universal Plugin System

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

> I don't know how long it'll last

I'm just baffled no software vendor has already come up with a subscription to access the API via MCP.

I mean obviously paid API access is nothing new, but "paid MCP access for our entreprise users" is surely on the pipeline everywhere, after which the openness will die down.

Re: MCP: An (Accidentally) Universal Plugin System

#26

It's articles like this that tell you we're close to peak hype. There's nothing revolutionary about a text encoding plus a schema. SOAP could do this 20 years ago.

This reminded me of that HN comment on the Dropbox announcement post where the user says that theres nothing new about it since FTP and USB-sticks exist. Also, anyone who ever had the misfortune of using SOAP know how horrendeous it is. Truth is, sometimes the "new thing" does it better and wins out. Applications have standardized APIs now because of AI hype. This is a step in the right direction

Re: MCP: An (Accidentally) Universal Plugin System

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

Hype, certainly.

But the way I see it, AI agents created incentives for interoperability. Who needs an API when everyone is job secure via being a slow desktop user?

Well, your new personal assistant who charges by the Watt hour NEEDS it. Like when the CEO will personally drive to get pizzas for that hackathon because that’s practically free labor, so does everyone want everything connected.

For those of us who rode the API wave before integrating became hand-wavey, it sure feels like the world caught up.

I hope it will last, but I don’t know either.

Re: MCP: An (Accidentally) Universal Plugin System

#28
post #6
post #4

I don’t want to undermine the author’s enthusiasm for the universality of the MCP. But part of me can’t help wondering: isn’t this the idea of APIs in general? Replace MCP with REST and does that really change anything in the article? Or even an Operating System API? POSIX, anyone? Programs? Unix pipes? Yes, MCP is far simpler/universal than any of those things ended up being — but maybe the solution is to build simp…

The main difference between MCP and Rest is that MCP is self described from the very start. REST may have OpenAPI, but it is a later addon, and we haven't quite standardised on using it. The first step of exposing an MCP is describing it, for Rest is is an optional step that's often omitted.

isn't also SOAP self described?

Re: MCP: An (Accidentally) Universal Plugin System

#30
The author glosses over some practical realities. Just because something can be repurposed doesn't mean it should be. MCP was designed with specific assumptions about how AI models consume and process information. Using it as a general plugin system might work, but you'd likely hit limitations around things like authentication, real-time communication, or complex data flows that weren't priorities for the AI use case.
Post reply on HN