From n8n-skills
Exposes n8n workflows as MCP tools for coding agents. Wraps n8n API gaps (folder/tag CRUD, instance metadata, credential creation) and turns general workflows into agent tools.
How this skill is triggered — by the user, by Claude, or both
Slash command
/n8n-skills:n8n-extending-mcpThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
<!-- TEMPORARY: update whenever n8n mcp capacities are added. a lot of listed functionalities missing are coming soon -->
Any n8n workflow with MCP access enabled becomes a tool the coding agent can call by name. Two common cases:
The MCP calls your workflow as if it were a native tool: input from the Execute Workflow Trigger, output from the workflow's last node.
Case 1 (wrap n8n capability):
POST /credentials), no MCP tool yet.Case 2 (general agent tool):
Don't reach for this for:
n8n-credentials-and-security.search_workflows({ query: 'Tool:' }) and a capability keyword search. If something matches, use it instead of duplicating.1. User asks for a capability (missing MCP feature, or a workflow they want
the agent to be able to invoke).
2. You: "I can build a workflow that exposes this as a tool the MCP can call.
Want me to create it?"
3. User: yes.
4. You build the workflow:
- Trigger: Execute Workflow Trigger with declared inputs.
- Body: whatever logic the tool needs (HTTP Request to n8n's API, a
third-party call, internal computation).
- Output: structured response.
5. Validate, test, publish.
6. Ask the user if you can add an entry for this tool to their agent context
file (CLAUDE.md / AGENTS.md / etc.) so future sessions know to search for
it by name. Edit the file directly when they say yes.
7. The workflow is immediately callable: agent-created workflows have `availableInMCP: true` set by default.
Most common patterns, by usefulness. Case 2 (general agent tools) is whatever your project needs, no canonical examples.
n8n REST API reference: https://docs.n8n.io/api/api-reference/. Start here for any case-1 wrap. Find the endpoint, then wrap it with an HTTP Request node +
n8nApicredential. Self-hosted instances expose this at<instance-url>/api/v1/.
The MCP can place workflows into existing folders but can't create, rename, move, or delete them. n8n's REST API has a Folders endpoint, so a one-time wrap solves this for users who organize folders frequently.
Tool: create folder
Input: { projectId: string, name: string, parentFolderId?: string }
Output: { id, name, projectId, parentFolderId? }
Version, configured integrations, environment info. Useful for the SessionStart drift check or adapting workflows to instance capabilities.
Tool: get instance info
Input: {}
Output: { version, edition, integrations: [...], limits: {...} }
The MCP doesn't register each tool-flagged workflow as a separately-named MCP tool. Discovery and invocation are two steps:
search_workflows({ query: '<keyword>' }). Workflows with MCP access on return availableInMCP: true. Filter for that.execute_workflow({ workflowId, inputs }). Read the input schema first with get_workflow_details. The Execute Workflow Trigger defines typed fields.Output is whatever the workflow's last node returns.
MCP access defaults: Agent-created workflows default to availableInMCP: true. UI-created workflows may default off, in which case the user has to toggle MCP access on in the workflow's settings before it appears in search results. Either way, the user can flip it off later to restrict access.
This is why the agent-context-file snippet (CLAUDE.md / AGENTS.md / etc.) matters. Future sessions don't auto-enumerate tool workflows. The snippet tells them the tool exists by name, so they search for it instead of re-deriving the implementation.
| Anti-pattern | What goes wrong | Fix |
|---|---|---|
| Building an MCP-extension workflow without asking the user | Surprise creation of workflows on their instance with credentials | Always ask permission first |
| Not documenting the new tool in the agent's context file | Future sessions don't auto-enumerate tool workflows. Without a hint they'll re-derive the implementation. | Ask the user, then edit CLAUDE.md / AGENTS.md / whichever file their agent reads, directly. Don't make them paste a snippet. |
| Hardcoding the n8n API token in the HTTP Request node | Token leak when the workflow is exported or copied | Use a credential of type n8nApi or appropriate header auth |
| Side-effecting tool with no mention of side effects in its name/description | Agent invokes thinking it's a read, ends up sending real messages or writing real data | Name and describe the side effect explicitly (e.g., Tool: send Slack message). Read-only is the safer default for case-1 wrappers. |
| Wrapper that does bulk or destructive ops (archive, delete) with no dry-run | One bug touches many workflows | Strong explicit opt-in per call, plus a dry-run mode that lists targets without acting |
| Wrapper returns credential values | Token leak via tool output | Return IDs, names, types only. Never the secret. |
| Skipping the validate + verify + test cycle on the wrapper | The "tool" itself is broken, manifests as confusing tool-not-found or empty-response errors | Same lifecycle as any workflow: see n8n-workflow-lifecycle |
npx claudepluginhub n8n-io/skills --plugin n8n-skillsGuides use of n8n-mcp tools for node search, config validation, workflow CRUD, credential management, and security auditing. Consult before calling any n8n-mcp tool.
Guides n8n-mcp tool usage for node discovery, config validation, workflow management, and template deployment. Covers selection workflows, parameters, nodeType formats, and patterns.
Guides effective use of n8n-mcp MCP tools for node discovery, configuration validation, workflow management, and template deployment.