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