What if every REST API was already an MCP server?
A proposal to add a REST-compatible profile to MCP — so the hundreds of thousands of services that already have APIs can join the ecosystem without building anything new.
The problem
MCP adoption has a bottleneck
Every AI platform supports MCP. Every developer knows the term. But the number of services that have actually shipped MCP servers is still tiny. Building one means a new codebase, a new deployment, a new thing to maintain — separate from the REST API most services already have. For most companies, it keeps getting deprioritised.
The insight
Most MCP servers are just REST with extra steps
The vast majority of MCP integrations are straightforward request-response: the client calls the server, the server responds. OAuth for auth, JSON for data. The features that differentiate MCP from REST — bidirectional communication, stdio transport, stateful sessions — are rarely used in practice.
| What most MCP servers need | REST already has it |
|---|---|
| Tool discovery | OpenAPI spec |
| Tool definitions | operationId + JSON Schema |
| Authentication | OAuth 2.0 |
| Invoking a tool | HTTP request |
| Error handling | HTTP status codes |
| Streaming | Server-Sent Events |
The proposal
A REST-compatible profile for MCP 2.0
For a service that already has a REST API, MCP compatibility could be reduced to:
Serve an OpenAPI spec at /.well-known/mcp.yaml
A single route returning a static file.
Write descriptions for AI consumers
Review your operationId, summary, and description fields.
Support OAuth 2.0 with PKCE
Minor if you're using a standard OAuth library.
Return plain-language error messages
Probably already the case.
That's it. MCP compatibility goes from "build a new server" to "add a well-known URL and improve your descriptions."