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

161–170 of 366 posts

Re: MCP: An (Accidentally) Universal Plugin System

#161

Post by renerick »

NomDePlum wrote: post #133
mort96 wrote: post #121

Earlier quoted context omitted.

Wait was it? HATEOAS is all about hypermedia, which means there must be a human in the loop being presented the rendered hypermedia. MCP seems like it's meant to be for machine machine communication, not human machine

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 human in the loop, decides what to put in it the input and when to press the button. A machine can't do that on its own (but LLMs potentially can), so a user is required. That also means that JSON APIs meant for purely machine to machine interactions, commonly referred to as REST, can't be considered HATEOAS (and REST) due to absence of hypermedia controls.

Further reading:

- https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi...

- https://htmx.org/essays/hateoas/

Re: MCP: An (Accidentally) Universal Plugin System

#162

Post by whitten »

freeone3000 wrote: post #147
visarga wrote: post #89

Earlier quoted context omitted.

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.

what is IFTTT ?

Re: MCP: An (Accidentally) Universal Plugin System

#164

Post by stavros »

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…

I haven't seen an app that didn't have an API create one via MCP. The only MCP servers I've seen were for things that I could already access programmatically.

Re: MCP: An (Accidentally) Universal Plugin System

#165

Post by lazyasciiart »

whitten wrote: post #162
freeone3000 wrote: post #147

Earlier quoted context omitted.

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.

what is IFTTT ?

If this then that - a zapier type glue provider.

Re: MCP: An (Accidentally) Universal Plugin System

#166

Post by lazyasciiart »

therein wrote: post #136
notatoad wrote: post #128

Earlier quoted context omitted.

the whole point of the article is that it doesn't need to be an LLM, MCP is just a standard way to expose tools to things that use tools. LLMs can use tools, but so can humans.

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

Maybe phrasing it this way will be the lightbulb moment for everyone who hasn’t got that yet.

Re: MCP: An (Accidentally) Universal Plugin System

#167

Post by doug_durham »

nikolayasdf123 wrote: post #37
Jonovono wrote: post #21

Earlier quoted context omitted.

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?

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.

Re: MCP: An (Accidentally) Universal Plugin System

#168

Post by doug_durham »

marcosdumay wrote: post #77
caust1c wrote: post #47

Earlier quoted context omitted.

In my mind the only thing novel about MCP is requiring the schema is provided as part of the protocol. Like, sure it's convenient that the shape of the requests/response wrappers are all the same, that certainly helps with management using libraries that can wrap dynamic types in static types, but everyone was already doing that with APIs already we just didn't agree on what that envelope's shape should be. BUT, with…

> the only thing novel about MCP is requiring the schema is provided as part of the protocol You mean, like OpenAPI, gRPC, SOAP, and CORBA?

Where is the mandatory human readable prose description of the purpose of the tool in any of those specs. It isn't. Also the simplicity of JSON interface descriptions is key.

Re: MCP: An (Accidentally) Universal Plugin System

#169

Post by mort96 »

NomDePlum wrote: post #133
mort96 wrote: post #121

Earlier quoted context omitted.

Wait was it? HATEOAS is all about hypermedia, which means there must be a human in the loop being presented the rendered hypermedia. MCP seems like it's meant to be for machine machine communication, not human machine

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?

If you have machine machine interaction, why would you use HTML with forms and buttons and text inputs etc? Wouldn't JSON or something else (even XML) make more sense?

Re: MCP: An (Accidentally) Universal Plugin System

#170

Post by doug_durham »

gavinray wrote: post #144
gdecaso wrote: post #141

Earlier quoted context omitted.

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

Where is "list-tools" in any of those low level protocols?
Post reply on HN