Enterprise AI Agents Just Got a Major Upgrade: MCP with gRPC

Added: 2026-05-05

[00:00:00]Google just announced something that could change how AI agents work in production. They're contributing a gRPC transport layer for MCP, Anthropics protocol for connecting AI agents to tools and data. Now, if you have been following the channel, you know we have covered both MCP and gRPC individually.

[00:00:17]But this announcement brings them together in a way that solves a very real problem enterprise have been dealing with. And to understand why this matters, we need to start from the beginning. Let's get started.

[00:00:33]If you have watched my earlier video on MCP, you already know the core idea.

[00:00:37]Before MCP, every tool your AI agent needed to talk to required a custom integration. Want to connect to Slack?

[00:00:44]Build a Slack integration. GitHub, build a GitHub integration. Your internal database, another custom integration.

[00:00:50]Every single one of these has a different format, different authentication, different way of describing what it can do. It's a mess.

[00:00:57]MCP fixes this by creating one universal standard. Instead of every tool needing its own custom connector, every tool just speaks MCP. One protocol, one format, one way of connecting. If you want the full deep dive on how MCP works, I'll link that video up here. But for today, we care about is something most people skip over, the transport layer. How do the MCP client and MCP server actually talk to each other?

[00:01:23]Because when the MCB client talks to the MCB server, there are two separate things going on. There is the message format, how the actual request is structured. And then there's the transport, the delivery system that carries those messages, the content of the letter, and the postal service that delivers it. For the message format, MCP uses JSON RPC. JSON, the curly brace format you see everywhere on the web.

[00:01:48]Human readable, simple. You look at it and immediately understand what it says.

[00:01:52]Your browser speaks JSON. Your API speaks JSON. It's the English language of the internet. JSON RPC adds a little structure on top. When the MCB client makes a request, it looks something like this. There's a version JSON RPC2.0 and ID. So, we can match this request with its response later. A method, the action we want, such as call this tool, and params, the specifics, get me the weather for San Francisco. The server responds back with the same ID and that's how we know that this is the answer to our question and the result with the actual data. That's the entire message format. Okay. So that's what insides the envelope. Now how does the envelope actually gets delivered? Plain old HTTP. The same protocol your browser uses every time you load a website. When the MCP client wants to call a tool, it sends a regular HTTP post request. The JSON RPC message writes in the body.

[00:02:51]Server processes it, sends back an HTTP response. Nothing fancy, just the web.

[00:02:57]The same plumbing that's been working for decades. And for basic request response, call this tool, give me the result. This works beautifully. But what about when the server needs to push updates to the client? Maybe the agent is monitoring a database for changes or waiting for a longunning task.

[00:03:15]HTTP is you ask, I answer. One request, one response done. So MCP uses SSE, server send events. Instead of hanging up after each answer, the connection stays open. The server keeps pushing updates down the same line. Status changed, new data, task completed, one-way stream, server to client, running over regular HTTP. MCP's protocol logic at the top, such as tools, resources, prompts. JSON RPC structures every message. HTTP plus SSE carries everything back and forth. This is a clean setup. Any developer can read the messages. You can debug with curl.

[00:03:54]You can inspect with browser dev tools.

[00:03:56]It just works. For a standalone system, perfect. But in the real world, MCP doesn't live alone. It has to drop into infrastructure that companies have been building for years. And that infrastructure speaks a very different language. This is what a real enterprise backend looks like. Spotify, Netflix, Google, thousands of companies, hundreds of microservices, all talking to each other over gRPC. Google's higherformance RPC framework. Their service contracts are defined in protocol buffers. Their service mesh routes in gRPC calls. Their monitoring tools understand gRPC metadata. This is their world. This has been their world for years. And now MCV walks in and says, "Talk to me in JSON over HTTP." See the problem? If you want your AI agents to talk to your existing services through MCP, you now need to maintain two protocol stacks for the same backend. Your gRPC interface for all your existing serviceto-ervice communication and a separate JSON RPC interface just for AI agents. Two worlds side by side for the same service.

