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 create/rename/move and folder/project listing, tag listing and attach/detach. Still missing: folder deletion, project create/rename, 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 delete, and project create/rename: no MCP tool. Folder create/rename/move and moving workflows between folders now have MCP tools (
create_folder,update_folder,move_workflows_to_folder), on a registered instance; delete still needs the REST API. - Tag rename/delete: the MCP lists tags (
list_workflow_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-official.
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
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 delete and project management
The MCP now creates, renames, and moves folders natively (create_folder, update_folder, move_workflows_to_folder), so those no longer need wrapping. Still missing: deleting a folder, and creating/renaming projects. n8n's REST API covers both (Folders endpoint), so a one-time wrap fills the gap.
2. Instance metadata
Version, configured integrations, environment info. Useful for the SessionStart drift check or adapting workflows to instance capabilities.
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.


