[gdecaso]

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.

[OJFord]

> The main difference between MCP and REST is `list-tools`.

> REST APIs have 5 or 6 ways of doing that

You think nobody's ever going to publish a slight different standard to Anthropic's MCP that is also primarily intended for LLMs?

[doug_durham]

Why would they? I'm sure the "Enterprise" folks are putting together some working group to develop ANSI-xyzzy standard for Enterprise operability which will never see the light of day.

[OJFord]

Because they genuinely think it'll work better, because they think it will build brand awareness/moat, because they're upset MCP comes from a competitor

[gavinray]

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

OpenAPI, OData, gRPC, GraphQL

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

[anon7000]

In other words, there’s no commonly-used, agreed upon standard for creating APIs. The closest is REST-like APIs, which are really no more specific than “hit a URL and get some data back”.

So why are we all bitching about it? Programmatically communicating with an ML model is a new thing, and it makes sense it might need some new concepts. It’s basically just a wrapper with a couple of opinions. Who cares. It’s probably better to be more opinionated about what exactly you put into MCP, rather than just exposing your hundreds of existing endpoints.

[jjfoooo4]

I don’t think the comments here are complaining, they are pointing out that what’s being claimed as being new is not actually new

[doug_durham]

Where is "list-tools" in any of those low level protocols?

[opliko]

I don't know enough about OData, but:

- Introspection (__schema queries) for every graphQL server. You can even see what it exposes because most services expose a web playground for testing graohQL APIs, e.g. GitHub: https://docs.github.com/en/graphql/overview/explorer

- Server Reflection for gRPC, though here it's optional and I'm not aware of any hosted web clients, so you'll need a tool like gRPCCurl if you want to see how it looks in real services yourself.

- OpenAPI is not a protocol, but a standard for describing APIs. It is the list-tools for REST APIs.

[debugnik]

All of them already provide an IDL with text descriptions and a way to query a server's current interface, what else do we need? Just force those two optional features to be required for LLM tool calls and done.

Is there anything stopping generic MCP servers for bridging those protocols as-is? If not, we might as well keep using them.