Hacker News Reader

Comment by kvdveer | Hacker News Reader

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.

View on HN

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.

And gRPC with reflection, yeah?

and GQL with reflection?

JSON-LD?

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)

For each tool you get the human description as well as a JSON schema for the parameters needed to call the function.

You're getting an arbirary string back though...

how else would you describe an arbitrary tool?

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.

The description includes an input and output json schema.

Only input, not output.

https://modelcontextprotocol.io/specification/2025-03-26/ser...

You're not looking at the latest version. They added output schemas.

Thank you!

Reply on news.ycombinator.com