MCP vs. REST: Why do we need a new Protocol ?

[deepakgohil9]

Pre-submission Checklist

• I have verified this would not be more appropriate as a feature request in a specific repository
• I have searched existing discussions to avoid duplicates

Discussion Topic

REST APIs have been around for a long time, and they are widely adopted, well-documented, and already used in many systems. Instead of introducing a new protocol like MCP, why can't we simply build a middle layer that allows LLMs to interact with these existing REST APIs directly? Wouldn't this approach be more efficient, as it avoids the extra effort and cost of converting existing services (which are similar to 'tools' in agentic AI) from REST to MCP? This way, we could leverage the mature ecosystem of REST APIs without the need for major changes.

[Zhaobudaoyuema]

@deepakgohil9
I think the current SSE mode is actually a REST API as well. It provides the /sse and /message interfaces and uses the JSON-RPC data format.

I believe the key point is how to provide the model with descriptions of tools so that the model can call these tools.

Additionally, it has a local STDIO mode, which cannot be addressed by a REST API alone.

This is just my understanding, and I welcome any discussion.

[deepakgohil9]

@Zhaobudaoyuema

You're absolutely right that the current SSE mode functions similarly to a REST API, as it provides /sse and /message interfaces while using JSON-RPC over HTTP. However, what I want to highlight is the need for an out-of-the-box solution that directly supports calling any existing REST API without requiring additional adaptation or porting efforts.

Coming to the key point, how to provide LLMs with descriptions of available tools. I believe OpenAPI can be a strong solution. OpenAPI is a widely adopted standard for documenting REST APIs, and leveraging it could enable LLMs to understand and interact with APIs effectively without requiring a new protocol. Well-documented REST APIs with OpenAPI specs could serve as an excellent way to provide context to the model regarding the available tools.

Regarding the last point about the local STDIO mode, one possible alternative could be using loopback communication. This could serve as a bridge for local interactions without requiring a separate transport mechanism that deviates from standard RESTful interactions.

I look forward to understanding the reasoning behind choosing to create a new protocol like MCP instead of leveraging existing REST APIs!

[Zhaobudaoyuema]

https://github.com/orgs/modelcontextprotocol/discussions/134
Similar discussions that I have seen.

[Zhaobudaoyuema]

I think if you directly use REST API, you need to make some modifications.
For example, you need to provide an interface for obtaining tool descriptions and another interface for calling tools.
MCP has actually made these modifications and established a set of standards. As long as you follow this standard, my service can be openly used.

[sinclairjang]

Isn't MCP trying to establish a AI-native protocol? Then the question boils down to whether REST is apt for that purpose.
These are what I think REST comes short of being AI-native:

1. REST is stateless, but AI needs context
2. REST is built for humans, not AI Agents
3. REST is HTTP-only, but AI needs multi-protocol support

[Zhaobudaoyuema]

REST is stateless, but AI needs context

I didn't understand this. The context needed by AI is something that the host needs to resolve in the MCP. It is not something that the MCP protocol itself resolves.
In my logic, MCP is just a standard and then it calls tools. It provides tool descriptions and a call/tool capability.

[larryhopecode]

For example, client could get resource list from server and select a "root" for working scope. In this case, server needs to keep "state" with each client. So we need to build something on top of REST for sure.

[deepakgohil9]

@sinclairjang

I want to clarify that I’m not against MCP, but I’m trying to understand the actual reasons that led to the creation of a new protocol instead of leveraging existing REST APIs. The key idea I have in mind is creating a middle layer between AI and REST APIs to bridge them effectively. This could significantly reduce the time and cost required to make tools compatible with MCP. Instead of porting every tool to a new protocol, it might be more efficient to make AI compatible with REST.

Now, addressing each of the three points:

REST is stateless, but AI needs context

