当前位置：首页 > news >正文

基于MCP协议实现AI助手与n8n自动化平台的深度集成

news 2026/5/14 8:08:29

1. 项目概述：当AI助手遇上n8n自动化

如果你和我一样，是个重度依赖n8n来串联各种SaaS服务、处理数据、触发通知的自动化爱好者，那你肯定也经历过这样的场景：脑子里蹦出一个绝妙的自动化点子，比如“每天下午5点，自动把Trello里标记为‘完成’的任务同步到Notion，并给我发个Slack消息”，然后你就得打开n8n的Web界面，开始拖拽节点、配置参数、测试运行……一套流程下来，少说也得十几二十分钟。更别提有时候想批量修改一批工作流的某个参数，或者快速查看某个工作流最近的执行状态，都得在界面里点点点，效率实在谈不上高。

最近，我发现了makafeli/n8n-workflow-builder这个项目，它就像是为n8n和AI助手之间架起了一座桥。简单来说，它是一个基于模型上下文协议（Model Context Protocol， MCP）的服务器。MCP你可以理解为一个标准化的“插座”，让像Claude Desktop、Cline这类AI助手能够安全、规范地“插上”并使用外部工具。而这个MCP服务器，就是专门为n8n设计的那个“插头”。装上它之后，你的AI助手就能直接和你的n8n实例对话了。

这意味着什么？意味着你可以直接对你的AI助手说：“嘿，帮我列出所有的工作流”、“把那个‘数据备份’工作流激活一下”、“创建一个新的工作流，每天从Google Sheets读取数据，处理完后发到Discord”。AI助手会理解你的意图，并通过这个MCP服务器调用n8n的API，帮你完成这些操作。这不仅仅是省去了点击界面的步骤，更是将工作流的管理和创建提升到了一个“对话式”、“智能化”的层面。对于开发者、运维人员、自动化工程师，或者任何希望提升n8n操作效率的团队来说，这无疑打开了一扇新的大门。

2. 核心原理与架构拆解：MCP如何赋能n8n

要理解这个项目为什么有用，我们得先拆解一下它的核心——MCP，以及它是如何与n8n协同工作的。

2.1 模型上下文协议（MCP）是什么？

你可以把MCP想象成AI世界的“USB协议”。在硬件领域，USB协议定义了设备（如U盘、键盘）如何与主机（电脑）通信，使得任何符合USB标准的设备都能即插即用。MCP在AI领域扮演着类似的角色。它是由Anthropic（Claude的创造者）牵头提出的一套开放协议，旨在标准化AI模型（或AI助手）与外部工具、数据源之间的交互方式。

在没有MCP之前，每个AI助手想要连接一个新工具（比如n8n、数据库、日历），都需要开发者为其编写特定的、非标准的集成代码，这就像每个外设都需要自己的专用接口一样，繁琐且难以维护。MCP的出现，定义了一套通用的“语言”（包括工具发现、调用、返回结果等规范），使得任何符合MCP标准的工具（即MCP服务器）都能被任何支持MCP的AI客户端（如Claude Desktop）识别和使用。

n8n-workflow-builder就是一个严格遵循MCP标准实现的“工具服务器”。它对外暴露了一系列定义好的“工具”（Tools），比如list_workflows、create_workflow。当AI助手需要操作n8n时，它不再需要知道n8n API的具体细节，只需要按照MCP的格式调用这些工具名即可。

2.2 项目架构：三层桥接模型

这个项目的架构非常清晰，可以理解为三层桥接：

AI客户端层：这是用户直接交互的界面，比如Claude Desktop的聊天窗口。用户在这里用自然语言提出需求。
MCP服务器层（本项目）：这是核心的翻译与执行层。它接收来自AI客户端的、符合MCP协议的标准化请求，然后将这些请求“翻译”成n8n官方REST API能理解的HTTP调用。
n8n服务层：这是最终的执行层。它接收来自MCP服务器的API请求，执行实际的工作流操作（如创建、执行、查询），并将结果原路返回。

