Kind of--I'm saying that RESTful APIs are just an abstract vocabulary to describe state transfer operations, whereas MCP describes a concrete set of such operations. REST sits on top of the HTTP protocol layer, MCP sits on top of REST (if we accept how the meaning of REST has been butchered, but you know what I mean.)
This is easy to see when you think in terms of a client: It is pretty much impossible to build an opinionated UI for any kind of RESTful API, while creating one for an MCP server is fairly self-explanatory: MCP servers offer a mandatory and complete runtime introspection endpoint (you can retrieve a listing of available tools/resources/prompts etc. along with their parameter and return type schemas). So that means clients have a way to exhaustively describe everything an MCP server is able to do with a vocabulary that carries over exactly to other servers - a tool is a tool everywhere.
See my point #2. There are already standards to describe APIs.
This is easy to see when you think in terms of a developer. The natural way to adapt an existing REST API into an MCP server while keeping the two synchronized is to simply write a basic translation tool that takes your OpenAPI spec and turns it into an MCP manifest, mapping each HTTP endpoint to an MCP method, and copying over all the request / response type signatures and descriptions for everything. Then, all of the sudden, it hits you: there is no need for this translation layer.
I think OpenAPI does all you mentioned in your comment too. Maybe MCP is more strict, in the sense that it requires natural-language descriptions, which are optional in OpenAPI, but I don’t see the distinction.
There are multiple products that turn OpenAPI schemas into front-ends nowadays.
When I say REST, I basically mean HTTP/JSON. I know. Shame on me.
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.
REST has issues if you limit yourself to think of the “resources” as your domain entities.
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.
The read-only QUERY method can send much bigger requests than GET.
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.
Are you trying to say that REST APIs don't have a strict wire format with shared semantics for a huge range of features?
Kind of--I'm saying that RESTful APIs are just an abstract vocabulary to describe state transfer operations, whereas MCP describes a concrete set of such operations. REST sits on top of the HTTP protocol layer, MCP sits on top of REST (if we accept how the meaning of REST has been butchered, but you know what I mean.)
This is easy to see when you think in terms of a client: It is pretty much impossible to build an opinionated UI for any kind of RESTful API, while creating one for an MCP server is fairly self-explanatory: MCP servers offer a mandatory and complete runtime introspection endpoint (you can retrieve a listing of available tools/resources/prompts etc. along with their parameter and return type schemas). So that means clients have a way to exhaustively describe everything an MCP server is able to do with a vocabulary that carries over exactly to other servers - a tool is a tool everywhere.
See my point #2. There are already standards to describe APIs.
This is easy to see when you think in terms of a developer. The natural way to adapt an existing REST API into an MCP server while keeping the two synchronized is to simply write a basic translation tool that takes your OpenAPI spec and turns it into an MCP manifest, mapping each HTTP endpoint to an MCP method, and copying over all the request / response type signatures and descriptions for everything. Then, all of the sudden, it hits you: there is no need for this translation layer.
I think OpenAPI does all you mentioned in your comment too. Maybe MCP is more strict, in the sense that it requires natural-language descriptions, which are optional in OpenAPI, but I don’t see the distinction.
There are multiple products that turn OpenAPI schemas into front-ends nowadays.
Isn’t that the case? Aren’t REST people still debating about what makes a true beautiful REST API?
When I say REST, I basically mean HTTP/JSON. I know. Shame on me.
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.
REST has issues tough.
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?
REST has issues if you limit yourself to think of the “resources” as your domain entities.
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.
I think you provide good and accurate information. However, what you described sounds like a workaround to me.
The read-only QUERY method can send much bigger requests than GET.
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.
The wire format certainly isn’t strict