MCP 代理测试揭示客户端隐性失败：Claude Code 完胜 Gemini CLI

MCP 代理日志揭示了静默的客户端失败。

Claude Code 45/45 成功率 vs Gemini 的 42/45，揭示了可靠性差异。

检查 tool-call 差距和 serverInfo 元数据，避免将失败误判为模型问题。

发生了什么变化 — MCP 代理测试揭露隐藏的失败

一位开发者在 MCP stdio pipe 上运行了 90 次代理测试，用三个服务器（filesystem、playwright、github）和两个客户端（Claude Code 2.1.235 on claude-sonnet-5，Gemini CLI 0.55.1 on gemini-2.5-flash）进行测试。结果：Claude Code 完成了 45/45 次试验，Gemini CLI 完成了 42/45 次。但真正重要的发现不在 token 表格中，而是在测试前的准备工作里。

这对你意味着什么 — 静默失败看起来像是模型无能

关键问题在于：某个客户端（Gemini CLI 0.18.4）在数据到达服务器之前就已经在内部处理失败了。原因是其内置验证器没有注册 JSON Schema draft 2020-12 元 schema。@playwright/mcp@0.0.79 在全部 24 个工具上声明了 2020-12 支持，所以大多数调用因为 schema 中没有 key 或 ref "https://json-schema.org/draft/2020-12/schema" 而失败——根本没有到达网络层。

在网络层面，这看起来就像一个模型尝试很少、回答错误的情况。代理的 tool-call 差距字段捕捉到了这个问题：它从客户端记录的调用中减去实际发送的帧。零是正常的；3-4 的差距意味着调用已形成但从未发送。

立即尝试 — 如何在 Claude Code 中应用

检查你的 Claude Code 版本：确保你使用的是支持 JSON Schema draft 2020-12 的最新构建。该修复已在 Gemini CLI 0.28.0（issue #14970, PR #15060）中上线，但 Claude Code 的验证器也需要验证。

为你的 MCP pipe 添加检测：在 stdio pipe 上运行代理以记录工具/调用请求和响应。将你客户端使用输出中的工具名称（如 mcp_<server>_<tool>）与实际发送的帧进行对比。正的差距意味着存在静默失败。

为你的 MCP pipe 添加检测：在 stdio pipe 上运行代理以记录工具/调用请求和响应。将你客户端使用输出中的工具名称（如 mcp_<server>_<tool>）与实际发送的帧进行对比。正的差距意味着存在静默失败。

注意 _meta 块：Claude Code 会话携带 io.modelcontextprotocol/serverInfo，包含服务器名称、版本和 base64 PNG 图标——在一个 472 字符的回复中占 2,215 字符。如果你控制服务器，这是可以剥离的 token 开销。

注意 _meta 块：Claude Code 会话携带 io.modelcontextprotocol/serverInfo，包含服务器名称、版本和 base64 PNG 图标——在一个 472 字符的回复中占 2,215 字符。如果你控制服务器，这是可以剥离的 token 开销。

当心你自己的 CLAUDE.md：有一次试验失败了，因为 Claude Code 的全局 CLAUDE.md 写着"never send outbound communications"。现在运行者传递 --setting-sources "" 来隔离测试。对于你自己的工作，记住：你的 memory 文件可能以你意想不到的方式改变行为。

当心你自己的 CLAUDE.md：有一次试验失败了，因为 Claude Code 的全局 CLAUDE.md 写着"never send outbound communications"。现在运行者传递 --setting-sources "" 来隔离测试。对于你自己的工作，记住：你的 memory 文件可能以你意想不到的方式改变行为。

计算行尾：有一次 Gemini 失败是因为它为一个有 137 行的文件写了 138 行——服务器用空白行分隔符连接文件，而模型把它也算进去了。如果你在解析 MCP 响应，注意分隔符。

计算行尾：有一次 Gemini 失败是因为它为一个有 137 行的文件写了 138 行——服务器用空白行分隔符连接文件，而模型把它也算进去了。如果你在解析 MCP 响应，注意分隔符。

为什么它有效 — Token 成本因客户端而异

同一个 get_file_contents 调用对 Claude Code 返回 1,561 tokens，对 Gemini CLI 返回 161 tokens。为什么？Claude Code 协商的协议版本是 2026-07-28，而 Gemini 是 2025-06-18，而且每个响应都携带那个 _meta serverInfo 块。每次调用的成本不是服务器的单独属性——它是客户端协议版本的函数。

MCP 失败并不总是表面看到的那样。在责怪模型之前，检查客户端是否实际发送了调用。使用代理、追踪 tool-call 差距、验证你客户端的 schema 支持。你的调试时间会大幅下降。

[Updated 21 Aug via devto_mcp]

另一个项目解决了 MCP 代理的运维层面：Smart MCP Proxy 在运行时热切换服务器，监控 proxy-config.yaml 并 diff 服务器列表来添加或移除池，而无需重启 agent。它在所有连接的客户端之间共享每个服务器的一个子进程池——三个 agent 加七个服务器意味着七个池，而不是二十一个——并在 demand 时 spawn/kill 子进程，带有三次重试的崩溃恢复。可选的"AI concierge"层通过 MCP Sampling 将自然语言请求路由到正确的工具，只返回最终答案以保持上下文干净。MIT 许可的 v1.0.0 作为一个单一 Python 进程运行，无需数据库或 Docker，尽管 auth/HTTPS 尚未包含 [per Smart MCP Proxy]。

[Updated 22 Aug via devto_mcp]

除了调试，MCP 现在是视频剪辑工具的标准，托管端点和 OAuth 替代了本地密钥。OpusClip、Reap、Submagic 和 Whipscribe 都提供了 MCP 服务器；Katto 暴露了 15 个工具覆盖完整管道——剪辑创建、重渲染、八种语言的配音和配额检查 [per dev.to]。认证在 OAuth 托管（OpusClip、Reap、Katto）和 Bearer 密钥（Submagic、Whipscribe）之间分化。定价各异：OpusClip 按渲染分钟数计费，而 Katto 在所有付费计划中包含 MCP 且不额外收费。结论是：MCP 不再是差异化因素——实现质量、auth 和成本结构才是真正重要的。

Originally published on gentic.news

For further actions, you may consider blocking this person and/or reporting abuse