思考与探索：借由gRPC重塑MCP：探索强类型协议下的工具调用新范式

原创

于 2025-09-26 08:15:00 发布 · 1.4k 阅读

36 ·

CC 4.0 BY-SA版权

文章标签：

#mcp #GRPC

几周前，我读过一篇关于MCP（模型调用协议）的博客，当时还为MCP在特定场景下的合理性进行过辩护。但我从未接触过gRPC，此后每次遇到MCP相关的新问题或新库，都会重新翻阅那篇博客，探寻是否有相关洞见可供借鉴。于是，我花了几天时间深入学习gRPC，尝试勾勒出基于gRPC的工具调用协议雏形——为了简化表述，我将其命名为gMCP。

需要说明的是，以下内容仅代表一位“gRPC门外汉+MCP初学者”的主观思考，核心是探索MCP在gRPC生态中可能呈现的形态，并非严谨的技术方案。

一、回顾：MCP被诟病的核心问题

工程师Julien Simon在其博客《Why MCP’s Disregard for 40 Years of RPC Best Practices Will Burn Enterprises》中指出，MCP本应基于gRPC构建，而当前设计存在七大“隐患”，这些问题也成为我探索gMCP的核心出发点：

采用无 schema 的 JSON
：缺乏结构化约束，易导致数据格式混乱；
缺少跨客户端与服务器的生成绑定
：多语言场景下需重复处理数据适配，效率低；
混合有状态与无状态操作
：逻辑边界模糊，增加维护与调试难度；
将可观测性视为可选
：难以追踪请求链路、定位问题，不利于大规模运维；
依赖大量第三方库
：增加系统复杂度与潜在兼容性风险；
采用“拼凑式”系统设计
：各模块衔接松散，扩展性与一致性差；
服务器缺少 schema 版本控制
：工具更新可能直接导致客户端崩溃。

二、gMCP的设计思路：聚焦核心，借力gRPC优势

我的目标并非完全重写MCP，而是针对上述问题，依托gRPC的特性验证解决方案的可行性。因此，设计聚焦MCP的核心功能——工具调用，暂时忽略了提示词、资源管理、采样等次要模块，同时移除了会话机制与初始化流程，让方案更轻量化。

gMCP的核心思路是“最大化利用gRPC能力”：一方面借助gRPC的强类型、多语言绑定特性解决MCP的结构化与跨语言问题；另一方面，针对工具需动态定义schema的需求，通过gRPC原生能力填补缺口。其中关键的技术支撑是gRPC服务反射（Server Reflection）——它能让服务器对外暴露可访问的gRPC服务信息，客户端无需预编译服务定义，即可在运行时动态构建请求与解析响应。

此外，考虑到AI对JSON/text格式的兼容性更好，gMCP在客户端增加了“Protocol Buffers（PB）转JSON”的适配层，实现“传输层强类型、应用层易读”的平衡。

三、gMCP核心协议定义：两份Proto文件的关键作用

gMCP的核心协议通过两份Proto文件定义，分别对应MCP服务接口与服务器元数据，以此解决“结构化约束”与“版本控制”问题。

1. mcp.proto：定义MCP核心服务接口

该文件明确了工具查询（ListTools）与工具调用（CallTool）两大核心接口，同时约束了请求/响应的数据结构，实现强类型校验。

syntax = "proto3";
package mcp.v0;

import "google/protobuf/any.proto";  // 用于包装任意类型的消息

option go_package = "./proto/mcp/v0";  // Go语言包路径

// MCP核心服务
service McpService {
  // 查询服务器支持的工具列表（支持分页）
  r