Hacker News Reader

Comment by Jonovono | Hacker News Reader

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

View on HN

That only works if you let the LLM do the interpretation of the MCP descriptions, in the case of TFA the idea was to use MCP without LLM, which is essentially same as any old API.

You can use MCP to dynamically call different services, without ever having to use an LLM to decide.

With an LLM it would go

List MCP Tools -> Get User prompt -> Feed both into LLM -> LLM tells you what tools to call

You could skip the LLM aspect completely and get all tools and let the user at runtime pick the tool that "playsSong" for example

HATEOAS was supposed to be that.

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

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

I agree that HATEOAS never made sense without a human in the loop, although I also have never seen it be described as such. IMO that’s an important reason why it never gained useful traction.

There is a confused history where Roy Fielding described REST, then people applied some of that to JSON HTTP APIs, designating those as REST APIs, then Roy Fielding said “no you have to do HATEOAS to achieve what I meant by REST”, then some people tried to make their REST APIs conform to HATEOAS, all the while that change was of no use to REST clients.

But now with AI it actually can make sense, because the AI is able to dynamically interpret the hypermedia content similar to a human.

Hypermedia isn't just for human consumption. Back in the 90s, the Web was going to be crawled by "User Agents": software performing tasks on behalf of people (say, finding good deals on certain items; or whatever). Web browsers (human-driven interfaces) were the most common User Agent, but ended up being a lowest-common-denominator; the only other User Agents to get any widespread support were Google crawlers.

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/

So that's not my understanding. Hypermedia, as I understand it, are embedded links in responses that present possible forward actions.

They are structured in a way that machine program could parse and use.

I don't believe it requires human-in-the-loop, although that is of course possible.

HTML is a hypermedia format, the most widely used, and it's designed mainly for human consumption. Machines parsing and using something is too broad an idea to engage with meaningfully: browsers parse HTML and do something with it: they present it to humans to select actions (i.e. hypermedia controls) to perform.

Your understanding is incorrect, the links above will explain it. HATEOAS (and REST, which is a superset of HATEOAS) requires a consumer to have agency to make any sense (see https://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.h...)

MCP could profitably explore adding hypermedia controls to the system, would be interesting to see if agentic MCP APIs are able to self-organize:

https://x.com/htmx_org/status/1938250320817361063

I've programmed machines to use those links so I'm pretty certain machines can use it. I've never heard of the HTML variation but so will have a look at those links.

> I've programmed machines to use those links so I'm pretty certain machines can use it

I'm curious to learn how it worked.

The way I see it, the key word here is "programmed". Sure, you read the links from responses and eliminated the need to hardcode API routes in the system, but what would happen if a new link is created or old link is unexpectedly removed? Unless an app somehow presents to the user all available actions generated from those links, it would have to be modified every time to take advantage of newly added links. It would also need a rigorous existence checking for every used link, otherwise the system would break if a link is suddenly removed. You could argue that it would not happen, but now it's just regular old API coupling with backward compatibility concerns.

Building on my previous example of hn comments, if hn decides to add another action, for example "preview", the browser would present it to the user just fine, and the user would be able to immediately use it. They could also remove the "reply" button, and again, nothing would break. That would render the form somewhat useless of course, but that's the product question at this point

Yes, most of your observations about limitations are true. That doesn't mean it's not a useful technique.

This is a reasonable summary of how I understand it: https://martinfowler.com/articles/richardsonMaturityModel.ht...

This aligns with how I've seen it used. It helps identify forward actions, many of which will be standard to the protocol or to the domain. These can be programmed for and traversed, called or aggregated data presented using general or specific logic.

So New actions can be catered for but Novel actions cannot, custom logic would require to be added. Which then becomes part of the domain and the machine can now potentially handle it.

Hope that helps illustrate how it can be used programmatically.

how did the machines you programmed react to new and novel links/actions in the response?

New are fine, Novel need catered for. I have left a fuller explanation to a sibling comment.

Right, so that means that the primary novel aspect of REST (according to the coiner of that term, Roy Fielding), the uniform interface, is largely wasted. Effectively you get a level of indirection on top of hard-coded API response endpoints. Maybe better, but I don't think by much and a lot of work for the payoff.

To take advantage of the uniform interface you need to have a consumer with agency who can respond to new and novel interactions as presented in the form of hypermedia controls. The links above will explain more in depth, the section on REST in our book is a good overview:

https://hypermedia.systems/components-of-a-hypermedia-system...

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?

heh, there was a good convo about HATEOAS and MCP on HN awhile back:

* https://news.ycombinator.com/item?id=43307225

* https://www.ondr.sh/blog/ai-web

MCP is a JSON RPC implementation of OpenAPI, or, get this, XML and WSDL/SOAP.

WSDL triggered me ha. I'm afraid you're right

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

You will need to do that anyway. Easier discovery of the API doesn't say much.

The user might want a complicated functionality, which combines several API calls, and more code for filtering/sorting/searching of that information locally. If you let the LLM to write the code by itself, it might take 20 minutes and millions of wasted tokens of the LLM going back and forth in the code to implement the functionality. No user is going to find that acceptable.

so... is this OpenAPI then?

Basically, yes. But with much more enthusiasm!

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.

Can't you just build a simple REST that takes this abstraction of plugging in different song providers away?

Feels like segment.com but for calling APIs rather than adding libraries to the frontend.

Now make the segment for MCPs ;p

Reply on news.ycombinator.com