简单来说，n8n-mcp是一个专门为AI Agent（比如Claude Code，Trae，，Vecli，codeX等）打造的n8n外挂知识库。

它的核心作用是让AI能够深度理解和使用n8n。

有了它，AI就拥有了一个实时、准确、全面的n8n官方文档和工具信息库。

它可以让AI Agent：

https://zread.ai/czlonkowski/n8n-mcp

macOS/Linux: ~/.codebuddy.json

Windows: %USERPROFILE%.codebuddy.json

CodeX的在：

macOS/Linux: ~/.codex/config.toml

Windows: %USERPROFILE%.codex/config.toml

Vecli的mcp配置文件位置在：

macOS/Linux: ~/.ve/settings.json

Windows: %USERPROFILE%.vesettings.json

{  "mcpServers": {    "n8n-mcp": {      "command": "npx",      "args": ["n8n-mcp"],      "env": {        "MCP_MODE": "stdio",        "LOG_LEVEL": "error",        "DISABLE_CONSOLE_OUTPUT": "true",        "N8N_API_URL": "https://your-n8n-instance.com",        "N8N_API_KEY": "your-api-key"      }    }  }}

macOS/Linux: ~/.codebuddy.json

Windows: %USERPROFILE%.codebuddy.json

第二步：编辑.codebuddy.json，把n8n-mcp的配置加进去

从n8n-mcp的配置示例，可以看到有两个重要的配置：

N8N_API_URL和N8N_API_KEY

在获取这两玩意儿之前，我先把我的n8n升级一下，n8n更新太快了，每次打开github都是几小时前更新，更新频率相当高。

目前最新版是1.111.1，修改一下我的n8n docker-compose.yml文件

然后在该文件的当前目录的终端执行docker-compose up -d 就可以更新了。

更新成功后访问 http://localhost:32905

而N8N_API_URL就是http://localhost:32905

我的端口改成了32905，正常没有改端口的话，默认是5678

n8n的apikey可以在左下角->settings->n8n API这里创建。

这里创建的apikey，作为n8n-mcp配置里面的N8N_API_KEY

最终.codebuddy.json里面的n8n-mcp配置如下图

[mcp_servers.n8n-mcp]command = "npx"args = ["n8n-mcp"]env = { MCP_MODE = "stdio", LOG_LEVEL = "error", DISABLE_CONSOLE_OUTPUT = "true", N8N_API_URL = "https://your-n8n-instance.com", N8N_API_KEY = "your-api-key" }

终端执行codex启动，选择允许Codex在这个文件夹中工作，且不需要每次请求批准

使用OpenAI最近新出的，专门用于Codex的GPT-5-Codex模型

然后，就遇到一个卡点，这个Codex死活都安装不上mcp，用了这么多个AI CLI，头一次遇到这种基础的功能都有bug的情况…

各种查资料，看issues，都没用，每次尝试了一些方案之后，每次都告诉自己，这篇的目的不是解决Codex的bug，而是介绍n8n-mcp

但是作为程序员的那种钻牛角尖的劲上来之后，控制不住自己的想要去解决，不然浑身难受，我知道这样是在浪费时间，但就是忍不住…

最终浪费了我2个多小时，我暂时放弃了

于是我换成codebuddy海外版，以及Vecli我也试了一下，居然都不行。

不知道为啥本地的npm方式就是不行（有清楚的朋友请评论区指点指点，感谢～）。。。

最后我换成了n8n-mcp的docker的方式

先执行：

docker pull ghcr.io/czlonkowski/n8n-mcp:latest

docker方式的mcp配置示例：

{  "mcpServers": {    "n8n-mcp": {      "command": "docker",      "args": [        "run",        "-i",        "–rm",        "–init",        "-e", "MCP_MODE=stdio",        "-e", "LOG_LEVEL=error",        "-e", "DISABLE_CONSOLE_OUTPUT=true",        "-e", "N8N_API_URL=http://host.docker.internal:5678",        "-e", "N8N_API_KEY=your-api-key",        "ghcr.io/czlonkowski/n8n-mcp:latest"      ]    }  }}

codex的配置示例：

[mcp_servers.n8n-mcp]command = "docker"args = [  "run",  "-i",  "–rm",  "–init",  "-e", "MCP_MODE=stdio",  "-e", "LOG_LEVEL=error",  "-e", "DISABLE_CONSOLE_OUTPUT=true",  "-e", "N8N_API_URL=http://host.docker.internal:5678",  "-e", "N8N_API_KEY=n8n的apikey",  "ghcr.io/czlonkowski/n8n-mcp:latest",]

最终vecli和Codex中的配置如下：

左边是json格式，右边是toml格式

接下来就开始测试，还是要先重启这些cli工具。

我发现codex反而有点不稳定，它老是给我生成n8n的json文件。

最后我用codebuddy code，和搭配了kimi-k2的vecli以及搭配glm-4.5的Claude Code跑出了好几个n8n工作流。

