截止25年11月，MCP协议在实践中的问题与社区讨论收录

27天前发布

040

参考
https://www.anthropic.com/engineering/code-execution-with-mcp
MCP社区issue #1306

模型上下文协议（Model Context Protocol, MCP）是一个将 AI 智能体连接到外部系统的开放标准。将智能体连接到工具和数据传统上需要为每个配对进行定制集成，这造成了碎片化和重复工作，使得难以扩展真正互联的系统。MCP 提供了一个通用协议——开发者只需在其智能体中实现一次 MCP，即可解锁整个集成生态系统。

自 2024 年 11 月发布 MCP 以来，其采用速度迅猛：社区已经构建了数千个 MCP 服务器，所有主流编程语言都提供了 SDK，并且该行业已将 MCP 视为连接智能体与工具和数据的事实标准。

如今，开发者们通常构建的智能体能够访问跨越数十个 MCP 服务器的数百甚至数千个工具。然而，随着连接工具数量的增长，预先加载所有工具定义并通过上下文窗口传递中间结果会降低智能体速度并增加成本。

Token效率问题

工具定义挤占上下文窗口

大多数 MCP 客户端会预先将所有工具定义直接加载到上下文中，使用直接工具调用语法将其暴露给模型。工具描述会占用更多上下文窗口空间，从而增加响应时间和成本。在智能体连接到数千个工具的情况下，它们在读取请求之前需要处理数十万个令牌。

中间工具结果消耗额外令牌

大多数 MCP 客户端允许模型直接调用 MCP 工具。每个中间结果都必须经过模型处理。在此示例中，完整的通话记录会流经两次。更大的文档甚至可能超出上下文窗口限制，导致工作流中断。
对于大型文档或复杂的数据结构，模型在工具调用之间复制数据时更有可能出错。

数据格式问题

许多实际应用场景需要服务器在MCP工作流中直接处理二进制文件：

图像分析：计算机视觉服务器需要分析用户上传的图片文档处理：PDF分析器、OCR服务和文档解析器需要访问二进制文档代码分析：静态分析工具可能需要处理已编译的二进制文件或归档文件数据导入：服务器可能需要处理CSV、Excel或其他二进制数据格式模型训练：机器学习服务器可能需要各种二进制格式的训练数据
目前这些场景需要采用变通方案：在文本字段中使用复杂的base64编码（效率低下，存在大小限制）通过外部文件托管和URL共享（存在安全隐患，增加复杂性）预上传文件到共享位置（用户体验较差）