👁 79 次阅读

n8n MCP Client Tool 为何与 Gemini 模型不兼容

来源链接：https://github.com/n8n-io/n8n/issues/15553

现象描述

在 n8n 中使用 MCP Client Tool 搭配任意 Gemini 模型（无论是 palm 还是 vertex 路径），工作流在模型节点处直接报错。把模型换成 GPT-4o 后，同一套工作流连同 MCP 工具可以正常跑通。有用户在原 1.91.3 版本上遇到问题后，将 Docker 实例升级到 1.94.0 复测，现象依旧，未见到修复。 报错内容属于 Gemini API 侧的 payload 校验失败，原文如下：

Invalid JSON payload received. Unknown name "type" at 'tools[0].function_declarations[1].parameters.properties[1].value': Proto field is not repeating, cannot start list.
Invalid JSON payload received. Unknown name "type" at 'tools[0].function_declarations[2].parameters.properties[0].value': Proto field is not repeating, cannot start list.
Invalid JSON payload received. Unknown name "type" at 'tools[0].function_declarations[2].parameters.properties[1].value': Proto field is not repeating, cannot start list.

Vertex 路径下报错结构一致，只是节点名不同：

Error in sub-node 'Google Vertex Chat Model' Invalid JSON payload received. Unknown name "type" at 'tools[0].function_declarations[0].parameters.properties[2].value': Proto field is not repeating, cannot start list.

触发场景与 MCP 服务端实现相关。提出该问题的用户使用的 MCP server 是 google_workspace_mcp，并附上了一个最小复现工作流 Personal_AI_Assistant_Test.json。该工作流在 GPT-4o 与 Claude 3.5 下均正常，仅在 Gemini 模型下报错。

背景原因

从报错文本可以定位到问题的层级：错误来自 Gemini 侧的 Proto 字段校验，发现 tools[0].function_declarations[*].parameters.properties[*].value 这一层出现了名为 type 的字段，而报错原文写的是 Proto field is not repeating, cannot start list——即该位置不是可重复字段，不能接收列表结构。也就是说，工具声明的 JSON Schema 被序列化成了 Gemini 侧无法接受的形式。 issue 讨论中一位参与者给出的判断是： > This issue is reproducible and the root cause is in the current LangChain Gemini integration stack used by n8n (@langchain/google-genai / @langchain/google-vertexai), not in one specific workflow setup. 据 issue 讨论，根因位于 n8n 所使用的 LangChain Gemini 集成栈，即 @langchain/google-genai 与 @langchain/google-vertexai，而非某个特定工作流配置。这一判断把问题从「工作流写错了」修正为「集成层对 MCP 暴露的 JSON Schema 处理方式与 Gemini 的 proto 约束不匹配」。 需要区分的是：MCP 工具本身会向外暴露一份 JSON Schema 用于描述工具入参，不同模型提供商对该 Schema 的容忍度不同。OpenAI 与 Anthropic 路径能够消化这份 Schema，Gemini 路径在遇到嵌套的 type 字段时拒绝请求。有用户在 2026-01-11 的评论中表示，n8n 对 MCP 暴露的 JSON schema 做过改动，这一说法属于社区观察，未在 issue 中获得官方确认。

排查与量化方法

判断是否命中同一问题，可以按以下要点逐项核对：

• 确认报错文本中是否出现 Unknown name "type" 与 Proto field is not repeating, cannot start list 两段关键串同时存在。
• 确认工作流中挂载 MCP Client Tool 的模型节点是否为 Gemini 或 Vertex 路径。
• 将模型节点替换为 GPT-4o 或 Claude 3.5 复测。若替换后正常，则可判定为 Gemini 路径专属问题。
• 记录 MCP server 的具体来源。原 issue 中触发问题的 server 为 google_workspace_mcp，附有最小复现工作流，可作为对照。
• 记录 n8n 版本号。原 issue 中 1.91.3 与 1.94.0 均复现。

社区在后续讨论中给出了两个可对照的观察点。一位用户在 2025-12-29 表示 Gemini 可以配合社区节点 n8n-nodes-mcp 使用，并将其作为绕过官方 MCP Client Tool 的方向。另一位用户在同日追问该社区节点的可用工作流细节。这类信息属于用户侧经验，尚未形成统一的验证结论。

当前处理路径与局限

issue 状态为 closed，关闭时间 2026-09-26，关闭原因 completed。逐条核对讨论记录，维护者在早期创建了内部跟踪工单： > We have created an internal ticket to look into this which we will be tracking as “GHC-2086” 维护者在 2025-05-22 请求复现材料，原提问者随后提供了 MCP server 地址与最小工作流。此后讨论中未出现维护者确认复现并给出修复版本号的回复。末段实质评论仍在追问修复进展，包括 2025-11-01 的「same issue with gemini 2.5 pro, & flash…」、2025-12-23 的「same issue… is this fix WIP??」、2025-12-29 的「This issue is still persistent when MCP tooling at it’s peak usage we are unable to use it with Gemini chat model.」、2026-01-13 的「same issue, any updates?」以及 2026-02-14 的「Same Issue here.」。 按上述记录，issue 已关闭归档，但官方未提交修复，关闭原因与维护者判定无关。关闭状态不构成「已修复」或「已随版本发布」的证据。截至讨论中可见的最后时间点，有用户在 Gemini 2.5 pro 与 flash 上继续复现，涉及版本与上报渠道仅有 issue 评论本身，讨论中未给出进一步的原因推断。 可行的处理路径仅限于讨论中出现过的动作：

