/using-n8n-mcp-skills

name: using-n8n-mcp-skills
description: "Use when building, editing, validating, testing, or debugging an n8n workflow through the n8n-mcp MCP server — designing a flow, configuring a node, writing an expression or Code node, wiring credentials, or fixing one that misbehaves. The entry-point skill for the n8n-mcp-skills pack: it routes you to the right specialist skill, gives working knowledge of every n8n-mcp tool from turn one, and states the rules that keep workflows from breaking in production. Always consult it first on any n8n, workflow, node, or automation task — even a quick one-off, and even when the user names no skill — because n8n's surface drifts between versions and the specialist skills prevent silent failures."

Using the n8n-mcp Skills

This is a **router**, not a reference. It tells you which skill owns the rules for what you're about to do. The skill bodies hold the actual guidance — invoke them with the Skill tool. When in doubt, load more skills rather than fewer.

The community **n8n-mcp** server and n8n itself move faster than any model's training cutoff. Tool names, parameters, node `typeVersion`s, and default behaviors drift between releases. When you spot drift — a tool a skill names doesn't exist, a parameter shape doesn't match what `get_node` returns, behavior differs from what a skill describes — trust the **live tool**, tell the user, and suggest updating the pack and the instance.

Non-negotiables

Three rules with no exceptions. Each one prevents a class of workflow that looks correct but breaks in production.

1. **Invoke the relevant skill before any n8n action** — not just before MCP calls. Before writing an expression, configuring a node, designing a workflow, wiring a connection, or writing Code, invoke the matching skill. PreToolUse hooks remind you on the highest-impact tool calls, but they exist **only in the Claude Code plugin install**. Everywhere else — Claude.ai skill uploads, and any client that loads this pack as an Agent Plugin (Codex, Cursor, Copilot and the rest) — nothing nudges you and it's on you. Assume you are un-hooked unless you have seen a hook fire this session. 2. **Validate AND verify before activating.** Run `validate_workflow` (or `n8n_validate_workflow` by id) before you activate, and call `n8n_get_workflow` after every create or update to inspect the `connections` object. Validation alone misses silently dropped wires, Merge index off-by-one, and error outputs that were never wired. Validation passing means the JSON is well-formed — not that the workflow is correct. A green test run isn't proof either: JS errors inside `{{ }}` resolve silently to `null` (a Filter with a broken condition drops every item and still shows success), so inspect the output values. See `n8n-expression-syntax`. 3. **Secrets never go in text fields.** Tokens, API keys, and passwords always go through the n8n credential system. If no native node exists, use the HTTP Request node with the official credential type. A Set node holding a token referenced via `{{ $json.token }}` is a leak with extra steps. See `n8n-mcp-tools-expert`.

Lean on skills, not training data

n8n changes constantly. "Remembered" parameter names are often silently wrong — they validate as plain strings and then do nothing at runtime. If a skill contradicts your memory, trust the skill. If `get_node` contradicts a skill, trust the tool and flag the drift.

Strong defaults

These are the defaults; the Code exceptions below are a closed list.

**Native node first, Code last.** Pick in this order: the service's own node (HTTP Request only when no node covers the operation), then a native node for the job, then a short expression inside that node, then Code. A function body or several statements inside `{{ }}` is code: it belongs in a Code node.

| Job | Use | |---|---| | Flag that only picks a route; dropping items | conditions in IF / Switch / Filter | | Constant, error or return item | Edit Fields (Set) | | Restore earlier context | `$('Node').item` | | Pick rows after a Data Table get | the get's order by + limit | | Group and sum | Summarize | | Items to one array / array to items | Aggregate / Split Out | | Join two lists | Merge (combine by fields) | | Diff or sync two lists | Compare Datasets | | Dedupe, also across runs | Remove Duplicates | | Top-N | Sort + Limit | | Dates | Date & Time, or a Luxon one-liner | | XML / HTML / Markdown / CSV / XLSX | XML, HTML, Markdown, Extract From File / Convert To File | | Paging an API (no service node) | HTTP Request's pagination option | | Throttle calls | HTTP Request's batching option, or Loop + Wait | | Hash, HMAC, UUID | Crypto (+ Webhook raw body) |

Code is right only for: loops or recursion no node expresses, state across runs, parsing no node handles, libraries, heavy all-items work on queue-mode workers (thousands of items, stated or measured), or one short Code node (~15 lines) replacing 4+ glue nodes that only reshape data. Every Code or HTTP Request node that stays gets the note `Why Code: <native node considered> — <reason>` (or `Why HTTP:`). See `n8n-node-configuration` and `n8n-code-javascript`.

• **A Set that only re-maps fields for the next node is the antipattern.** Put those

expressions in the next node. Edit Fields as a named step is fine. See `n8n-expression-syntax`.

• **Per-item iteration is automatic.** Don't add a Loop Over Items node to "make it loop"

when default per-item execution already handles the case.

• **Configure from the live schema, never from memory.** `get_node` before you set

parameters. See `n8n-node-configuration`.

Red flags: "about to ___" → invoke ___

If you catch yourself thinking any of these, stop and invoke the named skill first.

| Thought | Invoke | |---|---| | "This workflow is simple, I'll just build it" | `n8n-workflow-patterns` — most "simple" flows ship at 10+ nodes | | "I'll add a Set node to map these