n8n-extending-mcp
Use when you want to expose an n8n workflow as a tool the coding agent can call. Two cases. (1) Wrap n8n API capabilities the MCP doesn't natively expose: folder CRUD, tag rename/delete, instance metadata, credential creation. (2) Expose a general-purpose workflow as an agent tool: a workflow that calls a third-party API, runs business logic, or does any task you want the agent to invoke. Triggers on "expose as MCP tool", "build a tool for my agent", "I need to know X" where X isn't an MCP tool, "create folder", "rename tag", or any capability gap.
- Installs
- 210
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/n8n-io/skills --skill n8n-extending-mcp- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads n8n-extending-mcp automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
n8n Extending MCP
Any n8n workflow with MCP access enabled becomes a tool the coding agent can call by name. Two common cases:
- Wrap n8n capabilities the MCP doesn't expose. The MCP covers workflow CRUD, validation, execution, data tables, credential listing, execution search, folder/project listing, tag listing and attach/detach. Still missing: folder CRUD, tag rename/delete, instance metadata, credential creation. Build a workflow that hits the n8n API and exposes the result as an agent tool.
- Expose a general-purpose workflow as a tool. A workflow that has nothing to do with n8n itself (calls a third-party API, runs internal business logic, looks something up in a private system) can be MCP-callable. Lets the agent invoke real operations during a coding session.
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.
When to reach for this
Case 1 (wrap n8n capability):
- Folder CRUD (create, rename, move, delete): REST API exists, no MCP tool yet.
- Tag rename/delete: the MCP lists tags (
list_tags) and attaches/detaches them (update_workflowaddTags/removeTags, auto-creating unknown names), but can't rename or delete tag entities. REST API exists for those. - Instance metadata (limits, plan info, configured integrations): no MCP tool.
- Credential creation: REST API exists (
POST /credentials), no MCP tool yet. - Any n8n API operation the MCP doesn't natively expose.
Case 2 (general agent tool):
- A recurring agent task you'd rather codify than re-explain (lookup, format, send).
- An action against a system the agent doesn't have direct access to (private API, internal service, third-party integration).
- Anything you want a future session to invoke without re-deriving the implementation.
Don't reach for this for:
- One-off questions, ask the user directly.
- Things the MCP already exposes natively.
Non-negotiables
- Ask the user before building. This creates a workflow on their instance, with credentials. They need to OK it explicitly.
- Credentials via credential, never text field. Same rule as everywhere else in n8n. See
n8n-credentials-and-security.
Protocol
- Search for existing wrappers first.
search_workflows({ tags: ['tool'] })and a capability keyword search. If something matches, use it instead of duplicating. - For case 1, build as a stateless, queryable utility. Takes input, calls n8n's API, returns the result. No side effects. Case 2 may legitimately have side effects (sending, writing); name them in the tool description.
- Offer to edit the agent's context file yourself (CLAUDE.md, AGENTS.md, GEMINI.md, whatever the user's agent reads on session start) to add an entry for the new tool. You have Edit/Write tools, so there's no reason to make the user paste a snippet manually. Ask first since it's their config file, then edit it directly when they say yes.
The pattern, end to end
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.
Common case-1 wrappers (missing MCP capabilities)
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/.
1. Folder management
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? }
2. Instance metadata
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: {...} }
How the agent invokes a tool workflow
The MCP doesn't register each tool-flagged workflow as a separately-named MCP tool. Discovery and invocation are two steps:
- Discover via
search_workflows({ query: '<keyword>' }). Workflows with MCP access on returnavailableInMCP: true. Filter for that. - Invoke via
execute_workflow({ workflowId, inputs }). Read the input schema first withget_workflow_details. TheExecute Workflow Triggerdefines 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-patterns
| 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 |
FAQ
What does the n8n-extending-mcp skill do?
Use when you want to expose an n8n workflow as a tool the coding agent can call. Two cases. (1) Wrap n8n API capabilities the MCP doesn't natively expose: folder CRUD, tag rename/delete, instance metadata, credential creation. (2) Expose a general-purpose workflow as an agent tool: a workflow that calls a third-party API, runs business logic, or does any task you want the agent to invoke. Triggers on "expose as MCP tool", "build a tool for my agent", "I need to know X" where X isn't an MCP tool, "create folder", "rename tag", or any capability gap.
How do I install n8n-extending-mcp?
Run npx skills add https://github.com/n8n-io/skills --skill n8n-extending-mcp in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/n8n-extending-mcp/ (personal) or .claude/skills/n8n-extending-mcp/ (project).
Which AI agents can use n8n-extending-mcp?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is n8n-extending-mcp safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains n8n-extending-mcp?
It is published by n8n-io in n8n-io/skills. It has 210 recorded installs.
More from n8n-io/skills
n8n-workflow-lifecycle-official
n8n-io/skills
Use when starting, designing, organizing, finishing, or shipping an n8n workflow. Covers visual layout (sticky notes), descriptions that capture the why, node names, validation, testing, folders/projects, and publishing. Triggers on createworkflowfromcode, updateworkflow, validateworkflow, publishworkflow, archiveworkflow, "design", "lay out", "organize", "structure", "sticky", "describe this workflow", "ship", "deploy", "publish", "name this workflow", or any folder/project organization request.
n8n-agents-official
n8n-io/skills
Use when the user wants an agent, assistant, or bot in n8n, or is building, editing, testing, publishing, or debugging a first-class n8n Agent. Covers choosing an Agent vs a workflow vs the AI Agent node, the Agent MCP tools (createagent, mutateagent, validateagent, callagent, publishagent, updateagentintegration), Agent config JSON, tools and approvals, skills, sub-agents, model routing, knowledge files, vector stores, memory and sessions, Slack / Telegram / Discord / Linear / n8n Chat channels, scheduled tasks, the Message an Agent node, and reading Agent sessions and traces. Triggers on "build me an agent", "assistant", "chatbot", "Slack bot", "Telegram bot", "agent skills", "sub-agent", "knowledge base", "agent memory", "session", "Message an Agent", "publish the agent", or any Agent tool call.
n8n-debugging-official
n8n-io/skills
Use when an n8n workflow isn't working, errors appear, results don't match what was expected, or the user says "this isn't working." Triggers on errors, unexpected output, "it's not working", "why is this happening", "the workflow stopped", failure investigation, or any debugging context.
n8n-error-handling-official
n8n-io/skills
Use when building any webhook-triggered workflow, scheduled/production-bound workflow, wiring a per-node error output, or any workflow where silent failure would drop user-visible work. Triggers on "webhook", "respond to webhook", "API", "production", "error", "failure", "5xx", "try/catch", "error workflow", "onError", "continueErrorOutput", "error branch", "node error output", "output(1)", "main[1]", "scheduled", or any workflow that runs unattended.
n8n-credentials-and-security-official
n8n-io/skills
Use when handling any auth, API keys, tokens, OAuth, bearer tokens, basic auth, or secret values in n8n workflows. Triggers on "API key", "token", "bearer", "OAuth", "secret", "auth", "credentials", "Authorization header", "x-api-key", or any node configuration that mentions a third-party service.
n8n-code-nodes-official
n8n-io/skills
Use when the user reaches for a Code node, mentions writing JavaScript or Python in n8n, or any custom logic comes up in workflow design. Triggers on "Code node", "Code", "JavaScript", "Python", "custom logic", "transform data", "$input", "$json transformation", "loop in code", "write a function", or any time the obvious answer seems to be "just put it in code."
Popular ai & agents skills
google-agents-cli-publish
google/agents-cli
This skill should be used when the user wants to "publish an agent", "publish my ADK agent", "register an agent with Gemini", "publish to Gemini" (formerly Gemini Enterprise), or needs guidance on the agents-cli publish gemini command. Also use when the user wants to "manage agents in Agent Registry", "list/update/delete registered agents", or "register an MCP server". Covers ADK vs A2A registration modes, programmatic and interactive usage, flag reference, auto-detection from deployment metadata, Agent Registry fleet management, and troubleshooting. Part of the agents-cli skills suite. Do NOT use for deployment (use google-agents-cli-deploy).
google-agents-cli-eval
google/agents-cli
This skill should be used when the user wants to "run an evaluation", "evaluate my agent", "evaluate my ADK agent", "write an eval dataset", "analyze eval failures", "compare eval results", "optimize agent", or needs guidance on the Gemini platform eval methodology and the Quality Flywheel. Covers eval metrics, dataset schema, LLM-as-judge scoring, and common failure causes. Applies to any agents-cli project, whatever framework the agent is written in. Do NOT use for agent API code patterns (ADK: use google-agents-cli-adk-code), deployment (use google-agents-cli-deploy), or project scaffolding (use google-agents-cli-scaffold).
skill-creator
anthropics/skills
Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.
codex-pet
prime-skills/runcomfy-agent-skills
Codex Pet generator on RunComfy. Build a Codex-compatible Codex Pet spritesheet.webp + pet.json from a single reference image, drop it into ${CODEXHOME:-$HOME/.codex}/pets/ / and Codex picks it up as a custom Codex Pet next to the 8 built-ins. This skill produces the exact Codex Pet atlas Codex expects (1536x1872 PNG/WebP, 8 cols x 9 rows, 192x208 cells, 9 animation states — idle, running-right, running-left, waving, jumping, failed, waiting, running, review). Calls OpenAI GPT Image 2 edit ONCE via the local RunComfy CLI as runcomfy run openai/gpt-image-2/edit to produce a canonical Codex Pet pose, then assembles all 9 animation rows programmatically with ImageMagick micro-transforms — no Codex Pro, no $imagegen, no OPENAIAPIKEY required, only RUNCOMFYTOKEN. Triggers on "codex pet", "create codex pet", "make codex pet", "hatch codex pet", "/hatch image", "desktop pet codex", "codex pets", "spritesheet.webp", or any explicit ask to build a custom pet for OpenAI Codex.
full-output-enforcement
leonxlnx/taste-skill
Overrides default LLM truncation behavior. Enforces complete code generation, bans placeholder patterns, and handles token-limit splits cleanly. Apply to any task requiring exhaustive, unabridged output.
executing-plans
obra/superpowers
Use when executing an implementation plan in the current session as the implementer yourself — your human partner chose inline execution, or no subagent tool is available