主流AI工具集成MCP Server演示（含：Cline、LiteLLM、Cherry Studio、n8n）

你好，我是 Dr.N8N。在自动化与 AI 落地的一线战场摸爬滚打多年，我见过无数个被“硬编码”毁掉的 Agent 项目。过去，为了让 AI 读取数据库或操作 CRM，我们需要编写繁琐的 HTTP 请求节点，维护复杂的 API 鉴权，一旦 API 变动，整个工作流（Workflow）就会瘫痪。

但 Model Context Protocol (MCP) 的出现，彻底改变了这一局面。它就像是 AI 时代的 USB-C 接口，让 n8n 不再仅仅是一个自动化工具，而是升级为 AI Agent 的“工具挂载中心”与“大脑皮层”。今天，我将避开枯燥的理论，直接带你深入 n8n 与 MCP 集成的实战深水区，解决那些官方文档没告诉你的“坑”。

为什么 MCP 是 n8n 玩家的必修课？

在传统的 n8n AI Agent 构建中，我们面临着“工具匮乏”与“维护地狱”的双重挑战。MCP 协议将这个问题从 (M \times N)（M 个模型适配 N 个工具）降低到了 (M + N) 的线性复杂度。

对 n8n 而言，MCP 带来了两种全新的范式转换：

• n8n as Client（作为消费者）： AI Agent 节点可以直接“挂载”本地文件系统、Git 仓库或私有数据库，而无需编写任何 API 连接器。
• n8n as Server（作为提供者）： 将复杂的 n8n 工作流封装成一个标准的 MCP Tool，供桌面端的 Claude (Cline) 或 Cherry Studio 调用。

实战场景一：赋予 n8n“本地手脚” (Consuming Tools)

很多自动化场景的痛点在于：n8n 运行在云端或 Docker 容器中，无法直接操作你本地开发机的文件或执行 CLI 命令。虽然 n8n 官方推出了 MCP Client 节点，但它优先支持 SSE (Server-Sent Events) 协议，而大多数本地工具（如 mcp-server-filesystem）是基于 Stdio（标准输入输出）运行的。

Dr.N8N 的解决方案：协议桥接 (Bridging)

我们需要一个中间件将 Stdio 转换为 SSE。我推荐使用 supergateway。这是打通 n8n 与本地资源的关键一步。

# 在你的本地机器上运行（需安装 Node.js）

这条命令将本地的 Git MCP Server 转换为 n8n 可访问的 SSE 服务
npx -y supergateway --stdio "uvx mcp-server-git" --port 8000

配置步骤：

1. 在 n8n 中拖入 AI Agent 节点。
2. 连接 MCP Client Tool 节点。
3. 在配置中，SSE Endpoint 填入 http://host.docker.internal:8000/sse（如果你在 Docker 中运行 n8n）。

⚠️ 安全警告： 这种方式会暴露本地环境给 n8n。在生产环境中，务必使用 --apikey 参数为 supergateway 设置访问令牌，并在 n8n 的 MCP Client 节点中配置对应的 Header 认证。

实战场景二：让 n8n 成为 Claude 的“外挂” (Providing Tools)

这是更有趣的反向操作。想象一下，你有一个复杂的 n8n 工作流，负责“查询库存 -> 计算折扣 -> 生成报价单”。过去，你必须在 Claude Desktop 中手动描述这些步骤。现在，你可以将这个工作流变成一个 MCP Tool。

操作清单：

配置完成后，你可以在 Cherry Studio 或 Cline 的配置文件中添加这个 n8n 端点。你的桌面 AI 助手瞬间就拥有了执行复杂业务逻辑的能力。

进阶架构：LiteLLM 网关与治理

当你的团队中有几十个 Agent 和上百个 MCP 工具时，直接点对点连接就是一场噩梦。这时，引入 LiteLLM 作为流量网关至关重要。

LiteLLM 不仅可以聚合多个 LLM 模型，还可以充当 MCP 的注册中心。你可以将 n8n 暴露的工具注册在 LiteLLM 的 config.yaml 中，并利用其 Access Groups 功能进行权限控制。例如，限制“财务 Agent”只能调用“薪资查询”的 MCP 工具。

# LiteLLM config.yaml 示例 mcp_servers: n8n-workflows: url: "https://n8n.your-company.com/webhook/mcp/sse" auth_type: "bearer_token" auth_value: "sk-your-secure-token" access_groups: ["finance-team"]

☠️ 避坑指南：SSE 与 Gzip 的“死锁”

这是我作为 Dr.N8N 必须要强调的技术细节。我在帮助企业落地时，90% 的连接失败都源于此。

MCP 依赖 SSE (Server-Sent Events) 进行流式传输。如果你使用 Nginx、Traefik 或 Coolify 作为反向代理，它们通常默认开启 Gzip 压缩 和 Response Buffering。这会导致 SSE 数据流被“卡”在缓冲区，直到积攒足够的大小才发送，表现为连接超时或 AI 一直“正在思考”。

解决方法： 针对 /sse 或 MCP 相关的路径，必须显式关闭缓冲。

# Nginx 配置片段 location /webhook/mcp { proxy_buffering off; chunked_transfer_encoding on; gzip off; }

结论与交付清单

MCP 不仅仅是一个协议，它是 n8n 下一代自动化的入场券。通过它，我们不再是编写僵化的流程，而是在构建具有感知和执行能力的智能体。

Dr.N8N 的最终交付清单：

• [ ] 环境准备： 部署 supergateway 以桥接本地 CLI 工具。
• [ ] 网络配置： 检查反向代理，确保 SSE 路径禁用了 Gzip 和 Buffering。
• [ ] 安全加固： 所有 MCP 端点必须强制开启 Bearer Auth 或 OAuth2。
• [ ] 成本监控： Agent 自主调用工具会消耗大量 Token，建议配合 LiteLLM 设置预算上限。

开放讨论： 你目前的 n8n 工作流中，最想通过 MCP 接入的一个外部工具是什么？是本地数据库，还是某个特定的浏览器自动化脚本？欢迎在评论区告诉我，我可能会在下一期专门针对它写一个配置教程。

参考资料

• Hostinger: How to use n8n with MCP (Concepts)
• GitHub: Supergateway Usage Arguments
• n8n Community: Fixing SSE Gzip Compression Issues
• Leanware: n8n MCP Integration Insights