Something significant happened in the API world last week, and I think it deserves more attention than it’s getting: Google proposed gRPC as a transport layer for Anthropic’s Model Context Protocol (MCP) — the emerging open standard that defines how AI agents communicate with external tools and APIs.
If you’re not tracking MCP, you should be. It’s quickly becoming the de facto standard for AI tool integration. When you ask an AI agent to “check my calendar” or “query the database,” MCP is the protocol that makes that handshake work. And now Google wants gRPC to be the wire protocol underneath it.
Why This Matters
MCP defines the what — the schema for tool discovery, invocation, and response. The transport layer defines the how — how bytes move between client and server. If gRPC becomes the standard MCP transport, every MCP server and client in the ecosystem needs gRPC support. That’s a massive shift from the current REST/JSON-over-HTTP world.
gRPC’s Case for AI Workloads
Honestly, gRPC makes a compelling argument for AI agent communication:
- Bidirectional streaming: AI agents need persistent, real-time communication channels. An agent might send a tool call, receive partial results, send follow-ups, and get streaming responses — all on one connection. gRPC’s bidirectional streaming handles this natively. REST’s request-response model requires workarounds like long-polling or WebSocket upgrades.
- Protocol Buffers for serialization: Protobuf messages are 3-10x smaller than equivalent JSON and parse 20-100x faster. When an AI agent is making hundreds of tool calls per session, that efficiency compounds.
- Built-in service discovery and strong typing: Protobuf contracts define exactly what a tool accepts and returns. No more guessing at JSON shapes or writing validation code. The compiler catches mismatches before runtime.
- HTTP/2 multiplexing: Multiple concurrent tool calls over a single connection, with header compression and flow control built in.
REST’s Limitations (for This Use Case)
I want to be clear: REST is excellent for what it was designed for. But AI agent communication pushes against its boundaries:
- Request-response doesn’t model streaming well. Server-Sent Events help for one direction, but true bidirectional communication requires additional protocols.
- JSON parsing overhead becomes significant at high-volume tool call rates. When an agent executes 50 tool calls in 10 seconds, serialization costs matter.
- No native type safety means integration bugs surface at runtime rather than compile time.
Our Team’s Experience
We migrated internal service-to-service APIs from REST to gRPC about two years ago. The results were meaningful: latency dropped roughly 40%, payload sizes dropped about 60%, and the protobuf contracts eliminated an entire category of integration bugs where services disagreed on field names or types.
But the trade-offs are real. Debugging is significantly harder — HTTP traffic is human-readable, protobuf is binary. We had to build custom tooling for inspecting gRPC traffic. Developer onboarding took longer because protobuf compilation adds a build step that REST doesn’t have.
The Current Landscape
The API world isn’t monolithic:
| Protocol | Dominant Use Case | Market Share (approx) |
|---|---|---|
| REST/JSON | Public APIs, browser-to-server | ~80% of APIs |
| gRPC | Service-to-service, internal | Growing fast, especially at scale |
| GraphQL | Frontend-focused, flexible queries | ~10% of frontend APIs |
My Prediction: Convergence, Not Replacement
I don’t think gRPC replaces REST. I think we’re heading toward a three-layer world:
- External/public APIs stay REST — human developers need readability, curl-ability, and a low barrier to entry
- Internal service-to-service APIs move to gRPC — machines talking to machines benefit from efficiency and type safety
- AI agent APIs adopt gRPC — agents need streaming, type safety, and performance, and they don’t care about human readability
The MCP proposal, if accepted, would accelerate layer three significantly.
The Question
Is your team using gRPC today? And more importantly — does the MCP transport proposal change how you’re thinking about your API strategy? I’m particularly curious if anyone has experience with gRPC in client-facing (not just internal) contexts.