A gRPC Transport for the Model Context Protocol

AI agents are moving out of demos and into real enterprise systems. That shift changes the requirements. When an agent is calling tools that touch production data, "it works on my laptop" isn't good enough anymore. You need reliable, structured, observable communication between the agent and everything it talks to.

The Model Context Protocol (MCP) has become the standard for that agent-to-tool communication. But there's a gap I keep running into: most enterprises already run their internal services on gRPC, while MCP's default transport is JSON-RPC. So today, if you want your agents to talk to your gRPC services over MCP, you end up putting transcoding gateways in the middle. That's extra infrastructure, extra latency, and one more thing to break.

The obvious question: why not just run MCP over gRPC directly?

Why gRPC makes sense as the transport

Smaller, faster messages. Protobuf's binary encoding produces messages roughly 10x smaller than the equivalent JSON. For agent workloads that make a lot of tool calls, that adds up to lower latency and lower network costs.

HTTP/2 under the hood. Client and server can continuously send data over a single persistent connection. No connection churn, and streaming is native rather than bolted on.

Built-in flow control. Backpressure is part of the transport itself. If a server is drowning, the protocol handles it instead of your application code.

Security that enterprises actually need

This is where the case gets stronger for anyone running agents in production:

Identity and encryption: Mutual TLS and SPIFFE identity support give you secure, verified communication between services. Authentication: Native hooks for JWT and OAuth, so access control plugs into what you already use. Granular authorization: Method-level authorization means you can permission individual operations across your service mesh, not just whole endpoints.

An agent that can call tools is only as trustworthy as the auth around those calls, so I don't think of this as a nice-to-have.

Operational maturity

gRPC has been running at scale for a decade, and it shows:

OpenTelemetry integration for observability across the stack Deadlines, timeouts, and flow control built in Protobuf's strict typing rejects malformed inputs before they reach your handler Metadata support for extensible per-request context xDS support for proxyless service mesh setups Mature libraries in C++, Go, Python, Java, Node, PHP, and Rust The tricky part: what "pluggable transport" actually means

Here's the thing that took some thinking. An MCP implementation really has three layers:

MCP types at the top: CallToolRequest, CallToolResult, and friends Message format in the middle: JSON-RPC by default Transport at the bottom: stdio, streamable HTTP, WebSocket...

When people say "pluggable transports," they usually mean swapping both bottom layers. And that matters, because running gRPC while keeping JSON-RPC as the message format makes no sense. You'd be smuggling JSON-RPC strings through protobuf and throwing away everything protobuf gives you.

The MCP SDK team at Anthropic has been working through exactly this in their path to V2. The answer is the dispatcher pattern. Previously, the SDK's BaseSession tangled MCP semantics (initialize, call_tool, list_tools, progress, cancellation — 19 methods) together with the wire protocol (JSON-RPC wrapping, ID correlation, receive loops, stream management). Want gRPC? Reimplement the whole session.

After the refactor, BaseSession holds MCP semantics only, and a small Dispatcher interface handles the wire: send_request, send_notification, send_response, set_handlers, run. Implement those five methods and all 19 MCP methods work for free. Swap JSONRPCDispatcher for GrpcDispatcher and you've changed both bottom layers cleanly.