Using n8n Skills

The official n8n MCP evolves over time, so tool names, parameters, and default behaviors can drift between versions. When you spot drift (a tool a skill names doesn't exist, a parameter shape doesn't match what get_node_types returns, or behavior differs from what the skill describes), suggest updating the skill and n8n instance to the latest stable.

Non-negotiables

Three rules with no exceptions. Violating any produces workflows that look right but break in production.

1. Invoke the relevant skill before any n8n action. Not just MCP tool calls. Before writing SDK code, configuring a node, designing a workflow, wiring a connection, building an agent, or handling errors: invoke the matching skill via the Skill tool. This document is a router. The skill body has the actual rules. The PreToolUse hooks remind you on the highest-impact MCP calls if a plugin is installed. The responsibility is yours on everything else. Err on the side of reading extra documents.
2. Validate AND verify before publishing. validate_workflow before publish_workflow, and get_workflow_details after every create or update to check the connections object. Validation alone misses many issues documented in the skills that will silently break workflows.
3. Tokens/secrets never go in text fields. Always use the n8n credential system. If no native node exists, configure HTTP Request with the official credential type. See n8n-credentials-and-security.

Strong defaults (each skill owns its exceptions)

• The Code node is a last resort. Expression first, then arrow function inside Edit Fields, then Code. Code earns its place for multi-source aggregation, libraries, and stateful work. See n8n-code-nodes.
• Anything reusable becomes a stateless sub-workflow. Search existing ones via search_workflows({ query: 'Subworkflow' }) before building. See n8n-subworkflows.

Red flags: thoughts that mean STOP and invoke