The 30 second answer
I choose based on who the caller is, not on which name is fashionable. REST fits public and partner HTTP clients, browsers, caches and OpenAPI toolchains. gRPC fits internal, typed, often streaming service-to-service calls, as long as load balancers understand HTTP/2. MCP fits an AI host that must discover tools at runtime and let a model choose among them, usually as a façade over an existing API.
I do not treat these as competing products. I treat them as façades, and I pick the façade that matches the caller.
Prefer REST when the callers are diverse and HTTP-native: public or partner APIs, browsers, mobile clients, or teams that already standardise on OpenAPI, API gateways and caches. Use it when intermediary caching, content negotiation and a uniform resource model matter. Zalando's public guidelines make this the default style for microservice HTTP APIs.
Prefer gRPC when both ends are under your control, you want a typed, code-generated contract, and you need multiplexed or streaming RPCs between services. It is a strong default for internal, high-chatter service-to-service calls, with the operational caveat that load balancers must be HTTP/2-aware or the client must balance per RPC. Do not expect browsers to speak it without gRPC-Web.
Prefer MCP when the immediate caller is an AI host that must discover capabilities at runtime and let a model choose among tools. Use it as a façade over existing systems rather than as a replacement for your service-to-service API. Keep the durable business contract in REST or gRPC; expose a small, well-described tool surface through MCP.
Avoid false oppositions. "REST versus API" is a category error. "MCP versus REST" is usually "which façade do we offer?", not "which one is the system of record?". "gRPC is always faster than REST" is not a claim this answer will make; measure the actual workload if performance is the decision driver. Binary protobuf and multiplexed HTTP/2 streams reduce payload size and connection overhead for chatty RPC, and HTTP caching helps when REST responses are cacheable, but the gain depends on the workload.
Side-by-side comparison:
| Dimension | REST, typical HTTP JSON API | gRPC | MCP, revision 2026-07-28 |
|---|---|---|---|
| Transport | HTTP/1.1, HTTP/2 or HTTP/3. Each call is an HTTP request to a resource URI. | Native protocol is HTTP/2 streams. Connections are long-lived. | stdio, newline-delimited JSON-RPC, or Streamable HTTP POST to one endpoint. HTTP+SSE is deprecated. |
| Payload format | Commonly JSON, any media type via content negotiation. | Default is binary protobuf; a JSON mapping exists but is secondary. | JSON-RPC 2.0 messages. Tool arguments follow JSON Schema. |
| Contract and schema | OpenAPI, or similar, describes paths, methods and schemas, often written first. | A proto file for messages and services; protoc generates stubs. Field numbers are the wire contract. | MCP methods are fixed by the protocol. Tool, resource and prompt shapes are discovered at runtime and described with JSON Schema. |
| Discovery | Documentation, OpenAPI, sometimes hypermedia links. Most clients are generated or hand-written against a known URI set. | The service list is known at compile time from the proto file. | server/discover, then tools/list, resources/list, prompts/list. The model is given those descriptions at runtime. |
| Streaming | HTTP response bodies can stream. Not a first-class RPC pattern. | First-class: unary, server streaming, client streaming, bidirectional. | Request-scoped SSE on Streamable HTTP, and subscriptions/listen for change notifications. Not a general bidirectional RPC model like gRPC. |
| Typical use | Public and partner HTTP APIs, browsers, mobile apps, microservice HTTP façades, caches and CDNs. | Service-to-service calls, polyglot backends, low-latency streaming, typed internal contracts. | Connecting LLM hosts to tools and context: IDE assistants, chat apps, agent workflows. |
| Tooling | curl, browsers, API gateways, OpenAPI codegen, Spring Boot MVC, caches, CDNs. | protoc, language stubs, grpcurl, Envoy and other HTTP/2 proxies, gRPC libraries. | MCP SDKs, MCP Inspector, host applications, OAuth for remote HTTP servers. |
| Performance, qualitative only | Text JSON is larger and cheaper to debug. Benefits from HTTP caching and CDNs when responses are cacheable. No multiplier is claimed here. | Compact binary messages and multiplexed HTTP/2 streams reduce payload size and connection overhead for chatty RPC. Actual gain depends on the workload. | JSON-RPC over stdio or HTTP. Optimised for tool orchestration and discoverability, not for high-QPS internal RPC. |
| Browser support | Native. This is the web's native API style. | Not native. Requires gRPC-Web plus a proxy. Unary and server streaming only in typical browser transports. | A host in the browser can use Streamable HTTP. MCP is usually spoken by the host, not by page JavaScript calling a public API the way it would call REST. |
| Who the caller is | A developer-written client: browser, app or another service, using a contract known at build time. | Almost always another service or a generated client, using stubs known at build time. | The host, acting for a user and a language model. The model selects tools at runtime; a human should be able to approve or deny calls. |
The same search capability can be offered all three ways, with one system of record:
GET /product-offers?q=navy%20sneakers&limit=2 HTTP/1.1
Host: catalog.example.com
Accept: application/jsonservice Catalog {
rpc Search(SearchRequest) returns (SearchResponse);
rpc SearchStream(SearchRequest) returns (stream SearchHit);
}{
"jsonrpc": "2.0",
"id": 2,
"method": "tools/call",
"params": {
"name": "search_product_offers",
"arguments": {"query": "navy sneakers", "limit": 2},
"_meta": {
"io.modelcontextprotocol/protocolVersion": "2026-07-28",
"io.modelcontextprotocol/clientCapabilities": {}
}
}
}Alternate interview scenarios
"We need partners, internal search services and an in-house assistant to query the same catalogue. Which API do we build?"
All three façades, one backend. Partners get a REST API with OpenAPI, pagination and Problem JSON. Internal services get gRPC, with a deadline on every call and an HTTP/2-aware load balancer. The assistant gets an MCP tool that wraps the same search, with a tight schema and a consent step. I would not ask the partner integration to speak MCP, and I would not ask the model to compile against a proto file.
"Is MCP going to replace our REST APIs?"
Not as the system of record. MCP is a runtime-discovery protocol for AI hosts. Replacing a stable public or internal contract with a tool list the model chooses from would throw away caching, generated clients, HTTP semantics and a reviewable OpenAPI or proto file. Wrap the existing API; do not delete it.
Sources (4)
- Zalando RESTful API and Event Guidelinesopensource.zalando.com
- gRPC core conceptsgrpc.io
- MCP specification, 2026-07-28modelcontextprotocol.io
- Fielding dissertation, Chapter 5ics.uci.edu