从简单到复杂，主要是3个案例

最终生成的工作流如下（完全没有动手，AI直接在n8n里面创建）：

第一个案例，比较简单

帮我创建一个带Agent的n8n工作流,使用OpenAI的大模型,对外提供HTTP调用

它按照要求完成的不错（只不过需要我们配置一下OpenAI的apikey啥的）：

第二个中等难度的案例（提示词由gemini生成）：

生成效果如下：

最后一个案例最难（提示词由gemini生成）

这个效果挺让我惊艳的：

虽然目前使用n8n-mcp还无法一次性生成直接可用的n8n工作流。

但是已经比我几个月前测试的效果好多了

之前是生成n8n的json，中等难度的工作流最多只能完成50%。很多时候线都连不明白…

而现在n8n-mcp不仅给了AI充足的上下文，还结合了n8n的API接口，让AI可以自主操作n8n工作流的搭建。

这种方式一次性生成的简单工作流，大部分时候是可用的。

对于复杂工作流，一次性可以生成75%左右，并且可以边调试，边用AI进一步优化。

如果分模块小步迭代，那么一个复杂工作流，估计可以逐步完成到100%。

而且n8n可以开发子工作流，然后用多个子工作流拼装成整个功能。

这里面有两点原因：

n8n-mcp对于小白来说它能生成一些简单的工作流用于学习，对于有一定编程基础，或者n8n使用经验的人来说，能极大提高效率。

你可能会有疑问，n8n-mcp里面的n8n节点信息从哪里来？

n8n-MCP获取节点信息的方式，既不是实时从n8n官网抓取，也不是通过API从你部署的n8n实例里获取。

它的信息来源是在项目构建时（build-time），通过解析 n8n 的源代码包和官方文档库来生成的，最终打包成一个预构建的数据库（pre-built database）。

这个过程是这样的：

当n8n-MCP的开发者准备一个新版本时，他们会在项目中引入n8n官方的npm开发包（例如 n8n-nodes-base）。这些包里包含了所有节点的最原始、最权威的定义代码。

n8n-MCP的构建脚本会做以下事情：

n8n的各个节点信息，和使用方式：

程序化读取这些源代码文件。

解析出每个节点的详细信息，比如：

节点名称 (name) 和内部类型 (nodeType)。

所有的属性（Properties），包括它们的类型（字符串、数字、选项列表等）、默认值、是否必需。

所有的操作（Operations），比如HTTP Request节点的GET, POST, PUT等。

属性之间的依赖和显示关系（比如，只有当认证方式选为API Key时，才会显示API Key输入框）。

这是最准确的技术性信息来源，因为它直接来自n8n的核心代码。

n8n的官方文档数据：

为了获取更具可读性的描述和用法说明，构建脚本还会拉取 n8n 的官方文档GitHub仓库（n8n-io/n8n-docs）。

然后，脚本会解析这些文档文件（一般是Markdown格式），提取节点描述、参数说明、注意事项等，并将这些信息与第一步从代码中提取出的节点进行关联。

预构建的数据库

脚本将上述两部分信息整合、处理后，会生成一个轻量级的SQLite数据库文件（约15MB）。

这个数据库就相当于一本n8n的离线百科全书，记录了当前版本n8n的绝大部分信息。

当使用npx或docker运行n8n-mcp时，你下载的包里已经包含了这个数据库。

所以它的响应速度非常快（平均12ms），因为它只是在本地查询这个现成的数据库，完全不需要任何网络请求。

那么，既然是离线的，如何获取最新的n8n节点信息？

答案是通过更新n8n-MCP这个工具本身来完成。

更新流程是这样的：

n8n官方发布了一个新版本（比如增加了新的节点或修改了现有节点）。

n8n-MCP的维护者会更新项目中的n8n源代码包依赖到最新版。

维护者重新运行上面提到的构建脚本，生成一个包含n8n最新信息的新版数据库。

维护者发布一个新版本的n8n-MCP（比如从 2.7.0 更新到 2.8.0），这个新版本里就打包了那个全新的数据库。

我们下一次运行 npx n8n-mcp (它会自动拉取最新版) 或者 docker pull ghcr.io/czlonkowski/n8n-mcp:latest，就获取到了包含n8n最新节点信息的n8n-mcp版本。

「总结」

n8n-MCP提供的信息是打包在特定版本里的，是静态的。它反映的是其所基于的那 n8n版本的状态。

配置n8n API的作用是操作：

配置中填写的N8N_API_URL和N8N_API_KEY，是用来让AI管理你的n8n工作流的（例如创建、更新、执行）。

最后，我相信随着上下文工程，和大模型的不断发展进步，n8n工作流将完全能交给AI全自动生成。

只要Agent执行速度没有质的提升，稳定性无法达到99.9%，那么工作流就不会被淘汰。

>/ 作者：袋鼠帝