n8n-workflow-builder-mcp
n8n Workflow Builder MCP
Un servidor de Model Context Protocol (MCP) para crear y manipular flujos de trabajo (workflows) de n8n. Crea flujos de trabajo de n8n simplemente mediante prompts con IA; funciona con Claude Code, VS Code, Cursor y cualquier cliente compatible con MCP.
VÍDEO DE DEMOSTRACIÓN:
Reglas de Cursor
El archivo con las reglas se encuentra en
rules/n8n-mcp-server-rules.mdc
Related MCP server: mcp-n8n-builder
Características principales
Gestión de flujos de trabajo: Crea, actualiza y ejecuta flujos de trabajo de n8n mediante programación (la ejecución aún no está implementada)
Descubrimiento de nodos: Explora los nodos de n8n disponibles y sus capacidades
Gestión de conexiones: Crea conexiones entre nodos de flujo de trabajo
Integración con IA: Herramientas especiales para conectar componentes de IA en los flujos de trabajo
Interfaz amigable para IA: Diseñada específicamente para la interacción con agentes de IA
Gestión de versiones de N8N: Detección automática de versiones y manejo de compatibilidad; admite más de 184 versiones de n8n (1.86.0 – 2.6.2) con filtrado dinámico de nodos y coincidencia con la "versión inferior más cercana" para compatibilidad con versiones anteriores
Requisitos previos
Node.js (v18 o superior)
npm (para el comando npx)
Un cliente compatible con MCP (Claude Code, VS Code, Cursor, etc.)
Instalación y configuración
Obtención de tu clave API de n8n
Abre tu instancia de n8n en un navegador
Ve a Settings > API Keys
Haz clic en Create API Key
Copia la clave generada y úsala en tu configuración
Claude Code (Recomendado)
Agrega el servidor MCP usando la CLI de Claude Code:
claude mcp add n8n-workflow-builder -- npx -y n8n-workflow-builder-mcpLuego configura las variables de entorno:
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_VERSIONes opcional: el servidor la detecta automáticamente desde la API.
VS Code / Cursor
Agrégalo a tu archivo de configuración de MCP (.vscode/mcp.json para VS Code, .cursor/mcp.json para 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"
}
}
}
}Reinicia tu IDE para que los cambios surtan efecto.
Instalación para desarrollo
Para desarrollo o pruebas locales, clona y compila desde el código fuente:
git clone https://github.com/ifmelate/n8n-workflow-builder-mcp.git
cd n8n-workflow-builder-mcp
npm install
npm run buildLuego apunta tu cliente MCP al punto de entrada compilado:
# 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"]Para desarrollo con recompilación automática:
npm run devHerramientas MCP disponibles
El servidor proporciona las siguientes herramientas para trabajar con flujos de trabajo de n8n:
Gestión principal de flujos de trabajo
Nombre de la herramienta | Descripción | Parámetros clave |
create_workflow | Crea un nuevo flujo de trabajo de n8n |
|
list_workflows | Lista los flujos de trabajo en el espacio de trabajo |
|
get_workflow_details | Obtiene información detallada sobre un flujo de trabajo específico |
|
validate_workflow | Valida un archivo de flujo de trabajo frente a esquemas de nodos y conectividad |
|
Gestión de nodos
Nombre de la herramienta | Descripción | Parámetros clave |
add_node | Agrega un nuevo nodo a un flujo de trabajo |
|
edit_node | Edita un nodo existente en un flujo de trabajo |
|
delete_node | Elimina un nodo de un flujo de trabajo |
|
list_available_nodes | Lista los tipos de nodos disponibles con filtrado opcional. Admite sinónimos estilo etiqueta y lógica OR/AND de múltiples tokens |
|
Gestión de conexiones
Nombre de la herramienta | Descripción | Parámetros clave |
add_connection | Crea una conexión entre dos nodos |
|
add_ai_connections | Conecta un modelo de IA, herramientas y memoria a un agente |
|
connect_main_chain | Construye una ruta principal mínima a través de nodos de flujo de trabajo de IA (Trigger → Model → Memory → Embeddings → Doc Loader → Vector Store → Vector Tool → Agent) |
|
Planificación y composición de flujos de trabajo
Nombre de la herramienta | Descripción | Parámetros clave |
plan_workflow | Crea un plan no destructivo (nodos y conexiones) para actualizar un flujo de trabajo. No escribe archivos |
|
review_workflow_plan | Aplica un plan en memoria y devuelve errores de validación, advertencias y correcciones sugeridas. No escribe archivos |
|
apply_workflow_plan | Aplica un plan previamente revisado al flujo de trabajo en el disco (escritura atómica) |
|
compose_ai_workflow | Compone un flujo de trabajo de IA complejo (agente + modelo + memoria + embeddings + vector + herramientas + trigger) en una sola llamada, incluyendo cableado y validación básica |
|
Gestión de parámetros
Nombre de la herramienta | Descripción | Parámetros clave |
suggest_node_params | Sugiere parámetros válidos mínimos para un tipo de nodo usando valores predeterminados y campos obligatorios |
|
list_missing_parameters | Lista los parámetros obligatorios que faltan para un nodo considerando las reglas de visibilidad |
|
fix_node_params | Devuelve parámetros con valores predeterminados aplicados para los campos obligatorios que faltan |
|
Plantillas y descubrimiento
Nombre de la herramienta | Descripción | Parámetros clave |
list_template_examples | Lista ejemplos de uso de nodos extraídos de plantillas gratuitas. Filtra por node_type o template_name |
|
get_n8n_version_info | Obtiene la versión actual de N8N y sus capacidades |
|
Comportamiento de validación
validate_workflow promueve las advertencias a errores y, además, falla cuando cualquier nodo habilitado no está conectado (directamente o a través de puertos de IA) a la cadena principal que comienza en el startNode inferido. Usa connect_from/connect_to o add_ai_connections para corregir la conectividad.
Solución de problemas
General
Revisa tu configuración de MCP: asegúrate de que el JSON sea válido y que el nombre del servidor coincida.
Actualiza Node.js a la última versión LTS.
Limpia la caché de npm si npx falla:
npm cache clean --forceIntenta una instalación global como alternativa:
npm install -g n8n-workflow-builder-mcp
Claude Code
Ejecuta
claude mcp listpara verificar que el servidor esté registrado.Revisa los registros con
claude mcp logs n8n-workflow-builder.
VS Code / Cursor
Revisa el panel de Salida (Output): selecciona "MCP" en el menú desplegable para ver los registros del servidor.
Asegúrate de que el servidor esté habilitado en Settings > Features > MCP Servers.
Reinicia el IDE después de realizar cambios en la configuración.
Estructura del proyecto
/src: Código fuente principal/src/tools: Implementación de herramientas MCP/src/models: Modelos de datos/src/utils: Funciones de utilidad/src/middleware: Autenticación y middleware/config: Archivos de configuración/tests: Archivos de prueba/workflow_nodes: Definiciones de nodos de n8n/docs: Documentación adicional
Contribución
¡Las contribuciones son bienvenidas! Por favor, siéntete libre de enviar un Pull Request.
Haz un fork del repositorio
Crea tu rama de funciones (
git checkout -b feature/amazing-feature)Confirma tus cambios (
git commit -m 'Add some amazing feature')Envía la rama (
git push origin feature/amazing-feature)Abre un Pull Request
Licencia
Licencia MIT
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