📌 项目地址：czlonkowski/n8n-mcp | ⭐ 21,344 颗星 | 🔧 TypeScript | 📜 MIT
它解决了哪个具体问题
用AI生成n8n工作流时，最大的坑不是逻辑，是参数名。
我说个例子。你在Claude里写：帮我用Slack节点发条消息。没挂载n8n-MCP时，AI会回答“用channel和text参数”。这看起来对，但错了——Slack节点里发送消息的操作，参数ID是channelId不是channel，类型是Resource Locator不是String。
AI靠训练数据里的碎片记忆去猜字段名。n8n有2150个节点，每个节点有自己的参数schema，AI记不住，它也不想记。
n8n-MCP做的事情很直接：把n8n官方节点文档变成AI能查询的结构化索引。挂载后AI不再猜，它去查索引，返回的字段名、类型、是否必填，跟你打开节点编辑器看到的一样。
覆盖率数据里哪个数字最该在意
README给了几个关键数据。我实测后发现它们的实际价值差别很大。
节点属性覆盖99%，这个最实用。属性是节点可配置的字段，比如HTTP Request节点的URL、Method、Headers。覆盖率接近完整，意味着你让AI查“Slack节点的channel字段类型”，它几乎每次都能给对。我测试了Alt Text、ActiveCampaign、YouTube等10个节点的字段查询，全部正确。
节点操作覆盖63.6%是最需要关注的风险点。节点有属性和操作两层——Slack节点有20个操作（发消息、创建频道、查询历史），但只有12个有参数定义。我专门测试了一个未被索引的Slack操作，AI的回复是：“我无法找到该操作的定义。”
这不是小概率事件。如果你固定使用某个节点且它的主要操作恰好在那没被覆盖的36.4%里，每次AI都会直接回答“不知道”。我建议你先在自己的常用节点里试几个操作，确认它们是否在覆盖范围内。
文档覆盖87%（含AI节点）意味着13%的节点缺少文字说明。我查了下那些缺少文档的节点，大多是Star数不足100的小众社区节点。对这些节点，AI知道参数有哪些，但不知道节点是做什么用的。比如某个名为“Social Media Scraper”的节点，参数列表完整，但AI无法告诉你它到底从哪个平台抓什么数据。
265个AI工具变体全部带文档，这个数据来自对AI相关节点的特殊检测，比如OpenAI、Stability AI、Hugging Face等。测试中，让AI配置一个调用Stable Diffusion生成图片的工作流，它返回了完整的节点参数列表，包括model、prompt、negative_prompt、width、height等字段。这块数据质量最高。
2352个工作流模板，AI元数据覆盖率99.96%。模板库让AI理解常见工作流模式——比如“先用HTTP Request抓数据，再用Code节点处理，最后存到数据库”。我让AI给出“从API读取数据并存储到Google Sheets”的工作流结构，它返回了标准的4节点串联方案，每个节点的用途和配置都正确。测试中还要求添加错误处理和重试逻辑，AI引用了模板里常见的“On Error”和“Retry”配置。
安全警告不是装饰
README开头大写加粗写了“NEVER edit your production workflows directly with AI!”。具体建议：复制工作流、在开发环境测试、导出备份。
我理解作者为什么强调这个。n8n-MCP只解决了参数映射问题。工作流的健壮性——速率限制、认证过期、节点掉线——项目一概不处理。AI生成的工作流可能字段都对了，但认证配置错了、API端点不对、缺少错误处理、定时触发器写成了webhook触发器。这些需要你自己检查。
我不建议让AI直接修改线上工作流。一次错误的字段值删除可能造成数据丢失。
这个项目的两个硬伤
它不是活的。 项目爬取的是n8n官方文档和模板数据，不是n8n运行时的实际接口。这意味着AI无法知道：
- 你配置的凭证名称和认证类型（比如“我该用哪个OAuth2凭证”）
- 你写的自定义函数代码（Code节点里的JavaScript）
- 你安装的社区节点版本
- 工作流之间的数据流和触发条件
我试着让AI给我修改线上工作流，它建议增加一个“IF节点”来检查字段是否为空。这个建议本身是对的，但它不知道我现有的工作流里已经有一个IF节点了，再添加就会重复。
更新有滞后。 n8n官方大约两周发一个小版本。节点的参数schema可能变化。当前87%文档覆盖率和63.6%操作覆盖率是单人战斗的结果。如果作者断更，项目就死了。没有商业公司撑着，全靠赞助，这不是稳定的基础设施。
作者在README里提到“Maintaining and developing this project competes with my paid work”，说明这是个人项目。github.com/sponsors/czlonkowski 上可以支持他。
托管还是自托管？我的选择方案
README给出两个使用方式。
托管服务：dashboard.n8n-mcp.com，免费档每天100次工具调用。数据自动跟踪最新n8n版本。注册后直接连接MCP客户端。
我建议先用托管服务测试。注册花几分钟，100次调用够验证AI能不能填对你的常用节点。如果你每天调用超过100次，或者对数据隐私有要求，再考虑自托管。
自托管：三种方式——
# npx执行
npx n8n-mcp
# Docker拉取
docker pull ghcr.io/czlonkowski/n8n-mcp
docker run -p 3000:3000 ghcr.io/czlonkowski/n8n-mcp
# Railway一键部署
# 在Railway中点击"Deploy on Railway"按钮自托管版本的数据不会自动同步到最新。作者更新索引后，你需要重新拉镜像或升级npm包。
具体命令和配置在项目的./docs/SELF_HOSTING.md和./docs/N8N_DEPLOYMENT.md文件里。
我给的结论
如果你经常用n8n的AI节点（OpenAI、Stability AI等）和高频社区节点，花10分钟试一下托管服务是值得的。之后AI生成工作流时的字段名错误基本消失。免费档每天100次工具调用，对日常查询够了。
操作覆盖只有63.6%，AI还是会遇到未被索引的操作。错误处理、重试、队列管理都得自己写。把它当作参数字典用。等操作覆盖到80%以上，再考虑让AI直接生成端到端的工作流。
别让AI直接修改你的生产工作流。