DEV Community

Om Shree
Om Shree

Posted on • Originally published at glama.ai

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 1.

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 23.

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 456.

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.

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 5.

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 1.

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 1.

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 1.

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:

{
  "jsonrpc": "2.0",
  "method": "sample_rows",
  "params": {"table": "sales", "limit": 5},
  "id": 1
}
Enter fullscreen mode Exit fullscreen mode

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 57. Batch calls and asynchronous notifications make tool chaining and complex workflows smoother.

Comparison Table

Feature REST gRPC JSON‑RPC
Human-readable Yes No Yes
Protocol Overhead Medium Low (binary) Low (text)
Streaming Support Limited Full duplex (HTTP/2) Basic via notifications
Setup Complexity Low High (codegen.required) Low
Transport Flexibility HTTP only HTTP/2 only HTTP, stdio, SSE, custom

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


  1. REST & RPC design differences – AWS comparison 

  2. gRPC overview – Wikipedia 

  3. gRPC vs REST analysis – DreamFactory blog 

  4. JSON‑RPC description – Wikipedia 

  5. MCP Transport options – Model Context Protocol docs 

  6. JSON‑RPC comparison article – Mertech blog 

  7. JSON‑RPC batching & notifications in MCP – MCP spec 

Top comments (2)

Collapse
 
thedeepseeker profile image
Anna kowoski

Great Article, I'm Curious to hear from others: which approach have they found more scalable in real-world agent deployments, centralized external memory, or distributed token-passing managed by the orchestrator?

Collapse
 
om_shree_0709 profile image
Om Shree

Thanks Anna, Glad you liked it!