I have been developing with MCP for a few weeks now, making some small python and javascript servers to integrate with Claude Desktop.
I am yet to see a use case that wouldn't be better served with an HTTP API. I understand the need to standardize some conventions around this, but at the heart of it, all "tool" use boils down to: 1. an API endpoint to expose capabilities / report the API schema 2. other endpoints ("tools") to expose functionality
Want state? ("resources") - put a database or some random in-memory data structure behind an API endpoint. Want "prompts"? This is just a special case of a tool.
Fundamentally (like most everyone else experimenting with this tech), I need an API that returns some text and maybe images. So why did I just lose two days trying to debug the Python MCP SDK, and the fact that its stdio transport can't send more than a few KB without crashing the server?
If only there was a stateless way to communicate data between a client and a server, that could easily recover from and handle errors...
APIs aren't self describing by default, but it feels like a missed opportunity for REST and HATEOAS proponents to show the value in those approaches. I've always said REST is for human clients, and LLMs seem like they should be human enough for this kind of thing.
MCP is not self describing by default either.
I can implement a tool and not add it to the definitions, much like you can implement an API endpoint and not add it to the spec.
This is a documentation/code synchronization problem that is solved the same way for both MCP and REST, generate documentation from code.
Rest is for people who thought xml was a good idea.