← Articles
> Architecture

gRPC in MCP, explained from the transport up

Enterprises want MCP to speak gRPC without a translation layer.

Vivek Raj

Vivek Raj

AI Engineer @ WaveMaker

9 min read · Jul 4, 2026
gRPC in MCP, explained from the transport up

I first ran into this at KubeCon India 2026 in Mumbai, in a talk by a Google engineer. The pitch fit in one sentence: MCP should be able to speak gRPC natively, not through a translation layer. I posted a short take on it afterwards, and then went digging through the repos, the spec proposal, and the SDK discussions to see how real it is. This article is what I found. The short version: the code is further along than I expected, the politics are messier than the talk let on, and the mechanism that will actually ship it is not the one anyone was arguing about.

A transport history in four steps

MCP’s transport layer has been rewritten more times than any other part of the protocol, and each rewrite tracks who was trying to adopt it.

It started with stdio. Your MCP server was a local process, the client wrote JSON-RPC to stdin and read from stdout. Perfect for a desktop app talking to a tool on the same machine, useless for anything remote.

Then came HTTP with server-sent events, which made remote servers possible. Then streamable HTTP, which cleaned up the awkward two-endpoint dance of the SSE design. Then stateless streamable HTTP, which let servers run behind ordinary load balancers without session pinning.

Notice the direction. Every step made MCP servers look more like normal backend services. And the moment they looked like normal backend services, the companies that run thousands of normal backend services showed up with a reasonable question: our services already speak gRPC, why are we translating?

Four transports: stdio, HTTP plus SSE, streamable HTTP, stateless streamable HTTP. Each rewrite widened who could adopt. The fleets arrived at step four, and brought gRPC with them.

The mismatch

MCP speaks JSON-RPC on the wire. That was the right call for a protocol that needed to be debuggable with curl and adoptable in a weekend. But the enterprise backends that are now wiring themselves up as agent tools mostly standardized on gRPC years ago. It is a CNCF project, their service meshes already understand it, and their auth and observability tooling grew up around it.

Connecting the two today means a transcoding gateway: a proxy that translates protobuf to JSON and back on every call. It works, and in a demo you never notice it. At thousands of calls a second you notice it in three places at once: latency, cost, and one more piece of infrastructure that can fail or drift out of sync with the schema on either side.

Today a transcoding gateway translates every call between JSON-RPC and protobuf. The proposed native transport is one gRPC hop. The same tool call, routed two ways.

This is not a hypothetical enterprise. Stefan Särne at Spotify described exactly this in Google’s announcement post: gRPC is their backend standard, so they built experimental MCP-over-gRPC support internally rather than gateway everything, citing developer familiarity and the statically typed APIs. When a company builds a nonstandard transport in-house rather than use the standard one, that is the protocol equivalent of a desire path. The proposal is essentially an offer to pave it.

What gRPC actually brings

Google’s argument, laid out in a blog post by Victor Moreno and Mark D. Roth, comes down to four properties.

Size and connection efficiency. Protobuf’s binary encoding runs roughly 10x smaller than the equivalent JSON, over persistent HTTP/2 connections. That is Google’s number, and worth flagging: the post offers no published benchmarks, latency figures, or throughput comparisons. The claim is plausible, protobuf-vs-JSON size ratios in that range are well documented elsewhere, but nobody has yet shown MCP-specific measurements.

Real streaming with backpressure. HTTP/2 gives full-duplex bidirectional streams, and gRPC layers flow control on top, so a fast tool cannot flood a slow agent. MCP’s current transports simulate bidirectionality; gRPC has it natively.

Security that is already deployed. Mutual TLS for zero-trust authentication, JWT and OAuth hooks, and authorization enforceable per method, so an agent can be allowed to call ReadFile but not DeleteFile at the transport layer rather than in application code. The KubeCon talk also covered SPIFFE-based workload identity, which is how most service meshes issue those mTLS identities in practice. Protobuf’s strict typing adds schema-level input validation for free.

Operational maturity. Native OpenTelemetry integration, standardized error codes like UNAVAILABLE and PERMISSION_DENIED, deadlines and timeouts as first-class concepts, and code generation for eleven-plus languages. None of this needs to be built for MCP. It exists, hardened by a decade of production use.

The one-line summary of all four: a service already on gRPC could expose itself as an agent tool using infrastructure its team already trusts, with no gateway in the path.

The code is real

This is not a slideware proposal. Two repos exist.

The proto definitions live at GoogleCloudPlatform/mcp-grpc-transport-proto: an Mcp gRPC service in mcp.proto and the message payloads in mcp_messages.proto, kept in sync with MCP schema version 2025-11-25, with a v0.1.0 release from April 2026. One design detail in there says a lot about the mindset. The protos deliberately avoid oneof fields, because oneof breaks forward compatibility when new message types land, and MCP is a protocol that adds message types constantly. The maintainers committed to non-breaking changes only. Whoever wrote these protos has been burned by schema evolution before, which is exactly who you want writing them.

