Hacker News Reader

Comment by Karrot_Kream | Hacker News Reader

MCP is just RPC over a long-lived connection, most cases being a Websocket. IMO RPC is easier to setup because:

1. There's less bikeshedding for the authors about whether modifying a field in a user object should be a PUT or a POST replacing the original user object. I've spent a non-trivial amount of time bikeshedding over REST verbs.

2. LLMs don't need to understand the REST semantics of the API. It can just look at available RPC methods and make the RPC call it thinks will work.

I think that's really it.

View on HN

MPC is more than just a standard way to access remote functionality - it also provides discoverability so the client (LLM) can ask the server what functionality it offers, and understand how to use it.

Sure but there are established alternatives for that also. The internet supports looking up DNS records (A, MX, SRV, TXT, etc), the web offers /.well-known as a place to store things like API endpoint specs, etc. The main difference with MCP is that the discoverability comes with the stream-oriented communication semantics.

Well, you’re basically saying that different domains have different solutions to this problem. There isn’t a universally accepted way to do client discovery, and what exists are very specific to those domains.

> There isn’t a universally accepted way to do client discovery, and what exists are very specific to those domains.

I commented elsewhere on this recently, https://news.ycombinator.com/item?id=44063680, but a huge value of LLMs is you don't need a "universally accepted way to do client discovery" - if you have an exposed API that already supports one of the bajillion standards that expose schema information (e.g. Swagger/OpenAPI, GraphQL, SOAP, etc.), then any decent LLM should just be able to figure out how to use it.

This idea that we need "one more universal interop standard to rule them all" seems to me like a very pre-LLM way of thinking.

> if you have an exposed API that already supports one of the bajillion standards that expose schema information

I don't know jf they are doing it well with MCP, but if a solution has one extra round trip in the model for a dependent read it has to reprocess the entire context or store it into a cache hierarchy possibly burning several hundred gigs of ssd write durability if it isn't a short enough time to cache in system RAM.

Oh great, just what I need for my finance stack, an API with built in AI hallucinations :/

the thing with building interconnected software is that we should resist the urge to just let the AI perform magic and somehow reliably mix and match all these overlapping things. We should have ONE clearly defined contract. There is no evidence that this principle can be challenged even at the current state of LLM.

> There isn’t a universally accepted way to do client discovery

Someone should really create a protocol to transfer hyper text where clients could discover resources through embedded links in documents

I don't think it's accurate to describe .well-known as "very specific to [a domain]"

It’s at least restricted to http servers. Certainly more once you include domain specific conventions

That’s far from unheard of in RPC protocols? E.g. the system namespace of xml-rpc.

maybe REST? I think a proper REST system of APIs is designed to be discoverable.

REST is a design principle, not a protocol.

As such you can make a REST system discoverable via e.g. external schemas (commonly OpenAPI) or self-documentation but there is no guarantee that either exists, and while the latter is intrinsic there is no standard discovery mechanism for the former (cf openapi-specification issues 724 or 2128).

Right, our MCP server we’ve productionized supports this. It’s really fantastic when it works well. Lotta work to do to make it work well more often though!

>MCP is just RPC over a long-lived connection, most cases being a Websocket.

My impression was that MCP used SSE and that not using websockets was one of the main reasons it isn't enterprise ready - because it requires maintaining server side state which makes it difficult to deploy at scale. Did they change it to websockets?

https://raz.sh/blog/2025-05-02_a_critical_look_at_mcp

Not "change" but it does seem to be an option https://modelcontextprotocol.io/specification/2025-03-26/bas...

As for the stateless part, they heard you and made sure to bring sessions back to SSE: https://modelcontextprotocol.io/specification/2025-03-26/bas...

It isn't "just RPC". The response from an MCP Server Tool is supposed to be LLM-Ready Context. Normal API or RPC calls are responses designed for other software to ingest. If you simply attach an existing API you get a context flooded with detail it likely doesn't need.

I use RPC in combination with vector search and a embedded model to get AI ready content. Would you define this as MCP?

Isn't it just an extension of Swagger, ensuring the API is well documented so the LLM can properly use it?

Doesn't seem to have any other real magic. It could be replaced by an additional field which acts as the LLM equivelent of a doc string in python.

Reply on news.ycombinator.com