Live data from Hacker News

MCP: An (Accidentally) Universal Plugin System

worksonmymachine.substack.com

31–40 of 366 posts

Re: MCP: An (Accidentally) Universal Plugin System

#31
post #6

Earlier quoted context omitted.

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.

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.

> It would have been much better if the description language had been more formalized.

To speculate about this, perhaps the informality is the point. A full formal specification of something is somewhere between daunting and Sisyphean, and we're more likely to see supposedly formal documentation that nonetheless is incomplete or contains gaps to be filled with background knowledge or common sense.

A mandatory but informal specification in plain language might be just the trick, particularly since vibe-APIing encourages rapid iteration and experimentation.

Re: MCP: An (Accidentally) Universal Plugin System

#32

Yes, I'm old. Old enough to remember the MCP when he was just a chess program! He started small, and he'll end small!

Sounds like programming! What happened to low code/no code? I AM old, retired in fact. IT has more "middleware" than the library of congress and mainframes still exist. But I will dig around, because I'm still curious. Carry on. LOL

Re: MCP: An (Accidentally) Universal Plugin System

#33

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.

> it’s APIs we did not have

Isn't that what we had about 20 years ago (web 2.0) until they locked it all up (the APIs and feeds) again? ref: this video posted 18 years ago: https://www.youtube.com/watch?v=6gmP4nk0EOE

(Rewatching it in 2025, the part about "teaching the Machine" has a different connotation now.)

Maybe it's that the protocol is more universal than before, and they're opening things up more due to the current trends (AI/LLM vs web 2.0 i.e. creating site mashups for users)? If it follows the same trend then after a while it will become enshittified as well.

Re: MCP: An (Accidentally) Universal Plugin System

#34
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.

> we will point to the tool's documentation or OpenAPI

You can already do this as long as your client has access to a HTTP MCP.

You can give the current generation of models an openAPI spec and it will know exactly what to do with it.

Re: MCP: An (Accidentally) Universal Plugin System

#35

Earlier quoted context omitted.

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).

As https://www.stainless.com/blog/mcp-is-eating-the-world--and-... recaps, tool calling existed before MCP, some vague standards existed, nothing took off, no really normal users don't want to just download the OpenAPI spec.

Anthropic wants to define another standard now btw https://www.anthropic.com/engineering/desktop-extensions

Re: MCP: An (Accidentally) Universal Plugin System

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

so... is this OpenAPI then?

Re: MCP: An (Accidentally) Universal Plugin System

#38
post #28
post #6

Earlier quoted context omitted.

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?

And gRPC with reflection, yeah?

Re: MCP: An (Accidentally) Universal Plugin System

#39
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.

Is it "self-described" in the sense I can get a list of endpoints or methods, with a human- (or LLM-) readable description for each - or does it supply actual schemata that I could also use with non-AI clients?

(Even if only the former, it would of course be a huge step forward, as I could have the LLM generate schemata. Also, at least, everyone is standardizing on a base protocol now, and a way to pass command names, arguments, results, etc. That's already a huge step forward in contrast to arbitrary Rest+JSON or even HTTP APIs)

Re: MCP: An (Accidentally) Universal Plugin System

#40
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.

> we will point to the tool's documentation or OpenAPI You can already do this as long as your client has access to a HTTP MCP. You can give the current generation of models an openAPI spec and it will know exactly what to do with it.

you don't even need MCP for that. just access to hosted swagger file.
Post reply on HN