这个设计的精妙之处在于解耦。n8n-workflow-builder MCP服务器对AI客户端隐藏了n8n API的所有复杂性（如认证方式、端点URL、请求体格式）。AI客户端开发者只需要关心MCP协议本身，而n8n管理员也无需为每个AI助手单独配置n8n连接。所有安全控制和权限管理，仍然通过n8n的API密钥机制来完成，数据流不经过任何第三方，直接在你的AI客户端和你的n8n实例之间传输。

2.3 安全性考量：为什么可以放心用？

很多朋友第一反应可能是：“让AI直接操作我的自动化核心，安全吗？” 这是一个非常好的问题。这个项目的安全模型设计得很扎实：

权限继承自n8n：它不创建任何新的权限体系。你赋予这个MCP服务器的能力，完全取决于你在n8n中生成的那个API密钥。如果你只给这个密钥“只读”权限，那么AI助手也只能查看工作流，无法创建或修改。密钥的权限管理完全在n8n内部进行。
无数据中转：MCP服务器运行在你指定的环境（你的电脑或你信任的服务器上）。它只是一个“翻译官”，所有对n8n的请求都是直接从你的环境发往你的n8n实例，敏感数据（如API密钥、工作流配置）不会上传到任何第三方服务器。
操作可审计：所有通过AI助手发起的操作，最终都会体现在n8n的“执行历史”和日志中。如果某个工作流被意外修改或删除，你可以在n8n的日志里追溯到是哪个API密钥（对应这个MCP连接）在什么时间执行了该操作。
网络隔离可控：你可以将MCP服务器和n8n实例部署在同一个安全的内部网络中，进一步减少暴露面。

实操心得：在正式使用前，我强烈建议先在n8n中创建一个权限范围明确的API密钥进行测试。例如，可以先创建一个只有workflow:read权限的密钥，让AI助手只能“看”，不能“动”。等熟悉了整个流程后，再根据需要逐步增加workflow:write、execution:manage等权限。这是将“最小权限原则”应用于AI集成的最佳实践。

3. 环境准备与快速上手

理论讲完了，我们来点实际的。最快的方式，是用npx直接运行，几乎零配置。

3.1 基础环境要求

在开始之前，请确保你的环境满足以下条件：

Node.js环境：版本需要在v18.0.0或以上。你可以在终端输入node --version来检查。如果版本过低，建议使用nvm（Node Version Manager）来安装和管理多版本Node.js。
可访问的n8n实例：无论是你本地Docker运行的http://localhost:5678，还是公司内网的http://n8n.internal.company.com，或者是n8n.cloud上的云实例https://your-app.n8n.cloud，只要你能在浏览器里访问它的Web界面，并且能获取到API密钥就行。
有效的n8n API密钥：这是连接的关键。登录你的n8n实例，进入Settings（设置） -> API Keys（API密钥），点击“Create API Key（创建API密钥）”。在创建时，请仔细勾选这个密钥需要的权限。为了安全起见，我建议先创建一个只有workflow:read和execution:read权限的密钥用于测试。

3.2 两种部署方式详解

项目提供了两种主要的使用方式，适合不同场景。

方式一：NPX直接运行（推荐给大多数个人用户和快速体验者）

这是最简单粗暴的方式，npx会帮你自动下载并运行最新的包，无需克隆代码或安装依赖。

# 在终端中直接运行，并通过环境变量传递配置 N8N_HOST=http://localhost:5678 N8N_API_KEY=your_n8n_api_key_here npx @makafeli/n8n-workflow-builder

运行后，你会看到类似[n8n-workflow-builder] Server running on stdio的输出，表示MCP服务器已经在标准输入输出上启动，等待MCP客户端（如Claude Desktop）来连接。

方式二：从源码构建与运行（推荐给开发者或需要定制化修改的用户）

如果你需要研究代码、添加自定义工具，或者希望将其集成到自己的系统中，可以从GitHub克隆源码。

# 1. 克隆仓库 git clone https://github.com/makafeli/n8n-workflow-builder.git cd n8n-workflow-builder # 2. 安装项目依赖 npm install # 3. 构建TypeScript代码（编译为JavaScript） npm run build # 构建成功后，会在项目根目录生成一个 `dist` 文件夹 # 4. 运行服务器 # 同样需要设置环境变量 export N8N_HOST=http://localhost:5678 export N8N_API_KEY=your_n8n_api_key_here npm start # 或者直接运行构建后的文件 node dist/index.js

