MCP插件工具模型调用失败求助

背景

在基于 Model Context Protocol (MCP) 构建的 AI 应用生态中，开发者通常面临复杂的集成挑战。近期，在 LINUX DO 社区的 MCP 板块中，出现了一起关于 NewAPI 平台与 MCP 插件集成失败的技术求助。

用户反馈的核心痛点在于：虽然 MCP 服务器注册成功，但在实际会话过程中，工具（Tools）无法正确注入到 LLM 的上下文中。通过 AI 辅助分析，初步判断上游请求中确实携带了工具定义，但 NewAPI 或其他中间平台未能正确识别这些工具，导致“会话工具注入失败”。这一现象反映了当前 MCP 协议在跨平台代理（Proxy）场景下的兼容性痛点。

核心内容

该讨论聚焦于 MCP 协议在通过 NewAPI 等 API 聚合平台转发时出现的“工具定义丢失”或“识别失败”问题。具体技术细节如下：

1. 现象描述：

   • MCP 客户端与服务端的握手及注册流程正常完成。
   • 在发起具体会话（Session）请求时，LLM 未能接收到 MCP 定义的工具列表，导致无法调用外部能力（如搜索、数据库查询等）。

2. 故障排查线索：

   • 用户借助 AI 工具对网络请求进行了抓包分析。
   • 分析结果显示，底层发送的 HTTP/JSON-RPC 请求中，实际上携带了工具（Tools）的定义信息。
   • 然而，上游服务（此处特指 NewAPI 或类似的 API 网关/代理平台）在解析或转发请求时，未能正确提取或透传这些工具定义。

3. 根本原因推测：

   • 协议解析差异：NewAPI 可能将其视为标准的 OpenAI Chat Completions 接口，而未完全兼容 MCP 特有的 JSON-RPC 结构或特定的字段命名。
   • 字段映射缺失：MCP 协议中的 tools 字段可能在转发过程中被上游平台忽略、过滤或错误映射，导致下游 LLM 接收到的 payload 中 tools 数组为空或格式错误。
   • 中间件干扰：API 聚合平台可能在转发前对请求体进行了预处理，破坏了 MCP 所需的特定上下文结构。

关键要点

• MCP 注册成功 $\neq$ 功能可用：MCP 的初始化握手成功仅表示连接建立，不代表工具定义能成功透传到 LLM 推理层。
• 上游平台兼容性是关键瓶颈：NewAPI 等主流 API 代理平台目前对 MCP 协议的支持可能不完善，存在“识别盲区”。
• 请求载荷确实包含工具信息：故障点不在客户端发送端，而在中间层（NewAPI）的解析或转发逻辑。
• 需要定制化配置或补丁：默认情况下，直接通过 NewAPI 转发 MCP 请求可能无法工作，可能需要修改 NewAPI 的源码逻辑或寻找支持 MCP 透传的特定配置。

意义与影响

此案例揭示了 MCP 协议在商业化落地过程中面临的“最后一公里”问题：

1. 生态碎片化风险：如果主流 API 聚合平台（如 NewAPI、OneAPI 等）不能原生支持 MCP 协议，开发者必须自行搭建复杂的网关或修改源码，增加了使用门槛。
2. 标准化推进的必要性：这促使 MCP 社区和上游平台厂商需要加速对 tools 字段在 JSON-RPC 和 RESTful 映射中的标准化支持，确保工具定义能无损透传。
3. 开发者工作流调整：在 NewAPI 等工具完全适配 MCP 之前，开发者可能需要采用“旁路”方案，即让 MCP 服务器直接对接支持 MCP 的 LLM 提供商，或通过自定义中间件处理工具定义的转换，而非直接依赖通用 API 代理。