The Python transport at GoogleCloudPlatform/mcp-grpc-transport-py is younger: a handful of commits, no release yet, explicitly work in progress. The scaffolding is there, the implementation is arriving.

And because protobuf is the source of truth, stubs for Go, Java, Rust, C++, or Node are one protoc invocation away. That is the quiet advantage of proto-first design: the Python transport is the first implementation, not the only possible one.

The hard part was never the code

Here is where the story gets more interesting than the talk suggested. The MCP maintainers have pushed back twice, both times for defensible reasons.

Timeline: maintainers agree in principle in December 2025, the SDK PR closes in January, protos and the V2 dispatcher land in April, SEP-2598 is deferred in May, V2 stable is targeted for July 2026. Two rejections on paper. Read on for why the door is still open.

The first attempt was a Python SDK pull request adding the minimal interfaces a custom transport would implement. The maintainers closed it in January 2026, arguing the existing interface already supported multiple transports. Underneath that sat the deeper blocker: the MCP spec itself is coupled to JSON-RPC framing, and no SDK abstraction can paper over that.

The second attempt went through the front door: a SEP, or Specification Enhancement Proposal, the numbered design documents MCP borrowed from Python’s PEP process for proposing changes to the protocol itself. SEP-2598, titled Pluggable Transports, draws the line like this: stdio and streamable HTTP stay as the only standard transports, and everything else, gRPC included, ships as independent packages that may even use non-JSON encodings as long as they faithfully round-trip MCP semantics. Its design principle is stated outright: a small standard set is load-bearing, because every transport added to the core is complexity every implementer carries forever. The review pulled in both directions, some arguing the requirements were too strict, others that they asked too much of SDK maintainers. Along the way one reviewer mentioned he already runs a production gRPC transport aligned with the proposal’s spirit. The desire path keeps getting walked.

In May 2026, the core maintainers voted to defer the SEP. Not rejected, deferred, but the message was clear: not like this, not yet.

The dispatcher is the actual answer

So the spec proposal is parked and the SDK PR is closed. Why do I still think this ships?

Because of a talk at the MCP Dev Summit in New York this April: Max Isbey’s “Path to V2 for MCP SDKs.” The V2 rework’s architectural headline is a dispatcher pattern that separates MCP semantics from wire format and transport.

The V2 dispatcher sits between MCP semantics and the transports. stdio and streamable HTTP stay in the core spec; gRPC, WebSocket, and SSH plug in as independent packages. SEP-2598’s shape, delivered through SDK architecture instead of the spec. That separation is precisely the thing whose absence killed the January PR. Once the SDK core no longer assumes JSON-RPC framing, a gRPC transport stops being a spec question and becomes a packaging question: an independent module that slots into the dispatcher, exactly the shape SEP-2598 sketched for it.

The timeline makes this concrete rather than aspirational. TypeScript V2 is in alpha, Python V2 entered beta in Q2, and both stable releases are targeted for July 27, 2026, alongside the new spec revision. The pieces are converging from both ends: Google maintains the protos and the transport, the SDK team ships the seam it plugs into, and the spec never has to bless gRPC at all. Deferring the SEP looks less like a rejection and more like the maintainers refusing to standardize a plug before the socket existed.

What I would push back on

A fair article needs the other side, and there is one.

JSON-RPC is debuggable with your eyes. Every MCP developer has read raw tool-call traffic to figure out what went wrong; protobuf turns that into a tooling problem. That cost lands on everyone, not just enterprises.

There is also a genuine impedance mismatch between protobuf’s compile-time schemas and MCP’s runtime dynamism. Tools appear and disappear mid-session, their JSON Schemas are arbitrary and server-defined. The proto repo’s no-oneof rule is a clever workaround for protocol evolution, but it is a workaround, and it trades away some of the type safety that is supposedly the point.

And the performance case remains unquantified for MCP specifically. Tool-call payloads are often small and infrequent; the 10x wire savings matters enormously for high-frequency service-to-service traffic and much less for an agent making a dozen calls a minute. The companies that need this, need it badly. Most MCP servers will never notice.

That is probably the right way to hold the whole proposal. It is less a fight over the default and more a protocol growing the ability to meet deployments where they already are. JSON-RPC for reach and readability, gRPC for fleets that outgrew both concerns years ago.

Where this leaves us

As agents move out of demos and into production, the unglamorous layers start deciding the economics. Nobody writes keynotes about transports, but the transport is where cost, latency, and reliability actually live once call volume gets serious. MCP’s history of rewriting its transport every time a new class of adopter arrived suggests the maintainers understand this, and the V2 dispatcher suggests they have chosen extensibility over an ever-growing blessed list.

Watch three things: the stable V2 SDK releases targeted for late July, the Python transport repo filling in against them, and whether SEP-2598 comes back refined once the dispatcher is real. If all three land, MCP-over-gRPC goes from conference talk to pip install sometime this year, and the interpreter finally leaves the room.

Sources

Share

Get the drops in your inbox

One email when something new ships, and nothing else.