Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MCP: An (Accidentally) Universal Plugin System

worksonmymachine.substack.com

Post reply on HN
Print view View original

141–150 of 366 posts

Re: MCP: An (Accidentally) Universal Plugin System

#141

Post by gdecaso »

jadar wrote: 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 `list-tools`.

REST APIs have 5 or 6 ways of doing that, including "read it from our docs site", HATEOAS, OAS running on an endpoint as part of the API.

MCP has a single way of listing endpoints.

Re: MCP: An (Accidentally) Universal Plugin System

#142

Post by gdecaso »

sureglymop wrote: post #95

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…

[dead]

Re: MCP: An (Accidentally) Universal Plugin System

#143

Post by jasondclinton »

TZubiri wrote: post #108
jampa wrote: 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 wasn't able to find a good source on it, but I read a couple of times that Anthropic (builders of MCP) do astroturfing/shilling/growth hacking/SEO/organic advertisement. Everything I've read so far with MCP and Claude and the hype I see on social media is consistent with that, hype and no value.

This is false.

Re: MCP: An (Accidentally) Universal Plugin System

#144

Post by gavinray »

gdecaso wrote: post #141
jadar wrote: 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 `list-tools`. REST APIs have 5 or 6 ways of doing that, including "read it from our docs site", HATEOAS, OAS running on an endpoint as part of the API. MCP has a single way of listing endpoints.

WSDL + XML API's have been around since 1998.

OpenAPI, OData, gRPC, GraphQL

I'm sure I'm missing a few...

Re: MCP: An (Accidentally) Universal Plugin System

#145

Post by graerg »

sureglymop wrote: post #95

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…

This has been my take, and maybe I'm missing something, but my thinking has been that in an ideal case there's an existing API with an OpenAPI spec you can just wrap with your FastMCP instantiation. This seemed neat, but while I was trying to do authenticated requests and tinkering with it with Goose I ended up just having Goose do curl commands against the existing API routes and I suspect with a sufficiently well documented OpenAPI spec, isn't MCP kinda moot?

On the other hand, in the absence of an existing API, you can implement your MCP server to just [do the thing] itself, and maybe that's where the author sees things trending.

Re: MCP: An (Accidentally) Universal Plugin System

#146

Post by kerng »

Szpadel wrote: post #28
kvdveer wrote: 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?

When I read about MCP the first time and saw that it requires a "tools/list" API reminded me of COM/DCOM/ActiveX from Microsoft, it had things like QueryInterface and IDispatch. And I'm sure that wasn't the first time someone came up with dynamic runtime discovery of APIs a server offers.

Interestingly, ActiveX was quite the security nightmare for very similar reasons actually, and we had to deal with infamous "DLL Hell". So, history repeats itself.

Re: MCP: An (Accidentally) Universal Plugin System

#147

Post by freeone3000 »

visarga wrote: post #89
phh wrote: 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…

The issue holding us back was never that we had to write a frontend — it was the data locked behind proprietary databases and interfaces. Gated behind API keys and bot checks and captchas and scraper protection. And now we can have an MCP integrator for IFTTT and have back the web we were promised, at least for a while.
Post reply on HN