摘要：谷歌云宣布"将为模型上下文协议（Model Context Protocol，MCP）贡献一个gRPC传输包，填补那些在微服务中全面标准化使用gRPC的企业所面临的关键空白。至少从2025年4月起，开发者就开始呼吁，在GitHub的一次讨论（#1144）"中，从业者们主张MCP从一开始就应该围绕gRPC构建，部分开发者在此期间已推出了自己基于gRPC的MCP服务器。MCP维护者此后已经同意在SDK中支持可插拔得传输层，而谷歌计划自行贡献并分发gRPC传输包。
谷歌云宣布"将为模型上下文协议（Model Context Protocol，MCP）贡献一个gRPC传输包，填补那些在微服务中全面标准化使用gRPC的企业所面临的关键空白。MCP是Anthropic推出的协议"，用于实现AI智能体与外部工具和数据的集成，目前在企业环境中获得了广泛关注。
目前，MCP默认使用基于HTTP的JSON-RPC"作为传输层。这在处理自然语言负载时表现良好，但对于已全面采用gRPC的开发者而言，却带来了极大的不便。其他可选方案包括，重写服务以适配MCP的JSON传输、搭建转码代理，或并行维护两套独立实现，但是这些方案均不理想。
Spotify已经亲身体验过这种痛苦。该公司的高级员工工程师兼开发者体验技术负责人Stefan Särne在谷歌的博客文章"中表示：
由于gRPC是我们后端的标准协议，我们已在内部为基于gRPC的MCP提供了实验性支持，并且我们已经看到了其优势：对开发者而言非常易用且熟悉，同时通过利用结构化和静态类型的API，减少了构建MCP服务器所需的工作量。
这一举措也得到了社区的支持。至少从2025年4月起，开发者就开始呼吁，在GitHub的一次讨论（#1144）"中，从业者们主张MCP从一开始就应该围绕gRPC构建，部分开发者在此期间已推出了自己基于gRPC的MCP服务器。2025年7月的一个GitHub 问题（#966）"获得了43个赞，开发者们指出，基于HTTP的JSON传输存在JSON序列化带来的高开销、资源监听时低效的长轮询，以及API契约缺乏类型安全性等问题。MCP维护者此后已经同意在SDK中支持可插拔得传输层，而谷歌计划自行贡献并分发gRPC传输包。
通过在底层使用Protocol Buffers"替换JSON，可以显著降低网络带宽和CPU开销。对于已部署gRPC基础设施的企业而言，这意味着AI智能体可以直接与现有服务通信，无需额外添加转换层。Protocol Buffers的结构化、类型化契约也与大多数后端服务的定义方式更为契合。
但是，该提案并未完全解决一个现实的矛盾。在Medium上"，有一篇对比MCP与gRPC的分析文章指出：“gRPC的服务反射提供了结构信息（方法名、参数），但缺乏LLM所需的语义化、自然语言描述（也就是‘何时’和‘为何’）。”MCP 从设计之初就是为了向AI智能体提供这类上下文，即工具描述、资源说明、提示词指导，而gRPC本身并不具备这一能力。
因此，更大的架构问题依然存在：MCP是应该适配gRPC这类现有的RPC系统，还是这些系统需要学习MCP的语言？从业者们对此意见不一。一些人认为，强制将运行良好的gRPC服务重写为JSON-RPC是完全不必要的麻烦。另一些人则认为，不能简单地将gRPC强加于一个以AI为中心的协议之上，而不添加LLM实际运行所需的语义层。
对于将AI智能体投入生产环境的开发者而言，实际优势显而易见。那些已深度使用gRPC的企业（包括谷歌自身），它们“在全球范围内依赖gRPC来启用服务和提供API”，现在均可以直接采用MCP，而无需破坏现有的服务契约了。谷歌还为其自有服务推出了具有全球一致性端点的全托管远程MCP服务器，结合gRPC支持，使谷歌云能够直接面向那些已投资gRPC、希望添加AI智能体能力的企业。
gRPC传输层仍在开发中。谷歌正通过Python SDK中一个关于可插拔传输接口的活跃pull request"，与MCP社区合作推进。如果开发者关注该领域的话，MCP的GitHub仓库和贡献者频道"是了解最新进展的主要渠道。
原文链接：
Google Pushes for gRPC Support in Model Context Protocol"
谷歌云宣布"将为模型上下文协议（Model Context Protocol，MCP）贡献一个gRPC传输包，填补那些在微服务中全面标准化使用gRPC的企业所面临的关键空白。MCP是Anthropic推出的协议"，用于实现AI智能体与外部工具和数据的集成，目前在企业环境中获得了广泛关注。
目前，MCP默认使用基于HTTP的JSON-RPC"作为传输层。这在处理自然语言负载时表现良好，但对于已全面采用gRPC的开发者而言，却带来了极大的不便。其他可选方案包括，重写服务以适配MCP的JSON传输、搭建转码代理，或并行维护两套独立实现，但是这些方案均不理想。
Spotify已经亲身体验过这种痛苦。该公司的高级员工工程师兼开发者体验技术负责人Stefan Särne在谷歌的博客文章"中表示：
这一举措也得到了社区的支持。至少从2025年4月起，开发者就开始呼吁，在GitHub的一次讨论（#1144）"中，从业者们主张MCP从一开始就应该围绕gRPC构建，部分开发者在此期间已推出了自己基于gRPC的MCP服务器。2025年7月的一个GitHub 问题（#966）"获得了43个赞，开发者们指出，基于HTTP的JSON传输存在JSON序列化带来的高开销、资源监听时低效的长轮询，以及API契约缺乏类型安全性等问题。MCP维护者此后已经同意在SDK中支持可插拔得传输层，而谷歌计划自行贡献并分发gRPC传输包。
通过在底层使用Protocol Buffers"替换JSON，可以显著降低网络带宽和CPU开销。对于已部署gRPC基础设施的企业而言，这意味着AI智能体可以直接与现有服务通信，无需额外添加转换层。Protocol Buffers的结构化、类型化契约也与大多数后端服务的定义方式更为契合。
但是，该提案并未完全解决一个现实的矛盾。在Medium上"，有一篇对比MCP与gRPC的分析文章指出：“gRPC的服务反射提供了结构信息（方法名、参数），但缺乏LLM所需的语义化、自然语言描述（也就是‘何时’和‘为何’）。”MCP 从设计之初就是为了向AI智能体提供这类上下文，即工具描述、资源说明、提示词指导，而gRPC本身并不具备这一能力。
因此，更大的架构问题依然存在：MCP是应该适配gRPC这类现有的RPC系统，还是这些系统需要学习MCP的语言？从业者们对此意见不一。一些人认为，强制将运行良好的gRPC服务重写为JSON-RPC是完全不必要的麻烦。另一些人则认为，不能简单地将gRPC强加于一个以AI为中心的协议之上，而不添加LLM实际运行所需的语义层。
对于将AI智能体投入生产环境的开发者而言，实际优势显而易见。那些已深度使用gRPC的企业（包括谷歌自身），它们“在全球范围内依赖gRPC来启用服务和提供API”，现在均可以直接采用MCP，而无需破坏现有的服务契约了。谷歌还为其自有服务推出了具有全球一致性端点的全托管远程MCP服务器，结合gRPC支持，使谷歌云能够直接面向那些已投资gRPC、希望添加AI智能体能力的企业。
gRPC传输层仍在开发中。谷歌正通过Python SDK中一个关于可插拔传输接口的活跃pull request"，与MCP社区合作推进。如果开发者关注该领域的话，MCP的GitHub仓库和贡献者频道"是了解最新进展的主要渠道。
原文链接：
Google Pushes for gRPC Support in Model Context Protocol"