This MCP server provides tools for AI agents and developers to generate, lint, debug, and manage n8n workflows — both statically and against live n8n instances.
Stateless Tools (no live n8n required)
Generate Workflows: Convert a plain-English description into a valid n8n workflow JSON, including proper AI Agent/LangChain cluster topology.
Scaffold Custom Nodes: Generate a TypeScript INodeType skeleton for a custom n8n node from a description.
Lint Workflows: Analyze workflow JSON for 20+ rules — deprecated nodes, missing credentials, broken connections, AI Agent misconfigurations, Webhook issues, empty Set nodes, HTTP method/body mismatches, and more.
Diff Workflows: Semantically compare two workflow JSONs, reporting nodes added/removed/modified, connection changes, and settings drift.
Explain Failed Executions: Diagnose a failed execution with per-node findings — nodes returning 0 items, unresolved expressions, error messages with actionable hints, and LLM token usage.
Replay a Single Node: Build a self-contained replay workflow (Manual Trigger → pinned seed data → target node) to debug one node in isolation.
Execution Timeline: Render a per-node timing table showing start offset, duration, items in/out, and errors.
Live-Instance Tools (require N8N_API_URL + N8N_API_KEY)
List/Fetch Workflows: Paginate and filter workflows by active status, tags, or name; retrieve full JSON by ID.
Create Workflows: POST a new workflow to the n8n instance (created inactive).
Activate/Deactivate Workflows: Toggle a workflow's active state.
List Executions: Browse recent executions filtered by workflow ID or status, optionally including full execution data for diagnosis.
Runtime Policies: Control server behavior via environment variables — enable read-only mode, disable specific tools, or restrict access to certain workflow IDs or tags.
Deployment: Supports Docker, Render, Railway, and Fly.io.
Provides tools for generating, linting, and debugging n8n workflows, as well as managing live n8n instances through REST API tools.
An MCP server for n8n that gives Claude, Cursor, and other AI agents tools for generating workflows, linting, diagnosing failed executions, and driving live n8n instances.
We use n8n daily inside AutomateLab and kept hitting the same LLM failures: workflow JSON that imports but fails at runtime, AI Agent clusters wired with the wrong connection types, executions that silently drop items with no clue where to look. Dumping the whole n8n catalog into context doesn't fix it - the failure modes are too subtle (typeVersion mismatches, IF v1 schema, credentials that don't survive import).
So we built a small, focused server: encode the failure modes the lint can catch, the cluster topology the generator must respect, and the diagnosis the agent can't do alone. For a walkthrough of the nine tools with example output, see the launch post on automatelab.tech.
Related MCP server: Caipher MCP
Other n8n MCP servers (notably czlonkowski/n8n-mcp) compete on breadth - 20+ tools and an indexed corpus of every n8n node. They own that niche.
This server is the debugging-and-first-run-correctness MCP for n8n:
execution_explain is the wedge. Paste the execution JSON; get back per-node findings: which nodes returned 0 items, which had unresolved ={{ ... }} expressions, error messages with concrete hints. No other MCP server does this well, and it hits the n8n community's #1 debugging pain point (silent data loss between nodes).
workflow_generate is opinionated about AI Agent topology - emits proper LangChain clusters with ai_languageModel / ai_memory / ai_tool connections (sub-nodes connect upward to the agent, not via main). Imports cleanly on n8n 1.x.
workflow_lint catches the silent failures: deprecated node types (Function → Code, spreadsheetFile → convertToFile), AI Agent missing language model, IF v1 schema, Webhook missing webhookId, broken connections across all connection types (not just main).
5 REST tools (gated on N8N_API_URL + N8N_API_KEY) let you list, fetch, create, activate workflows and pull executions - so the lint and explain tools can run against your live workflows, not just JSON pasted in chat.
Plus: a paired Agent Skill that teaches the model when to use which tool and where to load deeper context (split into references/ so it doesn't bloat the prompt).
Tool names follow dot-notation and form a navigable tree: node.*, workflow.*, execution.*. Every tool declares an outputSchema (so callers can type-check responses) and MCP annotations (read-only / destructive / idempotent / open-world hints).
Stateless (work without a live n8n instance):
Tool | Purpose |
| Plain-English description → workflow JSON. Detects AI-agent intent. |
| Description → single |
| Workflow JSON → list of errors and warnings (20+ rules). |
| Two workflows → semantic diff (nodes added/removed/modified, connections, settings). |
| Failed execution JSON → per-node diagnosis with hints. |
| Workflow + node → self-contained replay workflow that exercises just that node. |
| Execution JSON → per-node timeline table (start, duration, items in/out, errors). |
Live-instance (require N8N_API_URL + N8N_API_KEY env vars):
Tool | Purpose |
| Paginate workflows; filter by active/tags/name. |
| Fetch a workflow by id. |
| POST a workflow. Strips read-only fields. |
| Flip active on/off. |
| Browse executions; pass |
v0.5.0 changes. Three new tools:
workflow_diff,execution_replay,execution_timeline. Lint expanded with 10 new rules (rate-limit, credential drift, expression staleness, code sandbox, webhook test path, manualTrigger-in-active, DST schedule risk, disabled-but-wired, empty Set, HTTP method/body mismatch). New runtime policy env vars:N8N_MCP_READ_ONLY,N8N_MCP_DISABLED_TOOLS,N8N_MCP_ALLOWED_WORKFLOW_IDS,N8N_MCP_ALLOWED_TAGS. DXT bundle + Dockerfile + Render/Railway/Fly deploy configs.
v0.4.0 breaking change. Tools were renamed from
n8n_*(snake_case) to dot-notation. Update any prompts, agent skills, or scripts that referenced the old names.
Constrain the server without forking. Set these env vars before launching:
Env var | Effect |
| Disables |
| Skip those tool registrations entirely. |
| REST tools refuse to touch any workflow outside the list. |
|
|
Useful when handing the MCP to a junior agent or wiring it behind a customer-facing assistant.
Claude Desktop one-click: build the .dxt bundle from dxt/manifest.json (see dxt/README.md).
Docker: docker build -t n8n-mcp . && docker run --rm -i -e N8N_API_URL=... -e N8N_API_KEY=... n8n-mcp.
Render: drop in render.yaml and click "New from Blueprint".
Railway: railway.toml — railway up in the repo root.
Fly.io: fly.toml — fly launch --copy-config.
Requires Node 20 or later.
npm install -g @automatelab/n8n-mcpUse the n8n MCP GitHub Action to lint workflows, diagnose executions, and generate workflow JSON in your CI/CD pipeline:
- uses: ratamaha-git/n8n-mcp@v1
with:
command: 'lint'
workflow-json: ${{ env.WORKFLOW_JSON }}See ACTION.md and GITHUB-ACTION-SETUP.md for examples and publication details.
Cursor (~/.cursor/mcp.json) or Claude Desktop (claude_desktop_config.json):
{
"mcpServers": {
"n8n": {
"command": "npx",
"args": ["-y", "@automatelab/n8n-mcp"],
"env": {
"N8N_API_URL": "https://your-n8n.example.com",
"N8N_API_KEY": "n8n_..."
}
}
}
}The env block is optional - the 4 stateless tools work without it. Get an API key from n8n: Settings → API → Create API key.
Restart your MCP host. The 12 dot-notation tools (workflow.*, node.*, execution.*) appear in the MCP panel.
workflow_generateUse workflow_generate to build: Stripe webhook → Slack message + new row in Google Sheets.
Returns workflow JSON ready for n8n's "Import from File" dialog.
execution_explainHere's a failed execution from n8n. Why is the Slack node not firing? [paste JSON]
Returns:
WARNING [Filter] Returned 0 items. Downstream nodes will not execute.
hint: Common causes: (1) IF/Switch routed to the other branch — check `parameters.conditions`. (2) Filter/Set node dropped everything — inspect its output explicitly.
INFO [Last node executed was "Filter". If the workflow stopped here unexpectedly, check its output items below.]workflow_lintLint this workflow JSON. [paste JSON]
Returns:
ERROR [AI Agent] AI Agent has no `ai_languageModel` sub-node connected. Attach a chat model (e.g. lmChatOpenAi).
WARNING [Webhook] Webhook node has no `webhookId`. n8n auto-generates one on import, so the production URL will change.
WARNING [LegacyFunction] Node type "n8n-nodes-base.function" is deprecated. Use "n8n-nodes-base.code".Or no issues found.
The examples/ directory ships with two ready-to-import workflows:
workflow-stripe-to-slack.json - Stripe webhook fans out to Slack and Google Sheets.
workflow-rss-to-discord.json - RSS feed trigger posts new items to a Discord channel.
Import either via n8n's Import from File dialog.
git clone https://github.com/ratamaha-git/n8n-mcp
cd n8n-mcp
npm install
npm run build
npm run smokenpm run smoke boots the server with a --smoke flag that lists registered tools and exits without binding stdio. Useful for CI or first-run sanity checks.
MIT. See LICENSE.
Developed by AutomateLab.
Diagnose a failed or surprising n8n execution. Paste the execution JSON (from the n8n UI 'Show details' or GET /executions/:id?includeData=true); returns a per-node summary highlighting nodes that returned 0 items, unresolved ={{ ... }} expressions, errors with hints, and LLM token usage. Hits the most common debugging pain point: items 'silently disappearing' between nodes. Deterministic, rule-based.
| Name | Required | Description | Default |
|---|---|---|---|
| execution | Yes | n8n execution payload (REST `?includeData=true` shape or raw UI export). Object or JSON string. |
| Name | Required | Description |
|---|---|---|
| findings | Yes | Per-node findings extracted from the execution payload. |
| error_count | Yes | Number of error-severity findings. |
| warning_count | Yes | Number of warning-severity findings. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds that it is deterministic and rule-based, and details what analysis covers (0-item nodes, unresolved expressions, errors, token usage). No contradiction.
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?
Four sentences, each delivering key info: purpose, input format, output highlights, common pain point. No redundant or unnecessary text. Front-loaded with primary purpose.
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?
Given single parameter, clear annotations, and presence of output schema, the description covers all needed context: what tool does, what input to provide (with sourcing hints), and what output to expect. Also addresses edge case of silent item disappearance.
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?
Only one parameter 'execution' with schema description covering 100%. The tool description adds practical guidance on how to obtain the JSON (UI 'Show details' or API call), which enriches the schema 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?
Description clearly states it diagnoses failed/surprising executions, with specific verb 'Diagnose' and resource 'n8n execution'. It distinguishes from sibling tools like 'execution.list' and 'execution.replay' by focusing on explanation rather than listing or replaying.
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?
Explicitly says when to use: for debugging failed or surprising executions. Provides guidance on obtaining input via UI or API. Lacks explicit when-not-to-use, but context implies it's post-execution only. Good but could be slightly more precise.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent executions from a live n8n instance (requires N8N_API_URL + N8N_API_KEY). Filter by workflowId, status (success|error|waiting), limit. Pass includeData: true to get the full execution body (large) — pair with execution.explain to diagnose a specific failure.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size (n8n default: 100, max: 250). | |
| status | No | Filter by status: success | error | waiting. | |
| workflowId | No | Filter by workflow ID. | |
| includeData | No | Include full execution data (large). Default false — pair with execution.explain. |
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of executions returned. |
| executions | Yes | Either trimmed summaries (default) or full execution bodies (includeData=true). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description discloses authentication requirements and warns about large data when includeData is true. No contradictions with annotations.
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?
Two sentences, front-loaded with purpose and requirements. Every sentence adds essential information with no waste.
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?
Covers purpose, authentication, filtering, data size, and tool pairing. Output schema exists, so return values are documented elsewhere. Could mention pagination or default limit, but still strong.
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?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the use of includeData and the filtering parameters in context, exceeding mere schema repetition.
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?
Clearly states 'List recent executions' (verb+resource) and specifies filtering capabilities. Distinguishes from sibling execution.explain by suggesting pairing, making purpose unmistakable.
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?
Provides context (requires API keys, filtering options) and recommends pairing with execution.explain. Lacks explicit when-not-to-use instructions, but the sibling context and advice are sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a self-contained replay workflow that exercises a single node from a larger workflow. The replay workflow is Manual Trigger -> Replay Seed (Code node with pinned items) -> target node. Optional inputItems or an execution payload pins what the target sees. Useful for iterating on one stubborn node without re-running the whole pipeline. Returns workflow JSON ready to import or push via workflow.create.
| Name | Required | Description | Default |
|---|---|---|---|
| node | Yes | Name of the node to replay. | |
| workflow | Yes | Original workflow JSON. | |
| execution | No | Optional execution payload — pulls real input the target saw last time. | |
| inputItems | No | Optional explicit input items (each becomes `{ json: ... }`). |
| Name | Required | Description |
|---|---|---|
| workflow | Yes | Full n8n workflow JSON (name, nodes, connections, settings, ...). |
| item_count | Yes | Number of input items the replay seed will feed the target. |
| target_node | Yes | Name of the node being replayed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds that it returns a workflow JSON ready for import, does not mutate the original workflow, and explains the internal structure, providing good behavioral context beyond annotations.
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?
The description is concise, front-loads the action, and each sentence adds value with no wasted words.
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?
Given the schema coverage, annotations, and presence of output schema, the description is largely complete. It explains the workflow structure, parameters, and use case, though it could mention that the node name must exist in the workflow.
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?
Schema coverage is 100% so parameters are documented. The description adds meaning by explaining optional parameters (e.g., inputItems become `{ json: ... }`) and how they affect the output.
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?
The description clearly states the tool builds a replay workflow for a single node, specifying the structure (Manual Trigger -> Replay Seed -> target node) and distinguishing it from sibling tools like workflow.create and execution.list.
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?
The description explains it is 'useful for iterating on one stubborn node without re-running the whole pipeline' and mentions optional inputs. However, it does not explicitly state when not to use it or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render an n8n execution as a per-node timeline: start offset, duration, items in/out, error flag. Complements execution.explain — that one surfaces why, this surfaces when. Output is a markdown table sorted by start time. Deterministic.
| Name | Required | Description | Default |
|---|---|---|---|
| execution | Yes | n8n execution payload (must include `data.resultData.runData`). |
| Name | Required | Description |
|---|---|---|
| rows | Yes | Per-node-run timing and item counts, sorted by start_ms. |
| total_ms | Yes | Wall-clock duration of the whole execution in milliseconds. |
| row_count | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds that output is a markdown table sorted by start time and is deterministic, which aligns with idempotentHint. No contradictions.
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?
Two sentences, front-loaded with purpose and output details, second sentence adds sibling differentiation. Every sentence is essential and no waste.
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?
For a simple read-only tool with one parameter, the description fully covers purpose, differentiation, output format, and determinism. Annotations and schema cover safety and parameter constraints. No gaps.
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?
Schema description coverage is 100% for the only parameter 'execution', which already states it must include data.resultData.runData. The tool description adds no additional meaning about the parameter beyond the action.
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?
Description clearly states the verb 'Render' and the resource 'n8n execution as a per-node timeline', and explicitly distinguishes from sibling 'execution.explain' by contrasting 'why' vs 'when'.
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?
Directly contrasts with execution.explain by specifying that this tool surfaces 'when' while the other surfaces 'why', providing clear guidance on when to use each. Does not mention other alternatives like execution.replay, but the explicit comparison is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scaffold a TypeScript skeleton for an n8n custom node from a plain-English description. Returns a single TypeScript file implementing INodeType with description, credentials reference, and an execute method stub. Pure code generation — no network, no filesystem writes.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeName | No | Optional PascalCase class name, e.g. 'DiscordRateLimited'. Derived from the description if omitted. | |
| description | Yes | Plain-English description of what the node should do (1+ chars). |
| Name | Required | Description |
|---|---|---|
| source | Yes | The full TypeScript source of the scaffolded node. |
| language | Yes | Always 'typescript' — n8n custom nodes are TS-only. |
| node_name | Yes | PascalCase class name of the generated node. |
| display_name | Yes | Human-readable display name shown in the n8n UI. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by stating it is pure code generation with no network or filesystem writes, aligning with readOnlyHint. No contradiction with annotations.
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?
The description is very concise—two sentences that front-load the action and contain no fluff. Every sentence adds value.
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?
Given the tool's simplicity, two parameters, and presence of an output schema, the description is complete. It explains purpose, output, and constraints sufficiently.
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?
Schema covers 100% of parameters, so baseline is 3. The description adds some context (e.g., deriving nodeName from description) but does not significantly enhance parameter understanding.
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?
The description clearly states the tool scaffolds a TypeScript skeleton for an n8n custom node from a plain-English description, distinguishing it from sibling tools which deal with execution and workflow management.
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?
The description explains when to use it (from a plain-English description) but does not explicitly state when not to use or provide alternatives. However, the context of siblings makes this less critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Activate or deactivate a workflow on a live n8n instance (requires N8N_API_URL + N8N_API_KEY). Pass active: false to deactivate. Idempotent — re-activating an already-active workflow is a no-op on n8n's side.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Workflow ID. | |
| active | No | Defaults to true (activate). Set false to deactivate. |
| Name | Required | Description |
|---|---|---|
| id | Yes | The workflow ID that was (de)activated. |
| ok | Yes | |
| action | Yes | Which action was performed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false. The description adds the requirement for external authentication but repeats idempotency. Marginal added value beyond annotations.
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?
Two sentences with no fluff. First sentence covers verb, resource, and requirement. Second covers parameter usage and idempotency. Front-loaded and efficient.
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?
Given the simple toggle action, output schema existence, and annotation coverage, the description is complete. It explains the action, requirements, and side effects (no-op) adequately.
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?
Schema description coverage is 100%, so the schema fully documents parameters. Description merely paraphrases (e.g., 'Pass active: false to deactivate'), adding no new meaning beyond the schema.
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?
Clearly states verb (activate/deactivate) and resource (workflow) with context of live n8n instance. However, it doesn't explicitly differentiate from sibling tools like workflow.create or workflow.get, though the action is distinct.
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?
Provides explicit prerequisites (N8N_API_URL, N8N_API_KEY) and usage pattern for deactivation. Lacks explicit when-not-to-use or alternatives, but gives clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a workflow on a live n8n instance (requires N8N_API_URL + N8N_API_KEY). Strips read-only fields (id, active, createdAt, ...) before posting. Workflows are created inactive — call workflow.activate afterward. Pairs with workflow.generate for end-to-end 'describe -> deploy'.
| Name | Required | Description | Default |
|---|---|---|---|
| workflow | Yes | Workflow JSON to create (typically the output of workflow.generate). Either a parsed object or a JSON string. |
| Name | Required | Description |
|---|---|---|
| id | Yes | The ID assigned by n8n to the new workflow. |
| name | Yes | The name of the newly created workflow. |
| workflow | Yes | Full n8n workflow JSON (name, nodes, connections, settings, ...). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that read-only fields are stripped before posting and that workflows are created inactive, adding context beyond annotations (readOnlyHint=false, destructiveHint=false). No contradictions.
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?
Three sentences front-loading purpose, then requirements, then behavior and pairing, with no wasted words.
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?
Covers purpose, prerequisites, behavioral nuances, and pairing with sibling tools; output schema exists but description still provides full context for invocation.
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?
Schema coverage is 100%; description adds context that the parameter is typically the output of workflow.generate and can be an object or string, enhancing schema meaning.
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?
Clear verb+resource: 'create a workflow on a live n8n instance' distinguishes from siblings like workflow.activate and workflow.generate.
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?
Explicitly states required credentials (N8N_API_URL + N8N_API_KEY), notes that workflows are created inactive (use workflow.activate afterward), and pairs with workflow.generate for end-to-end flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Semantic diff between two workflows. Reports nodes added / removed / modified (with field-level deltas: type, typeVersion, parameters, credentials, disabled, position), connection topology changes, and settings drift. Ignores noise (small position deltas, createdAt/updatedAt). Pair with workflow.get to compare deployed vs local. Deterministic.
| Name | Required | Description | Default |
|---|---|---|---|
| after | Yes | The 'after' workflow JSON. | |
| before | Yes | The 'before' workflow JSON. |
| Name | Required | Description |
|---|---|---|
| changes | Yes | Ordered list of semantic differences. |
| summary | Yes | One-line summary of change counts by kind. |
| change_count | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations: it states the tool is deterministic, lists the specific node fields compared, mentions connection topology and settings drift, and explains noise filtering. Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description complements them well with no contradictions.
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?
The description is extremely concise: three short sentences plus a pairing recommendation. It front-loads the core purpose, then details output specifics, noise handling, and a use-case suggestion. Every sentence adds value with no redundancy.
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?
Given that the tool has a high schema coverage (100% for parameters) and an output schema exists, the description is sufficiently complete. It covers purpose, detailed behavior, noise filtering, and a concrete use case. No additional information is needed for the agent to select and invoke the tool correctly.
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?
Schema description coverage is 100%: both parameters ('before' and 'after') have descriptions stating they are workflow JSONs. The tool description does not add additional parameter-specific semantics beyond what the schema provides, so baseline score of 3 is appropriate.
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?
The description clearly and specifically states the tool's purpose: semantic diff between two n8n workflows. It lists exactly what changes are reported (nodes added/removed/modified with field-level deltas, connection topology changes, settings drift) and what is ignored (noise). This distinguishes it from sibling tools like workflow.get, workflow.lint, and workflow.generate.
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?
The description provides explicit usage guidance by suggesting to pair with workflow.get to compare deployed vs local workflows, which helps agents understand when to use this tool. While it does not explicitly state when not to use alternatives, the context from sibling tool names implies appropriate scoping.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a valid n8n workflow JSON from a plain-English description. Handles webhook/schedule/RSS triggers, common action nodes (Slack, Google Sheets, Discord, Gmail, Notion, HTTP), and AI Agent setups (LangChain root agent + chat model + memory + optional HTTP tool, wired with ai_languageModel / ai_memory / ai_tool connections). Returns workflow JSON with unique node IDs, connections, positions, and typeVersion on every node. Output is non-deterministic (random node IDs and webhook paths).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional workflow name. Derived from the first sentence of the description if omitted. | |
| description | Yes | Plain-English workflow description, e.g. 'Stripe webhook -> Slack message + Google Sheets row'. |
| Name | Required | Description |
|---|---|---|
| workflow | Yes | Full n8n workflow JSON (name, nodes, connections, settings, ...). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral traits beyond annotations: non-deterministic output (random node IDs and webhook paths) and specific handled node types. Annotations already indicate read-only and non-destructive, so no contradiction.
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?
Three sentences front-loaded with the core purpose, followed by capability details and a note on non-determinism. No extraneous content.
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?
Given the complexity of workflow generation, the description covers all essential aspects: input format, supported features, output characteristics, and non-determinism. The existence of an output schema reduces the need to detail return values, making this complete.
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?
Schema coverage is 100% and the description adds value by providing an example input for the 'description' parameter and clarifying that 'name' is derived from the first sentence if omitted. This enhances understanding beyond the raw schema.
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?
The description clearly states the tool 'Generate a valid n8n workflow JSON from a plain-English description' and enumerates supported triggers, action nodes, and AI Agent setups, distinguishing it from sibling tools like workflow.create or workflow.lint.
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?
The description implies usage for converting plain-English to workflow JSON, but it does not explicitly contrast with sibling tools like workflow.create or provide when-not scenarios. Still, the purpose is clear enough for most agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single workflow JSON by id from a live n8n instance (requires N8N_API_URL + N8N_API_KEY). Returns the full nodes/connections payload — pair with workflow.lint to audit a deployed workflow.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Workflow ID. |
| Name | Required | Description |
|---|---|---|
| workflow | Yes | Full n8n workflow JSON (name, nodes, connections, settings, ...). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds that it returns full nodes/connections payload and pairs with workflow.lint, beyond annotations (readOnly, idempotent, non-destructive). No contradictions; could mention timeout or auth failure handling.
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?
Two sentences, front-loaded with purpose and requirements. Each sentence adds value: first gives core function and environment, second details return type and suggested pairing.
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?
With output schema present and a single well-documented parameter, the description sufficiently covers behavior. Full context given for a simple retrieval tool.
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?
Schema covers 100% of parameters with clear description for 'id'. Description mentions 'by id' but adds no extra semantic meaning beyond what schema provides. Baseline 3 applies.
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?
Description clearly states it fetches a single workflow by ID, a specific verb+resource pair. Distinguishes from siblings like workflow.list (listing) and workflow.lint (auditing) by mentioning pairing with lint.
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?
Specifies environment prerequisites (N8N_API_URL + N8N_API_KEY) and suggests a use case (pair with workflow.lint). No explicit when-not, but context with siblings implies it's for fetching one workflow by ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lint an n8n workflow JSON. Returns concrete errors and warnings: missing credentials, deprecated node types (Function -> Code, spreadsheetFile -> convertToFile/extractFromFile), broken connections, missing or non-numeric typeVersion, duplicate node names or IDs, AI Agent missing ai_languageModel sub-node, Webhook missing webhookId, IF node still on v1 condition schema, rate-sensitive nodes without retries, Code-node sandbox violations, expression staleness ($('NodeName') referencing missing nodes), manualTrigger in active workflows, disabled-but-wired nodes, empty Set nodes, HTTP method/body mismatches, Schedule trigger DST risk, credential drift, webhook test paths in active workflows. Deterministic, rule-based.
| Name | Required | Description | Default |
|---|---|---|---|
| workflow | Yes | n8n workflow as either a parsed object or a JSON string (will be parsed). |
| Name | Required | Description |
|---|---|---|
| issues | Yes | All lint findings, ordered by node. |
| error_count | Yes | Number of error-severity issues. |
| warning_count | Yes | Number of warning-severity issues. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by specifying that the linting is deterministic and rule-based, and lists many specific checks, providing rich behavioral context.
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?
The description is packed with information but is a single paragraph. It is front-loaded with the main purpose, though it could be slightly more structured with bullet points or sections for readability.
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?
Given the presence of an output schema (though not shown), the description sufficiently explains the return format by listing many error/warning types, making it complete for the tool's complexity.
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?
The single parameter 'workflow' is fully described in the input schema (coverage 100%). The description does not add additional parameter semantics beyond what the schema provides.
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?
The description clearly states it lints an n8n workflow JSON and returns errors/warnings, listing many specific checks. It distinguishes itself from sibling tools, none of which are lint-related.
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?
The description does not explicitly state when to use this tool versus alternatives, such as before activation or during development. It only describes functionality without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List workflows from a live n8n instance (requires N8N_API_URL + N8N_API_KEY env vars). Returns id, name, active, nodeCount, updatedAt, tags. Filter by active, tags, name. Use this when the user asks 'what workflows do I have?' or before workflow.get.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Filter by exact workflow name. | |
| tags | No | Comma-separated tag names to filter by. | |
| limit | No | Page size (n8n default: 100, max: 250). | |
| active | No | Filter by active status. Omit to return both. |
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of workflows returned. |
| workflows | Yes | Summary of each workflow (id, name, active, nodeCount, ...). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=False, so the tool's safety is clear. The description adds the requirement of N8N_API_URL and N8N_API_KEY env vars, which is valuable behavioral context.
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?
Two concise sentences, front-loaded with purpose, no unnecessary words.
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?
Given the simple tool, strong annotations, full schema coverage, and existence of output schema, the description covers prerequisites, filters, and usage context completely.
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?
Schema coverage is 100%, so baseline is 3. The description merely repeats parameter names (active, tags, name) without adding new meaning beyond the schema's descriptions.
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?
The description clearly states it lists workflows from a live n8n instance, specifies return fields (id, name, active, nodeCount, updatedAt, tags), and mentions filters. This distinguishes it from siblings like workflow.get (single workflow).
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?
Explicitly says 'Use this when the user asks 'what workflows do I have?' or before workflow.get,' providing clear context and best-practice usage. Also specifies required environment variables.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.5.0execution.explainexecution.listexecution.replayexecution.timelinen8n_activate_workflown8n_create_workflown8n_explain_executionn8n_generate_workflown8n_get_workflown8n_lint_workflown8n_list_executionsn8n_list_workflowsn8n_scaffold_nodenode.scaffoldworkflow.activateworkflow.createworkflow.diffworkflow.generateworkflow.getworkflow.lintworkflow.listv0.3.0n8n_activate_workflown8n_create_workflown8n_explain_executionn8n_generate_workflown8n_get_workflown8n_lint_workflown8n_list_executionsn8n_list_workflowsn8n_scaffold_nodeEach tool has a distinct purpose within the n8n ecosystem: execution tools focus on debugging and replaying executions, node.scaffold generates custom nodes, and workflow tools cover lifecycle management (create, get, activate, list), generation, diffing, and linting. There is no overlap or ambiguity between the tools.
All tools follow a consistent dot-separated convention of 'domain.action' (e.g., execution.explain, workflow.create). The naming pattern is uniform and predictable, making it easy for an agent to understand the scope of each tool.
With 12 tools, the server is well-scoped for n8n automation workflows. It covers execution diagnostics, workflow CRUD (except delete), code generation, and linting—each tool earns its place without unnecessary bloat.
The toolset covers most core workflows (execution debugging, workflow creation/get/activate/list, generation, linting, node scaffolding) but lacks a delete or update workflow tool. This omission could require agents to implement workarounds for full lifecycle management.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Marketo MCP server for AI. 130 tools to operate Marketo from Claude, Cursor, or ChatGPT.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AutomateLab-tech/n8n-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
