n8n-workflow-builder-mcp
n8n Workflow Builder MCP
Ein Model Context Protocol (MCP) Server zum Erstellen und Bearbeiten von n8n-Workflows. Erstellen Sie n8n-Workflows einfach per KI-Prompt – funktioniert mit Claude Code, VS Code, Cursor und jedem MCP-kompatiblen Client.
DEMO-VIDEO:
Cursor-Regeln
Die Datei mit den Regeln befindet sich unter
rules/n8n-mcp-server-rules.mdc
Related MCP server: mcp-n8n-builder
Hauptfunktionen
Workflow-Verwaltung: Erstellen, Aktualisieren und Ausführen von n8n-Workflows per Programmcode (Ausführung ist noch nicht implementiert)
Node-Discovery: Erkunden Sie verfügbare n8n-Nodes und deren Funktionen
Verbindungsverwaltung: Erstellen Sie Verbindungen zwischen Workflow-Nodes
KI-Integration: Spezielle Tools zum Verbinden von KI-Komponenten in Workflows
KI-freundliche Schnittstelle: Speziell für die Interaktion mit KI-Agenten entwickelt
n8n-Versionsverwaltung: Automatische Versionserkennung und Kompatibilitätsbehandlung – unterstützt über 184 n8n-Versionen (1.86.0 – 2.6.2) mit dynamischer Node-Filterung und "Closest Lower Version"-Matching für Abwärtskompatibilität
Voraussetzungen
Node.js (v18 oder höher)
npm (für den npx-Befehl)
Ein MCP-kompatibler Client (Claude Code, VS Code, Cursor, etc.)
Installation & Einrichtung
Abrufen Ihres n8n-API-Schlüssels
Öffnen Sie Ihre n8n-Instanz im Browser
Gehen Sie zu Settings > API Keys
Klicken Sie auf Create API Key
Kopieren Sie den generierten Schlüssel und verwenden Sie ihn in Ihrer Konfiguration
Claude Code (Empfohlen)
Fügen Sie den MCP-Server über die Claude Code CLI hinzu:
claude mcp add n8n-workflow-builder -- npx -y n8n-workflow-builder-mcpSetzen Sie dann die Umgebungsvariablen:
claude mcp add n8n-workflow-builder \
-e N8N_API_URL=http://localhost:5678 \
-e N8N_API_KEY=your-n8n-api-key-here \
-- npx -y n8n-workflow-builder-mcp
N8N_VERSIONist optional – der Server erkennt sie automatisch über die API.
VS Code / Cursor
Fügen Sie dies zu Ihrer MCP-Konfigurationsdatei hinzu (.vscode/mcp.json für VS Code, .cursor/mcp.json für Cursor):
{
"mcpServers": {
"n8n-workflow-builder": {
"command": "npx",
"args": ["-y", "n8n-workflow-builder-mcp"],
"env": {
"N8N_API_URL": "http://localhost:5678",
"N8N_API_KEY": "your-n8n-api-key-here"
}
}
}
}Starten Sie Ihre IDE neu, damit die Änderungen wirksam werden.
Entwicklungsinstallation
Für die Entwicklung oder lokale Tests klonen und bauen Sie aus dem Quellcode:
git clone https://github.com/ifmelate/n8n-workflow-builder-mcp.git
cd n8n-workflow-builder-mcp
npm install
npm run buildVerweisen Sie dann Ihren MCP-Client auf den gebauten Einstiegspunkt:
# Claude Code
claude mcp add n8n-workflow-builder -- node /absolute/path/to/n8n-workflow-builder-mcp/dist/index.js
# VS Code / Cursor — use the same JSON config above with "command": "node" and "args": ["/absolute/path/to/dist/index.js"]Für die Entwicklung mit automatischem Rebuild:
npm run devVerfügbare MCP-Tools
Der Server stellt die folgenden Tools für die Arbeit mit n8n-Workflows bereit:
Kern-Workflow-Verwaltung
Tool-Name | Beschreibung | Wichtige Parameter |
create_workflow | Erstellt einen neuen n8n-Workflow |
|
list_workflows | Listet Workflows im Arbeitsbereich auf |
|
get_workflow_details | Ruft detaillierte Informationen zu einem bestimmten Workflow ab |
|
validate_workflow | Validiert eine Workflow-Datei anhand von Node-Schemas und Konnektivität |
|
Node-Verwaltung
Tool-Name | Beschreibung | Wichtige Parameter |
add_node | Fügt einem Workflow einen neuen Node hinzu |
|
edit_node | Bearbeitet einen vorhandenen Node in einem Workflow |
|
delete_node | Löscht einen Node aus einem Workflow |
|
list_available_nodes | Listet verfügbare Node-Typen mit optionaler Filterung auf. Unterstützt Tag-artige Synonyme und Multi-Token-OR/AND-Logik |
|
Verbindungsverwaltung
Tool-Name | Beschreibung | Wichtige Parameter |
add_connection | Erstellt eine Verbindung zwischen zwei Nodes |
|
add_ai_connections | Verbindet KI-Modell, Tools und Speicher mit einem Agenten |
|
connect_main_chain | Baut einen minimalen Hauptpfad durch KI-Workflow-Nodes (Trigger → Modell → Speicher → Embeddings → Doc Loader → Vektorspeicher → Vektor-Tool → Agent) |
|
Workflow-Planung & Komposition
Tool-Name | Beschreibung | Wichtige Parameter |
plan_workflow | Erstellt einen nicht-destruktiven Plan (Nodes und Verbindungen) zur Aktualisierung eines Workflows. Schreibt keine Dateien |
|
review_workflow_plan | Wendet einen Plan im Arbeitsspeicher an und gibt Validierungsfehler, Warnungen und Lösungsvorschläge zurück. Schreibt keine Dateien |
|
apply_workflow_plan | Wendet einen zuvor überprüften Plan auf den Workflow auf der Festplatte an (atomares Schreiben) |
|
compose_ai_workflow | Erstellt einen komplexen KI-Workflow (Agent + Modell + Speicher + Embeddings + Vektor + Tools + Trigger) in einem Aufruf, inklusive Verkabelung und grundlegender Validierung |
|
Parameter-Verwaltung
Tool-Name | Beschreibung | Wichtige Parameter |
suggest_node_params | Schlägt minimale gültige Parameter für einen Node-Typ unter Verwendung von Standardwerten und Pflichtfeldern vor |
|
list_missing_parameters | Listet erforderliche Parameter auf, die für einen Node unter Berücksichtigung von Sichtbarkeitsregeln fehlen |
|
fix_node_params | Gibt Parameter mit angewendeten Standardwerten für fehlende Pflichtfelder zurück |
|
Vorlagen & Discovery
Tool-Name | Beschreibung | Wichtige Parameter |
list_template_examples | Listet Beispiele für die Node-Verwendung aus kostenlosen Vorlagen auf. Filtern nach node_type oder template_name |
|
get_n8n_version_info | Ruft die aktuelle n8n-Version und Funktionen ab |
|
Validierungsverhalten
validate_workflow stuft Warnungen zu Fehlern hoch und schlägt zusätzlich fehl, wenn ein aktivierter Node nicht (direkt oder über KI-Ports) mit der Hauptkette verbunden ist, die am abgeleiteten startNode beginnt. Verwenden Sie connect_from/connect_to oder add_ai_connections, um die Konnektivität zu korrigieren.
Fehlerbehebung
Allgemein
Überprüfen Sie Ihre MCP-Konfiguration — stellen Sie sicher, dass das JSON gültig ist und der Servername übereinstimmt.
Aktualisieren Sie Node.js auf die neueste LTS-Version.
Leeren Sie den npm-Cache, falls npx fehlschlägt:
npm cache clean --forceVersuchen Sie eine globale Installation als Fallback:
npm install -g n8n-workflow-builder-mcp
Claude Code
Führen Sie
claude mcp listaus, um zu überprüfen, ob der Server registriert ist.Überprüfen Sie die Protokolle mit
claude mcp logs n8n-workflow-builder.
VS Code / Cursor
Überprüfen Sie das Ausgabefenster (Output) — wählen Sie "MCP" aus dem Dropdown-Menü, um Server-Protokolle zu sehen.
Stellen Sie sicher, dass der Server unter Settings > Features > MCP Servers aktiviert ist.
Starten Sie die IDE nach Konfigurationsänderungen neu.
Projektstruktur
/src: Hauptquellcode/src/tools: Implementierung der MCP-Tools/src/models: Datenmodelle/src/utils: Hilfsfunktionen/src/middleware: Authentifizierung und Middleware/config: Konfigurationsdateien/tests: Testdateien/workflow_nodes: n8n-Node-Definitionen/docs: Zusätzliche Dokumentation
Mitwirken
Beiträge sind willkommen! Bitte zögern Sie nicht, einen Pull Request einzureichen.
Forken Sie das Repository
Erstellen Sie Ihren Feature-Branch (
git checkout -b feature/amazing-feature)Committen Sie Ihre Änderungen (
git commit -m 'Add some amazing feature')Pushen Sie den Branch (
git push origin feature/amazing-feature)Öffnen Sie einen Pull Request
Lizenz
MIT-Lizenz
Available Tools
10 toolsadd_ai_connectionsD
| Name | Required | Description | Default |
|---|---|---|---|
| agent_node_id | Yes | The ID of the agent node that will use the model and tools | |
| memory_node_id | No | The ID of the memory node (optional) | |
| model_node_id | No | The ID of the language model node (optional) | |
| tool_node_ids | No | Array of tool node IDs to connect to the agent (optional) | |
| workflow_name | Yes | The Name of the workflow to add the AI connections to |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
add_connectionD
| Name | Required | Description | Default |
|---|---|---|---|
| source_node_id | Yes | The ID of the source node for the connection | |
| source_node_output_name | Yes | The name of the output handle on the source node (e.g., 'main') | |
| target_node_id | Yes | The ID of the target node for the connection | |
| target_node_input_index | No | The index for the target node's input handle (default: 0) | |
| target_node_input_name | Yes | The name of the input handle on the target node (e.g., 'main') | |
| workflow_name | Yes | The Name of the workflow to add the connection to |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
add_nodeD
| Name | Required | Description | Default |
|---|---|---|---|
| node_name | No | The name for the new node (e.g., 'My Gmail Node') | |
| node_type | Yes | The type of node to add (e.g., 'gmail', 'slack', 'openAi'). You can specify with or without the 'n8n-nodes-base.' prefix. The system will handle proper casing (e.g., 'openai' will be converted to 'openAi' if that's the correct casing). | |
| parameters | No | The parameters for the node | |
| position | No | The position of the node {x,y} - will be converted to [x,y] for N8nWorkflowNode | |
| typeVersion | No | The type version for the node (e.g., 1, 1.1). Defaults to 1 if not specified. | |
| webhookId | No | Optional webhook ID for certain node types like triggers. | |
| workflow_name | Yes | The Name of the workflow to add the node to | |
| workflow_path | No | Optional direct path to the workflow file (absolute or relative to current working directory). If not provided, uses standard workflow_data directory approach. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_workflowD
| Name | Required | Description | Default |
|---|---|---|---|
| workflow_name | Yes | The name for the new workflow | |
| workspace_dir | Yes | Absolute path to the project root directory where workflow_data will be stored |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_nodeD
| Name | Required | Description | Default |
|---|---|---|---|
| node_id | Yes | The ID of the node to delete | |
| workflow_name | Yes | The Name of the workflow containing the node | |
| workflow_path | No | Optional direct path to the workflow file (absolute or relative to current working directory). If not provided, uses standard workflow_data directory approach. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
edit_nodeD
| Name | Required | Description | Default |
|---|---|---|---|
| node_id | Yes | The ID of the node to edit | |
| node_name | No | The new name for the node | |
| node_type | No | The new type for the node (e.g., 'gmail', 'slack', 'openAi'). You can specify with or without the 'n8n-nodes-base.' prefix. The system will handle proper casing (e.g., 'openai' will be converted to 'openAi' if that's the correct casing). | |
| parameters | No | The new parameters | |
| position | No | The new position {x,y} - will be converted to [x,y] | |
| typeVersion | No | The new type version for the node | |
| webhookId | No | Optional new webhook ID for the node. | |
| workflow_name | Yes | The Name of the workflow containing the node | |
| workflow_path | No | Optional workflow path to the workflow file |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_n8n_version_infoD
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_workflow_detailsD
| Name | Required | Description | Default |
|---|---|---|---|
| workflow_name | Yes | The Name of the workflow to get details for | |
| workflow_path | No | Optional direct path to the workflow file (absolute or relative to current working directory). If not provided, uses standard workflow_data directory approach. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_available_nodesD
| Name | Required | Description | Default |
|---|---|---|---|
| n8n_version | No | Filter nodes by N8N version compatibility. If not provided, uses current configured N8N version. | |
| search_term | No | An optional search term to filter nodes by their name, type, or description. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_workflowsD
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
10 tool updates
v1.0.0- First observed
add_ai_connections - First observed
add_connection - First observed
add_node - First observed
create_workflow - First observed
delete_node - First observed
edit_node - First observed
get_n8n_version_info - First observed
get_workflow_details - First observed
list_available_nodes - First observed
list_workflows
TDQS
Scored across 10 tools
Most tools have distinct purposes targeting different aspects of n8n workflow management (e.g., create_workflow vs. list_workflows, add_node vs. edit_node vs. delete_node). However, add_ai_connections and add_connection could potentially be confused without descriptions, as their relationship is unclear—they might overlap in handling connections.
All tool names follow a consistent verb_noun pattern with snake_case throughout (e.g., add_connection, create_workflow, get_workflow_details). There are no deviations in naming conventions, making the set predictable and readable.
With 10 tools, the count is well-scoped for a workflow builder server, covering core operations like creating, listing, and managing workflows and nodes. Each tool appears to earn its place without being excessive or insufficient for the domain.
The tools cover basic CRUD operations for workflows and nodes (create, list, get, edit, delete), but there are notable gaps. For example, there's no update_workflow or delete_workflow tool, and the absence of descriptions makes it hard to assess if AI connections and general connections are fully covered, potentially leaving dead ends in workflow management.
Maintenance
Related MCP Connectors
Open-source Zapier/n8n alternative as an MCP server: agents build, run and debug your workflows.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
LLM Orchestration Agent (Mcp)
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
Related MCP Servers
- AlicenseBqualityDmaintenanceAn MCP server enabling secure interaction with n8n workflows, executions, and settings via the Model Context Protocol, designed for integration with Large Language Models (LLMs).3358 npm119MIT
- AlicenseAqualityDmaintenance🪄 MCP server for programmatic creation and management of n8n workflows. Enables AI assistants to build, modify, and manage workflows without direct user intervention through a comprehensive set of tools and resources for interacting with n8n's REST API.1050 npm86MIT
- AlicenseBqualityAmaintenanceMCP server for managing n8n workflows through AI assistants. Supports workflow CRUD operations, synchronization, inspection, and execution support for automation-focused workflows.19133 npm2MIT
- AlicenseNot gradedqualityDmaintenanceMCP server for integrating with n8n, enabling workflow automation and management through natural language.318 npm1MIT