[00:05:04]JSON is textbased. Every field name, every code, every bracket, it all gets serialized as text, sent across the wire, then passed back. For one tool call, nobody notices. But when you have AI agents making hundreds of tool calls per session, watching resources in real time, streaming data, that text based overhead adds up. Protocol buffers, gRPC's binary format, are dramatically smaller and faster to process. Problem number three, no type safety. JSON RPC is schema loose. You can send whatever you want and nothing validates it until runtime. GRPC with protobuff gives you strict typed contract. You now exactly know what fields exist, what types they are, what's required. In production systems where a malformed payload can cascade into failures, that matters a lot. And then there is a translation tax. your options. Rewrite your gRPC services to also speak JSON RPC. Set up transcoding proxies that convert between the two or just accept the burden of maintaining both forever. None of these are good. Spotify so acutely that they went and build their own experimental gRPC transport for MCP internally.

[00:06:22]So Google stepped in. They are contributing a gRPC transport package for MCP. And the key word here is transport. MCP itself, the protocol logic, the tools, resources, prompts, none of that changes. What changes is the bottom layer of that stack. JSON payloads get replaced by protocol buffers, compact, binary, typed, HTTP gets replaced by gRPC running on HTTP2, which gives you full birectional streaming natively. No more SSC workaround. Both the client and server can push data to each other simultaneously.

[00:06:58]And now look what happens. That MCP server that used to be the odd one out, it speaks gRPC just like everything else. Your existing service mesh can route to it. Your existing monitoring can observe it. Your existing protobuff definitions can describe it. It's just another gRPC service. The MCP SDK is being refactored to support pluggable transports. JSON RPC over HTTP isn't going away. It stays as the default.

[00:07:26]gRPC becomes a first class alternative.

[00:07:29]You pick the transport that matches your infrastructure and Spotify has already validated this. Their senior staff engineer said it directly. GRPC transport gives them developer familiarity, less work building MCP servers and the benefits of statically typed APIs. This isn't theoretical. It's already working. Now, let me be real with you. This isn't a magic bullet.

[00:07:52]First, the performance argument. If your AI agents make five tool calls in a conversation, the difference between JSON and protobuff serialization is negligible. The LLM inference itself dominates. Swapping the transport doesn't make that faster. So where does it matter? Highfrequency agentic workflows. If you have hundreds of agents operating simultaneously, realtime resource watching, large scale deployments where serialization overhead multiplies across thousands of requests per second. And here's the deeper issue.

[00:08:22]gRPC tells you the structure, method names, parameter types, but LLM don't just need structure, they need meaning.

[00:08:30]What does this tool actually do? When should I use it versus the other tool?

[00:08:34]MCP was designed to carry that semantic context. GRRPC wasn't. So, you can't just expose a raw gRPC service and expect an AI agent to figure it out. You still need that MCP description layer on top. The transport changes, but the semantic requirement doesn't go away.

[00:08:51]But regardless, for enterprises, this removes the single biggest barrier to MCP adoption for gRPC heavy organizations. And notice the timing.

[00:08:59]Google launched this alongside managed remote MCP servers on Google Cloud.

[00:09:04]They're building a pipeline. Your existing gRPC infrastructure flows right into Google's AI agent platform. This is competitive move against AWS and Azure.

[00:09:14]Pluggable transports open the door beyond gRPC. quickbased transports, edge computing optimizations, MCP starts building a protocol specification rather than transport prescription. So what's the bigger question? Does every new protocol eventually have to bend to accommodate the infrastructure that already exist? MCP started as an AI native protocol. Now it's adapting to speak gRPC because that's what enterprises already run. Is that pragmatism or compromise? Honestly, it might be both. And if you haven't seen them yet, I have covered both MCP and gRPC in depth on this channel. I'll link those right here. They'll give you a full foundation for everything we have talked about today. Thanks for watching and I'll see you in the next one.