• 在需要即时可用 MCP 工具的场景下，将模型节点切换为非 Gemini 的提供商。据 issue 讨论，OpenAI、Anthropic、Bedrock 路径均可作为替代。
• 尝试社区节点 n8n-nodes-mcp。据 issue 讨论，有用户反馈 Gemini 在该节点下可以工作，但同一讨论中也有用户在追问其具体工作流细节，尚未见到完整的、可复用的配置结论。
• 对当前工作流中的 MCP 工具声明保持关注，等待集成栈层面的变化。issue 讨论中提到 n8n 对 MCP 暴露的 JSON schema 做过改动，该改动是否影响此问题，讨论中未给出定论。

官方尚无在本 issue 中公开的针对性修复方案。本节只归纳已有评论中出现的动作与其局限，不补写未在讨论中出现的排查步骤。

参数或对比表格

下表汇总 issue 讨论中出现的模型路径与现象，用于快速对照：

模型 / 节点	现象	来源
GPT-4o	工作流正常，MCP 工具可用	原提问者复测
Claude 3.5	工作流正常	原提问者复测
Gemini（palm / vertex）	报 Unknown name "type"，Proto field is not repeating, cannot start list	原提问者，1.91.3 与 1.94.0
Google Vertex Chat Model 子节点	同类 JSON payload 报错	2025-05-21 评论
Gemini 2.5 pro / flash	2025-11-01 仍复现	后续评论
社区节点 n8n-nodes-mcp + Gemini	有用户反馈可用，细节未公开确认	2025-12-29 评论

常见错误排查

报错里为什么反复出现多条相同结构的消息？ Gemini 侧对 payload 做校验时会逐条列出不合规字段，每条对应 tools[0].function_declarations[n].parameters.properties[m].value 的一个位置。同一份工具集里多个参数声明都会各报一条，因此日志看起来很长。只需确认报错模式是否一致，无需逐条处理。 替换成 GPT-4o 后正常，是否说明工作流本身没问题？ 可以这样判断。同一工作流、同一 MCP server，仅更换模型提供商即恢复正常，说明问题不在工作流编排，而在 Gemini 路径对工具 Schema 的处理。 是某个特定 MCP server 的问题吗？ 原 issue 中触发者为 google_workspace_mcp，但讨论中维护者表示用若干 vertex 与 gemini 模型在一般场景下测试正常，并请求提供 MCP server 与工作流以便复现。这一分歧说明是否复现与具体 server 暴露的 Schema 形态有关，而非单一 server 独有。 升级 n8n 版本能解决吗？ 原 issue 中从 1.91.3 升级到 1.94.0 后问题依旧。讨论后续中 2025-11-01 至 2026-02-14 的评论仍在报告复现，覆盖 Gemini 2.5 pro 与 flash，未见版本升级带来改善的记录。 社区节点能否作为稳定替代？ 据 issue 讨论，有用户反馈 n8n-nodes-mcp 配合 Gemini 可用，但讨论未给出完整配置，且有用户在追问细节。将其作为替代方案前需要自行验证，不能视为已确认的通用解法。

实践建议

涉及 MCP 工具与 Gemini 模型组合的工作流，在当前状态下应预留提供商切换能力。将模型节点抽象为可替换的配置，避免 MCP 工具声明与特定模型路径强绑定，可以在遇到同类 Schema 兼容问题时快速降级到 GPT-4o、Claude 3.5 等已验证路径。 对报错日志的处理建议保留完整原文。Gemini 的报错会逐字段列出不合规位置，这些信息在向 MCP server 作者反馈 Schema 形态时有用，也能帮助判断问题是否属于本文讨论的同一类。 跟踪上游进展时，以 issue 评论中的实际复现报告为准，而非以 issue 关闭状态为准。本 issue 关闭原因为 completed，但依据讨论记录，关闭并未伴随可对应的修复版本，状态字段与实际可用性之间存在差距。

FAQ

Q：这个 issue 现在还是开放状态吗？ A：不是。GitHub 记录显示状态为 closed，关闭时间 2026-09-26，关闭原因 completed。但从讨论记录看，末段实质评论仍在追问修复进展，官方未提交对应修复。 Q：为什么 GPT-4o 能跑通而 Gemini 不行？ A：据 issue 讨论，根因在当前 LangChain Gemini 集成栈，即 @langchain/google-genai 与 @langchain/google-vertexai，对 MCP 暴露的 JSON Schema 的处理方式与 Gemini proto 约束不兼容。不同模型提供商对工具的 Schema 容忍度不同，OpenAI 与 Anthropic 路径可以消化该 Schema。 Q：有没有官方的修复版本号？ A：讨论记录中没有维护者确认复现并给出修复版本号的回复。维护者早期创建了内部跟踪工单 GHC-2086，但未在评论中公布对应修复版本。 Q：当前可以怎么绕过？ A：据 issue 讨论，可将模型节点替换为非 Gemini 提供商，例如 OpenAI、Anthropic、Bedrock 路径。另有用户反馈社区节点 n8n-nodes-mcp 配合 Gemini 可以工作，但该路径在讨论中未获得完整配置确认。 Q：报错中 Proto field is not repeating, cannot start list 是什么意思？ A：这是 Gemini 侧返回的 Proto 字段校验信息，报错原文为 Proto field is not repeating, cannot start list，表示 tools[0].function_declarations[*].parameters.properties[*].value 位置出现了列表结构，而该字段不可重复。它属于请求体校验失败，不是 n8n 内部错误。