I feel that these two concepts are not directly related. REST’s stateless nature is primarily about enabling horizontal scaling by ensuring that servers do not need to store client session data. The key requirement in our case is that AI should have access to the history of tool calls to maintain context. However, this does not mean that the server itself needs to maintain state. Since the decision to call a tool at a given point is entirely made by AI, the necessary context should be maintained within the message history. Additionally, MCP's own roadmap mentions plans to support stateless operations, specifically for serverless environments:
"Stateless Operations: Thinking about whether MCP could encompass serverless environments too, where they will need to be mostly stateless."
MCP Roadmap

REST is built for humans, not AI agents

This statement isn’t entirely accurate. REST is not designed for humans but for machine-to-machine communication. It provides a standardized way for machines to interact over the web, which is similar to what MCP aims to achieve. The key difference is that REST has already been widely adopted, extensively battle-tested, and refined over years of real-world usage. If AI needs a structured way to interact with APIs, REST (with standards like OpenAPI) already provides that foundation.

REST is HTTP-only, but AI needs multi-protocol support

This point seems to refer to transport mechanisms. MCP currently supports both STDIO and SSE-based transport, but in practical scenarios, SSE will likely be more significant. Not everyone will run all tools locally, so the reliance on STDIO may be limited. If the goal is multi-protocol support, rather than introducing an entirely new protocol, why not extend REST-based solutions with additional transport layers where needed?

I’d love to understand more about the core motivations behind choosing MCP over enhancing REST-based solutions.

[pulkitsharma07]

I have similar thoughts, but I think I can give my two cents here. First of all "Tool calling" is just one part of MCP, there are more things like "Sampling" which allow the Server itself to initiate stuff on the client. As for tool calling, having a layer like MCP makes sense because there a lot of things which don't have a REST-API + may need direct access to the system (filesystem, processes, etc).

Examples:

• Running SQL commands on a DB or a Redis instance.
• Launching Docker containers, SSHing to a server an running some command.
• Reading a file and extracting relevant information from it, like OCR.
• Controlling a remote browser using the WebDriver protocol, have some kind of persistent connection to a backend.

As for just pure REST-API usecases, I think MCP serves what Swagger/OpenApi-Spec do, i.e. enforce some kind of format and give each endpoint a "Name" which the LLM can invoke. The issue is that there is no standardised way to pass these specs to LLMs as tools (maybe something can be built in this space). In the future I can easily see some kind of library/abstraction which allows an MCP server to parse an existing swagger spec file to expose those APIs as tools.

[strowk]

I think one important part for me about "REST is built for humans, not AI agents" is that while REST is designed for one machine to call another, all pre-existing API's were made to be understood by humans, not AI's. While AI's have capability to understand the same things, they really need to be laser focused on particular tasks or they would go about hallucinating and soon run out of context window.

The context window optimisation seems to me something where MCP can be used much more successfully than REST. Dumping the whole OpenAPI spec of your service to model context and make it call your service via built-in http tool is certainly possible and would work just fine, except you will run out of context window faster than if you described every resource as MCP tool (and quite possibly dumped some of them as some might be not usable for AI).

[strowk]

BTW I believe stdio is very significant and much more usable in a lot of scenarios. Whenever access is needed that is not easy to propagate (and when it is ever), local server really shines.

[phil-rice]

I've found this discussion very interesting—thanks for raising these points. Like Deepak, I also highly value REST, particularly its emphasis on decoupling. Roy Fielding famously noted that REST is "optimized for systems designed for decades." However, common implementations of REST today often fall short of this original vision.

One significant advantage MCP brings, particularly in the context of LLMs, is addressing a gap that current REST implementations struggle with: effective agency (autonomy in decision-making) for machine-based consumers. True REST, as envisioned by Fielding, heavily relies on hypermedia and dynamic resource discovery as well as programming against media representations instead of schemas. Browsers exemplify this perfectly; changing my corporate website doesn't require changes or redeployment of browsers. Yet, enterprise "RESTful" APIs often gravitate towards static, predefined interactions. OpenAPI schemas, despite their utility for human developers, reinforce tight client-server coupling due to their out-of-band nature (see https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven for why this is problematic), limiting flexibility and increasing maintenance overhead—creating distributed monoliths.

