MCP server for n8n - provides tools to interact with n8n workflows, nodes, templates, and tags
The n8n MCP server defines 11 tools with consistent naming and basic schemas, but has significant gaps in parameter descriptions, output documentation, and error handling guidance. All tools follow verb_noun naming convention (list_, get_, create_, activate_, deactivate_, search_, add_tags_to_, index_). However, parameter descriptions are sparse or generic, output schemas are entirely undocumented, and error handling provides no recovery guidance. The server lacks input validation documentation, output field documentation, and security considerations around workflow creation. Descriptions are present but brief (50-150 chars typical), below the 194-char baseline for production tools. All 11 tools have registered schemas with type definitions, so schemas are not critically broken, but lack constraints (enums, ranges, patterns) and completeness around optional/required fields.
Activate a workflow
Add tags to a workflow
Create a new tag
Create a new workflow
Deactivate a workflow
Get documentation/specs for a specific node type from n8n documentation.
Get details of a specific workflow
Output schemas completely undocumented. No tool documents what fields are returned, their types, or required chaining IDs (e.g., workflow_id for downstream calls). LLMs cannot plan multi-step operations without knowing response structure.
Activation/deactivation tools (activate_workflow, deactivate_workflow) have minimal descriptions (50 chars) and do not clarify state-change semantics. Descriptions must explain what 'active' means (scheduled? running?) and whether repeated calls are idempotent.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
explore the n8n node library by category (Core, App, Trigger, etc.) to find the right node for a task.
List all available tags
List all workflows on the n8n server
Search for n8n workflow templates to find examples of how to use nodes.
create_workflow accepts 'nodes' and 'connections' as generic objects with minimal description. No schema constraints on node structure, required fields, or valid connection formats. LLMs will hallucinate invalid node definitions. Descriptions must specify node schema (type, properties, required fields).
Error handling provides no recovery guidance. All errors likely return raw API responses without suggesting next steps. E.g., 'workflow not found' should suggest search_workflows() or list_workflows(). No categorization (retryable vs fatal).
list_workflows lacks pagination controls. No documented limit parameter, no offset/cursor support, no documented max results. If a server has 1000 workflows, the response could exhaust token budget. Must implement page/limit and return total_count.
Parameter descriptions are under-specified. E.g., 'Filter by active status' does not say what 'active' means; 'tags' says 'Filter by tags' without explaining whether it's AND or OR logic. Many parameters lack type constraints (enums, ranges, formats).
Destructive operations (create_workflow, activate_workflow, deactivate_workflow) have no confirmation or dry-run support. No mention in descriptions that calls are irreversible. Agents risk unintended workflow activation or creation without safeguards.
N8N_API_KEY is stored in environment variables (dotenv). No mention of how secrets are managed in production or whether credentials could leak into logs. Tool descriptions do not document that the connection is authenticated or what permissions are required.