Why MCP Uses JSON-RPC Instead of REST or gRPC

When AI agents need to call external tools or services, a communication protocol needs to be both reliable and easy to use. MCP adopts JSON‑RPC 2.0, but how does that stack up against the more familiar REST or the high-performance gRPC? In this article, we explore the strengths and trade-offs of each, and explain why JSON‑RPC is the right fit for MCP.

REST vs gRPC vs JSON‑RPC

REST (Representational State Transfer)

REST uses HTTP methods like GET, POST, and PUT to manipulate resources via URLs. It's familiar and well-supported. You can quickly test REST endpoints using tools like curl or Postman. But issues arise when trying to perform specific actions or commands like run_analysis, which don't map naturally to resource operations. This often results in awkward workarounds or over-engineered routes that distract from core logic ¹.

gRPC (Google Remote Procedure Call)

gRPC uses Protocol Buffers and HTTP/2 to offer fast, bidirectional streaming and strongly-typed communication. It's optimized for high-throughput environments like microservices. However, it requires code generation, lacks browser support, and the binary format makes debugging harder, especially for developers who prefer transparency and simplicity ²³.

JSON‑RPC (JSON Remote Procedure Call)

JSON‑RPC uses JSON-based method calls to invoke remote functions. It supports batch requests and notifications, and works over various transports like stdio or HTTP. It's human-readable, simple to debug, and aligns well with agent‑based workflows where "actions" like query_data or generate_report are invoked directly. Its flexibility makes it a practical choice for diverse development environments ⁴⁵⁶.

Why JSON‑RPC Makes Sense for MCP

1. Method-Level Clarity JSON‑RPC uses named methods like run_analysis() instead of navigating to resource URLs. This mirrors how agents think, focused on actions, not data nouns, making it easier to reason about intent and debug interactions. One developer noted, “REST is for nouns while JSON‑RPC is for verbs” ².

2. Flexible Transport Options MCP tools can operate via stdio when run locally, or via HTTP/SSE when hosted in the cloud, all using the same protocol. That pluggable flexibility simplifies deployment across environments ⁵.

3. Human-Readable Format JSON is easy to read, log, and replay. This transparency makes it straightforward to inspect RPC calls and responses during development or troubleshooting.

4. Supports Real-Time Interaction & Batching JSON‑RPC supports notifications (e.g., status updates) and batch requests, enabling agents to handle streaming or multi-step workflows without resorting to complex HTTP polling ¹.

5. Low Development Overhead You don’t need to define Protobuf schemas, compile stubs, or manage binary serialization. JSON‑RPC can be adopted quickly with minimal tooling overhead ¹.

6. Wide Platform Compatibility Because it’s based on JSON, not binary formats JSON‑RPC works in browsers, CLIs, and across programming languages without special client libraries ¹.

Behind the Scenes

Under the hood, MCP uses JSON‑RPC 2.0. Each tool is defined with its method name, input schema, and transport configuration. Clients send calls like:

Servers respond with corresponding result or error. MCP supports streaming via Server‑Sent Events (SSE) or stateless stdio making tools compatible across desktop and cloud environments ⁵⁷. Batch calls and asynchronous notifications make tool chaining and complex workflows smoother.

Comparison Table

My Thoughts

JSON‑RPC strikes the right balance for MCP: it's structured without being overly complex, readable without sacrificing flexibility, and versatile across platforms. It provides consistency for agent-to-tool communication without locking developers into heavy frameworks. While gRPC might be better for ultra-high-performance systems, MCP prioritizes ease of use and adaptability and JSON‑RPC delivers exactly that.

References