MCP explicitly aims to grant AI agents greater autonomy by structuring interactions around tools and resources rather than static endpoints. Leveraging AI autonomy, we can significantly reduce tight coupling between clients and servers. While REST focuses primarily on resources, MCP recognizes the distinct value of tools, providing first-class support. Many valuable tools are inherently stateful (e.g., login processes or operations with commit/rollback semantics). Achieving similar functionality in REST is possible but often involves substantial complexity unrelated to the actual task.

Another advantage of MCP worth highlighting is its support for server to client notifications. Implementing this capability in REST-based systems is often challenging, typically requiring polling. This feature significantly simplifies scenarios like Command Query Responsibility Separation (CQRS). From practical experience, I've observed that queue and message-based systems excel in scenarios beyond straightforward request-response interactions.

To summarize my personal motivations for saying 'why we need an MCP instead of just REST"

• Enables proper message passing in both directions
  *Supports stateful behavior for intrinsically stateful tools
  *Allows inversion of the usual "client asks server" flow, such as with server-initiated requests like "sampling"

[binnn6]

can't agree more

[brunogcarneiro]

Running terminal commands is the one capability that rules them all.

REST is limited to HTTP, while MCP spans multiple protocols. However, if the model can execute terminal commands, it can handle HTTP requests or any other protocol by itself (or CLI), making MCP servers unnecessary. The real benefit of MCP is to restrict the model’s total power, allowing only a controlled subset of capabilities.

For example, if a model can execute terminal commands, it can perform any AWS operation through the AWS CLI, leveraging its built-in understanding of the CLI documentation. If you introduce a newly created REST API that didn’t exist during the model’s training, simply provide its OpenAPI definition. Because the model already knows how to construct curl commands and has the capability of run them in the terminal, it can immediately make use of the new API.

[vitalets]

The real benefit of MCP is to restrict the model’s total power, allowing only a controlled subset of capabilities. For example, if a model can execute terminal commands, it can perform any AWS operation through the AWS CLI

But you can wrap AWS CLI into HTTP server restricting available commands - in the same way as creating a MCP server.

[wjw99830]

Maybe we need a HTTPServerTransport in most cases, rather than SSEServerTransport?

As mentioned above, remote connection to server is one of its capabilities. There are many capabilities like fs, cmd even system setting run on the local environment. MCP is not just a protocol based on network like http.

[jasongodev]

MCP is trying to look "new" but it could have been a bunch of standardized REST API endpoints.

A backend MCP server could have been just an API server that has something like /api/tools for tools discoverability, /api/tools/weather for a weather app endpoint where other AI services and clients can submit requests, /api/promptTemplates for acceptable prompts to interface with the tools, /api/format endpoint to get possible response format allowed by the Ai service, /api/auth for permissions, etc.

Also, when you look at MCP server and client codes, there is no code pattern or framework that makes the code "MCP". The current MCP implementations does not have a distinct identity to be called as a new protocol. It's just unnecessary abstractions implemented arbitrarily (but still just REST API), and for the sake of calling it an LLM interface protocol everyone is calling it MCP.

It seems that MCP is an example of a "do not reinvent the wheel" case against existing standards like REST API.

[skamalj]

I have been struggling with this "MCP" vs "Rest' as well. I have been trying to implement lot of this on cloud and sticking with serverless, like AWS Lambda, Azure functions etc. MCP forces me to containerize its implementation., so on AWS, lambda is ruled out, ECS + API GW is the option, on GCP cloud run and so on.
It would have been better to support both "MCP" and "Rest", if we really had to go with "MCP". User should have been allowed to choose between these two.