Isn’t that the case? Aren’t REST people still debating about what makes a true beautiful REST API?
But there's a pretty large body of RFCs that define what makes a good REST API. For instance POST should create things, PUT should re-define them, PATCH should incrementally update them, GET must be side-effect-free, etc. And there's a ton of standard HTTP headers. Pair it with OpenAPI and the whole thing is self-documenting. You can achieve the same effect with gRPC + reflection, or GraphQL + reflection, and there's plenty of mature tooling and interoperability for each system.
By comparison, MCP actually has relatively few conventions. LLMs are very familiar with REST and OpenAPI already. Just use that.
How do you send a big read only query? A POST? A GET hoping nothings logs it or swallows half of it?
How do you deal with delayed answers? Things that most HTTP middleware will timeout long before the result is achieved?
If you have a long running search, the resource is the search. Create a search. Fetch search results. Delete the search when you’re done.
Similarly, if you have a sufficiently complex command, the resource is the command itself. Maybe it requires async work, and you can later fetch the command results.
Anecdotally, this seems to be too big of a leap in mental model for beginners, mostly because all of the REST learning path does is teach you how to use it in CRUD domains.
For delayed answers, MCP offers no improvement, because remote MCP servers use an HTTP transport anyway, and local ones don't involve middleware you can't control. Besides, that's well-trodden ground. SSE, trailers, gRPC streaming, websockets, simple polling, etc. We don't need another protocol.