注意事项：如果你在Windows系统上使用命令行，设置环境变量的语法略有不同。对于cmd，使用set N8N_HOST=http://localhost:5678；对于PowerShell，使用$env:N8N_HOST="http://localhost:5678"。我个人更推荐在Windows上使用Git Bash或WSL2来获得与Linux/macOS一致的体验。

3.3 配置AI客户端（以Claude Desktop为例）

服务器跑起来了，接下来就是告诉你的AI助手去哪里找这个“新工具”。这里以目前对MCP支持最完善的Claude Desktop为例。

找到Claude Desktop的配置文件。它的位置通常如下：
- macOS:~/Library/Application Support/Claude/claude_desktop_config.json
- Windows:%APPDATA%\Claude\claude_desktop_config.json
- Linux:~/.config/Claude/claude_desktop_config.json
用文本编辑器（如VS Code、Notepad++）打开这个JSON文件。
在mcpServers对象中添加n8n-workflow-builder的配置。这里的关键是command和args，它们告诉Claude如何启动我们的MCP服务器。同时，通过env字段传入连接n8n所需的环境变量。

{ "mcpServers": { "n8n-workflow-builder": { "command": "npx", "args": ["@makafeli/n8n-workflow-builder"], "env": { "N8N_HOST": "http://localhost:5678", "N8N_API_KEY": "你的_n8n_API_密钥" } } // ... 你可以在这里配置其他MCP服务器 } }

保存配置文件，并完全重启Claude Desktop应用（不是关闭聊天窗口，而是退出整个应用再重新打开）。
重启后，当你新建一个对话时，Claude应该会在回复中提示你它已经连接了新的工具（例如：“我已连接到n8n Workflow Builder服务器，可以帮你管理n8n工作流了。”）。如果没有提示，你可以在对话中尝试输入“你能用什么工具？”或“列出可用的工具”来触发它检查。

避坑技巧：配置文件修改后务必重启Claude Desktop！这是最多人踩的坑。另外，确保N8N_HOST的地址可以从运行Claude Desktop的机器上访问。如果n8n运行在Docker容器或远程服务器，localhost可能需要替换为具体的IP地址。

4. 核心工具详解与实战应用

连接成功后，你的AI助手就拥有了15把操作n8n的“瑞士军刀”。我们来深入看看其中最常用、最核心的几个工具，以及如何在实际场景中运用它们。

4.1 探索与洞察：`list_workflows`与`get_workflow`

在管理大量自动化流程时，快速概览和定位是关键。list_workflows工具就是你的“仪表盘”。

它能做什么：获取你的n8n实例中所有工作流的列表，通常包括每个工作流的ID、名称、激活状态、创建时间等基础信息。
典型使用场景：
- 新接手一个n8n实例：快速了解存在哪些自动化流程。
- 定期巡检：让AI助手每天上午自动列出所有工作流，并报告是否有处于“错误”状态的工作流。
- 寻找特定工作流：结合AI的语义理解，你可以说“帮我找一下所有和‘邮件通知’相关的工作流”，AI会先获取列表，然后根据名称帮你筛选。

get_workflow则是你的“显微镜”。当你从列表中找到感兴趣的工作流ID后，可以用这个工具获取其完整的、详细的JSON定义。

它能做什么：根据工作流ID，返回该工作流的完整配置，包括所有的节点（nodes）、连接线（connections）、触发器设置、凭据引用等。
为什么需要它：n8n工作流的复杂性隐藏在节点配置和连接关系中。这个工具返回的JSON，是工作流的“源代码”。你可以：
1. 分析问题：当某个工作流执行失败时，让AI助手获取其定义，并结合执行日志帮你分析可能出错的节点。
2. 学习与复制：看到一个设计精妙的工作流，可以获取其JSON，作为模板来创建类似的工作流。
3. 备份：定期让AI助手获取关键工作流的定义并保存，作为一种简单的配置备份。

4.2 创造与构建：`create_workflow`

这是将自然语言想法转化为实际自动化流程的魔法棒。但它的使用有一定门槛，因为你需要以n8n能理解的JSON格式来描述一个工作流。

核心参数：一个workflow对象。这个对象的结构必须符合n8n的API要求。一个最简化的结构通常包含：

{ "name": "工作流名称", "nodes": [...], // 节点数组 "connections": {...}, // 节点间的连接关系 "settings": {...} // 可选，工作流级设置 }

难点与技巧：手动编写这个JSON，尤其是nodes和connections部分，非常复杂且容易出错。这里的核心技巧是：让AI助手帮你生成这个JSON。你可以这样操作：
1. 先向AI助手描述你想要的工作流：“我想创建一个工作流，每周一早上9点，从Airtable的‘项目’表中读取本周期待办事项，然后为每个事项在ClickUp中创建一个任务。”
2. AI助手（在MCP工具的加持下）可能会根据它的知识，为你生成一个大概的nodes数组框架，包括scheduleTrigger、airtable节点、clickUp节点等。
3. 但是，每个节点的具体参数（如Airtable的表ID、ClickUp的列表ID）以及节点间精确的connections映射，AI可能无法凭空知道。这时，你可以：
  - 先创建一个“骨架”工作流：让AI创建一个只包含触发器和一个HTTP Request（或Code）节点的基础工作流，保存下来。
  - 在n8n UI中完善：在熟悉的Web界面里，编辑这个新建的“骨架”工作流，拖入实际的Airtable、ClickUp节点，并完成配置和连线。这样比纯手写JSON效率高得多。
  - 使用get_workflow学习：如果你已经有一个类似的工作流，先用get_workflow工具获取它的完整JSON，然后让AI助手帮你分析其结构，并以此为基础修改成新的工作流。

实操心得：create_workflow最适合的场景不是“从零到一”创建复杂工作流，而是“从模板复制”或“批量创建相似工作流”。例如，你需要为10个不同的Google Sheets表格创建10个结构相同（都是读取数据->处理->发送通知）但参数不同的工作流。你可以先手动创建一个完美的模板，然后用AI助手读取其JSON，编写一个脚本循环修改其中的表格ID等参数，并调用10次create_workflow。这才是AI自动化价值的最大化。

4.3 控制与执行：`activate_workflow`,`deactivate_workflow`,`execute_workflow`

工作流创建后，生命周期管理就变得很重要。

activate_workflow/deactivate_workflow：这两个工具用于激活或停用一个工作流。一个被激活的工作流，其触发器（如定时触发器、Webhook）才会开始监听事件。这在以下场景非常有用：
- 维护窗口：在系统维护前，让AI助手批量停用所有生产环境的工作流。
- 灰度发布：先激活新版本工作流进行测试，同时保持旧版本处于停用状态作为回滚备份。
- 节假日开关：创建一个在节假日自动停用某些非紧急通知类工作流的自动化流程。
execute_workflow：手动立即执行一次工作流。这对于调试、测试或在特定事件触发后立即运行某个流程至关重要。例如，当你通过其他方式（如命令行脚本）更新了某个数据源后，可以立即通知AI助手：“请立即手动执行‘数据同步’工作流。”

4.4 高级管理：执行与标签管理

新版本的工具集增加了对工作流执行记录和标签的管理能力，让运维和治理更加完善。

list_executions：这是一个强大的运维工具。你可以用它来筛选和查看工作流的执行历史。参数如status（过滤成功/失败/等待中的执行）、workflowId（查看特定工作流的执行）、limit（分页）让排查问题变得高效。你可以让AI助手：“列出过去24小时内所有失败的工作流执行，并告诉我它们属于哪个工作流。”
delete_execution：n8n会保存所有执行记录，长期运行可能会占用数据库空间。这个工具可以用于清理旧的、不必要的执行日志，尤其是在开发测试阶段。
list_tags/create_tag：标签是组织大量工作流的有效方式。你可以按项目（如“Project-X”）、环境（如“production”、“staging”）、功能（如“notification”、“data-pipeline”）来打标签。然后通过AI助手进行分组查询和管理，例如：“给我看看所有打了‘production’和‘critical’标签的工作流状态。”

4.5 安全审计：`generate_audit`

这是一个面向企业级安全与合规的利器。它可以生成一份安全审计报告，帮助你发现潜在的风险点。

它能检查什么（根据其描述可能包括）：
- 长期未运行的工作流：识别那些创建后从未激活或很久未执行过的“僵尸”工作流，它们可能已失效但占用资源。
- 使用高风险节点的凭据：检查是否有工作流使用了存储明文密码或具有过高权限的凭据的节点。
- 暴露在公网的Webhook：列出所有包含Webhook触发器且未受保护的工作流，评估其暴露风险。
- 数据流合规性：检查工作流中是否存在将敏感数据（如客户信息）传输到未经授权的外部服务的节点。
使用方式：可以定期（如每周）让AI助手运行一次审计，并将报告摘要发送到团队频道（如Slack），让所有成员对自动化资产的安全状态保持警觉。

5. 典型应用场景与自动化模式

理解了工具，我们来看看如何将它们组合起来，解决真实世界的问题。

5.1 场景一：自动化运维与监控报告

需求：每天上午10点，自动检查所有生产环境工作流的健康状态，并将报告发送到Slack。

实现思路：

创建一个专用的“监控”工作流：这个工作流本身由n8n的定时触发器驱动。
在该工作流中使用“Code”节点：在这个节点中，我们可以编写一段JavaScript代码，但这段代码不是直接调用n8n API，而是模拟一个AI助手，去调用我们刚部署的MCP服务器工具。当然，更优雅的方式是，这个“监控”工作流直接使用n8n的“HTTP Request”节点，去调用一个专门为这个监控任务编写的、独立的脚本或微服务。而这个微服务内部，则集成了n8n-workflow-builder的客户端逻辑。
微服务内的逻辑：
- 调用list_workflows获取所有工作流。
- 遍历工作流，对每个关键工作流，可能调用get_workflow获取其最新状态，或调用list_executions检查其最近一次执行是否成功。
- 汇总信息，生成一份人类可读的报告（例如：“共50个工作流，其中48个正常，2个处于错误状态：’订单同步‘和’邮件队列‘”）。
发送报告：微服务将报告通过n8n的Webhook或直接调用Slack API，发送到指定频道。

价值：实现了对自动化平台自身的自动化监控，形成了闭环。

5.2 场景二：工作流模板的批量部署

需求：公司每个新客户 onboarding 时，都需要部署一套标准化的自动化工作流（如数据导入、欢迎邮件、初始任务创建等）。这套工作流结构相同，但需要根据客户信息（如CRM中的客户ID、邮箱）替换其中的变量。

实现思路：

制作模板：在n8n中精心创建一个“客户Onboarding模板”工作流，其中使用n8n的表达式（如{{ $node.xxx.data.xxx }}）或变量来代表客户特定信息。
获取模板JSON：使用get_workflow工具，获取这个模板工作流的完整JSON定义。
开发部署脚本：编写一个脚本（可以是Node.js、Python等），这个脚本集成了MCP客户端库。脚本的工作流程是：
- 从CRM或数据库中读取新客户列表及其信息。
- 为每个客户，复制一份模板JSON。
- 使用客户信息（如client_id,client_email）替换JSON中对应节点的参数（例如，将HTTP Request节点的URL中的{client_id}占位符替换为真实的ID）。
- 调用create_workflow_and_activate工具，将修改后的JSON提交给n8n，创建并立即激活这个客户专属的工作流。
自动化触发：将这个部署脚本设置为由“新客户创建”事件（如CRM的Webhook）触发。

价值：将重复性的、易出错的手工配置工作转化为秒级完成的自动化流程，确保部署的一致性和准确性。

5.3 场景三：与AI助手的深度对话式交互

需求：作为团队管理者，我想用最自然的方式了解自动化系统的状态，或者临时调整一些设置。

实现思路：这才是MCP最直接的用法。你只需要和Claude这样的AI助手对话。

查询：“我们有多少个活跃的工作流？上周失败率最高的是哪个？”
- AI会调用list_workflows过滤活跃状态，可能再调用多次list_executions来统计各工作流的失败率，然后给你一个分析结果。
操作：“马上停掉所有标记为‘测试环境’的工作流，我要做数据库迁移。”
- AI会先调用list_workflows，根据名称或标签（如果标签信息在返回数据中）筛选出“测试环境”的工作流，然后遍历调用deactivate_workflow。
诊断：“‘用户数据导出’工作流今天早上失败了，帮我看看可能是什么原因？”
- AI会先调用get_workflow获取该工作流的定义，了解其节点构成。然后调用list_executions获取该工作流最新的失败执行记录。结合两者，AI可以分析执行日志中的错误信息，并对照工作流节点，给出可能出错的环节建议（例如：“失败发生在‘转换数据’节点，错误信息是‘字段xxx不存在’，建议检查上游节点传入的数据结构。”）。

价值：极大降低了使用n8n的管理和运维门槛，让非技术人员也能通过自然语言与复杂的自动化系统进行交互。

6. 常见问题排查与优化技巧

在实际集成和使用过程中，你可能会遇到一些问题。这里我总结了一些常见的坑和解决办法。

6.1 连接类问题

问题：Claude Desktop提示“无法连接到MCP服务器”或配置后无反应。

检查点1：配置文件路径与格式。确保claude_desktop_config.json文件在正确的位置，并且JSON格式正确（无多余逗号，引号匹配）。可以使用在线JSON校验工具检查。
检查点2：环境变量有效性。确保配置文件中env里的N8N_HOST和N8N_API_KEY值正确。特别是N8N_HOST，如果n8n运行在Docker容器内，对于宿主机的Claude来说，localhost可能指向容器内部，需要改用宿主机的IP或Docker内部网络别名。
检查点3：服务器进程。在配置Claude之前，先手动在终端运行npx @makafeli/n8n-workflow-builder（带上环境变量），看服务器是否能独立启动并打印运行日志，而不是立刻退出。如果立刻退出，通常是环境变量缺失或n8n连接失败。
检查点4：Claude Desktop重启。修改MCP配置后，必须完全退出并重启Claude Desktop应用，仅关闭聊天窗口是没用的。

问题：MCP服务器启动失败，报错“Error: Unable to connect to n8n instance”。

排查网络连通性：在终端使用curl命令测试n8n地址是否可访问。例如：curl http://localhost:5678/healthz（n8n的健康检查端点）或curl http://localhost:5678/api/v1。确保能收到响应。
验证API密钥：使用curl或Postman等工具，手动调用一个n8n API进行验证。例如：
```
curl -H "X-N8N-API-KEY: YOUR_API_KEY" http://localhost:5678/api/v1/workflows
```
如果返回401错误，说明API密钥无效或权限不足。
检查n8n版本与API路径：较新版本的n8n，其API根路径可能是/api/v1。确保你的N8N_HOST设置正确。如果是http://localhost:5678，MCP服务器会尝试连接http://localhost:5678/api/v1。如果你的n8n版本不同或做了路径修改，可能需要设置为完整的API地址，如http://localhost:5678/api/v1。

6.2 权限与操作类问题

问题：AI助手可以列出工作流，但无法激活或创建，提示“Forbidden”或“Insufficient permissions”。

原因：使用的n8n API密钥权限不足。list_workflows通常只需要workflow:read权限，而activate_workflow和create_workflow需要workflow:write权限。
解决：登录n8n，找到对应的API密钥，编辑其权限范围，勾选所需的所有操作权限（如workflow:read,workflow:write,execution:read,execution:delete等）。遵循最小权限原则，按需分配。

问题：通过AI创建的工作流，节点配置看起来正确，但执行时失败。

排查步骤：
1. 使用get_workflow获取AI创建的工作流JSON，与一个手动创建的成功工作流JSON进行对比。重点关注nodes数组中每个节点的parameters和position字段。
2. 检查凭据（Credentials）：通过API创建的工作流，如果节点引用了n8n中已保存的凭据，需要确保凭据的id在JSON中引用正确。更常见且安全的方式是，在JSON中不写死凭据ID，而是让工作流在创建后，由人工在n8n UI中首次激活时去选择或创建凭据（n8n会提示）。
3. 简化测试：让AI先创建一个只包含一个“Manual Trigger”和一个“Code”节点（输出固定信息）的极简工作流，测试创建和执行流程是否通畅。再逐步增加复杂节点。

6.3 性能与使用技巧

技巧：处理大量工作流时的优化

当你的n8n实例中有成百上千个工作流时，直接调用list_workflows可能会返回大量数据，导致AI助手响应变慢。

分页意识：虽然当前工具的list_workflows可能未暴露分页参数，但你在让AI助手处理结果时，可以指示它：“只列出前20个活跃的工作流”或“找出名称中包含‘报警’的工作流”。AI可以在获取全部列表后，在本地进行过滤和摘要，避免在聊天界面刷屏。
结合标签：积极使用create_tag工具为工作流分类。之后可以让AI先调用list_workflows，然后根据返回数据中的标签信息进行筛选，或者未来如果工具支持按标签过滤，效率会更高。

技巧：将复杂操作封装为“超级指令”

你可以训练你的AI助手，将一系列常见的MCP工具调用组合成一个“超级指令”。例如，你可以告诉Claude：“当我下次说‘给我一份系统健康报告’时，请你依次执行：1. 列出所有工作流；2. 检查每个活跃工作流最近一次执行的状态；3. 统计成功和失败的数量；4. 用清晰的格式总结给我。” 虽然这需要AI在后台执行多个步骤，但对你来说，体验就是一个简单的指令。

7. 进阶：自定义扩展与开发

如果你不满足于现有的15个工具，或者有特殊的业务逻辑需要集成，那么这个开源项目的价值就更大了——你可以扩展它。

7.1 项目结构概览

克隆项目源码后，你会看到典型的TypeScript项目结构。核心代码位于src目录下。你需要重点关注的是定义MCP工具（Tools）的文件，通常是src/tools/目录下的各个文件，或者在一个统一的src/tools.ts或src/index.ts中。

每个工具本质上是一个函数，它接收来自AI客户端的参数，调用对应的n8n API，然后将结果格式化成MCP协议要求的格式返回。工具的定义会使用@modelcontextprotocol/sdk库中的相关装饰器或方法。

7.2 添加一个自定义工具示例

假设你想添加一个工具，用于获取n8n实例的系统状态（如队列长度、内存使用率——如果n8n API提供的话）。

在工具定义文件中添加新工具函数。例如，在src/tools/下创建systemTools.ts：

import { Server } from '@modelcontextprotocol/sdk/server/index.js'; import { CallToolRequest } from '@modelcontextprotocol/sdk/types.js'; import { n8nApiClient } from '../clients/n8nClient.js'; // 假设有一个封装好的n8n客户端 export function registerSystemTools(server: Server) { server.setRequestHandler(CallToolRequest, async (request) => { if (request.params.name === 'get_system_status') { try { // 调用n8n可能存在的系统状态API（此处为示例，需确认n8n API是否存在该端点） const status = await n8nApiClient.get('/system/status'); return { content: [{ type: 'text', text: JSON.stringify(status.data, null, 2) }] }; } catch (error) { return { content: [{ type: 'text', text: `Failed to get system status: ${error.message}` }], isError: true }; } } // ... 其他工具的处理 }); }

在主文件（如src/index.ts）中注册这个新工具集。
重新构建项目：npm run build。
更新你的Claude Desktop配置，指向你本地修改后构建的服务器（例如，将command改为node，args改为你本地dist/index.js的绝对路径）。

7.3 与其他系统集成

n8n-workflow-builderMCP服务器本身也可以成为更大自动化流程的一部分。例如，你可以创建一个n8n工作流，这个工作流中的一个“HTTP Request”节点，去调用另一个服务，而这个服务内部就集成了MCP客户端，能够驱动AI助手去管理第三个n8n实例。这就构建起了跨自动化平台的编排能力。

最后，我想说的是，makafeli/n8n-workflow-builder这个项目真正有趣的地方，不在于它替代了n8n的Web界面，而在于它打开了一种新的可能性：用自然语言和对话来驾驭复杂的自动化基础设施。它降低了操作门槛，提升了运维效率，并且为更智能的、自适应的自动化系统铺平了道路。从简单的查询到复杂的批量操作，再到与AI助手的深度协作，这套工具链值得每一个认真的n8n用户去尝试和探索。

查看全文

http://www.jsqmd.com/news/813955/