n8n's instance-level MCP server: letting Claude Desktop or Cursor build your workflows

Since the release of its MCP Server Trigger node, n8n already let you expose a workflow you had built as an MCP tool callable from the outside — we cover how that works in our MCP in n8n guide. What n8n added next is a different kind of feature: an instance-level MCP server that lets a client like Claude Desktop, Cursor, or ChatGPT create, edit, and run your workflows directly inside your editor, in plain language. You no longer describe a tool to expose — you describe the workflow you want, and the AI builds the nodes itself. This guide covers activation, authentication, what the AI can actually do — and the precautions worth taking before granting it that level of access.

Three MCP features, three distinct uses

With this instance-level server, n8n now lines up three different MCP building blocks, and it's easy to mix them up:

Feature	What it does	Who benefits
MCP Client Tool	An n8n AI Agent consumes tools from a third-party MCP server	The workflow itself, internally
MCP Server Trigger	An n8n workflow becomes a single MCP tool	An external client, for one specific purpose
Instance-level MCP server	An external client drives the entire n8n editor (create, edit, run workflows)	You, while building

The first two are covered in detail in our MCP in n8n guide and in our article on the quick connection to official MCP servers. This one focuses on the third: n8n as an instance an AI can drive, not as a building block inside a single workflow.

What the instance-level MCP server actually lets you do

Once connected, an MCP client gets a set of tools that cover most of a workflow's lifecycle:

• Create and edit workflows — edits happen as a batch of targeted, atomic operations: if one operation fails, none of them apply, which avoids leaving a workflow in a half-fixed state.
• Search existing workflows on the instance, with a preview of each (up to 200 results), so the AI knows what already exists before creating a duplicate.
• Run a test execution and read the result — the AI can trigger the workflow, observe the returned error, fix it, and retry, without you having to copy-paste the error message yourself.
• Activate or deactivate a workflow, manage its tags.
• Read the schema of available credentials (not their values) to know which credential type to wire into which node.
• Track, retry, or delete past executions.

In practice, this reproduces the loop a developer follows by hand in the editor — build, test, read the error, fix — except it's driven by a language model instead of your clicks.

Enabling the MCP server in the instance settings

Activation happens under Settings > Instance-level MCP. On n8n Cloud, the option is available directly in the UI. Self-hosted, there are two paths:

• On an up-to-date instance, the setting also appears in Settings, to enable manually.
• From version 2.20.0 onward, a dedicated environment variable (N8N_MCP_ACCESS_ENABLED=true) lets you enable it without going through the UI — useful for a scripted deployment or one managed through Docker Compose, in line with what our n8n environment variables to know guide covers.

n8n recommends version 2.18.4 or higher for a reliable building experience; on an older instance, update first before looking for the option — our guide on updating n8n under Docker without breaking anything walks through doing that safely.

Authentication: personal token or OAuth2

Once the option is enabled, a "Connection details" button opens the connection settings. Two authentication methods are offered on the client side:

1. Personal access token — on your first visit to the Access Token tab, n8n generates one automatically, tied to your user account. It's only shown in plain text once: copy it right away, since later visits only show a redacted value and the copy button is disabled.
2. OAuth2 — for a full authorization flow, better suited to a shared team setup where each user needs to keep their own identity on the n8n side.

This token carries the same rights as your account: treat it with the same rigor as an n8n API key or any sensitive n8n credential — never pasted into a shared prompt, a ticket, or a public repo.

On the transport side, the instance-level MCP server only works over remote HTTP: neither stdio nor SSE. Your MCP client therefore needs to support connecting to a remote MCP server over HTTP — true of Claude Desktop, Cursor, ChatGPT, and most recent clients, but check your own client's documentation if it's an older tool or a custom integration.

A concrete example

Take a typical case: you want a first draft of a workflow that reads an IMAP inbox, categorizes each incoming email with an LLM, and pushes urgent ones to Slack — the same logic covered in our AI email triage in n8n guide. Connected to your development instance's MCP server, a client like Claude Desktop can:

1. Search whether a similar workflow already exists on the instance, to avoid a duplicate.
2. Create the workflow: an Email (IMAP) trigger, an AI classification node, a conditional branch, a Slack notification.
3. Run a test execution against a real email, read the returned error (a misconfigured credential field, say), fix it, and retry — until it gets a passing run.
4. Leave the workflow deactivated, ready for your review before activation.

What you get isn't a finished, production-ready workflow, but a working first draft that would normally take an hour of manual setup. The real gain is on drafting and repetitive debugging — much less on final reliability, which remains your responsibility.

Limits and precautions worth knowing

Giving an MCP client the ability to create, edit, and activate workflows on your instance deserves the same caution as any write access to a production system.

Don't connect this server to your production instance by default. Nothing on the MCP server's side distinguishes a test instance from a critical one: an agent that activates a workflow does so without extra confirmation as long as the token allows it. Prefer a dedicated development instance — the pattern covered in our dev/prod separation in n8n guide — and only promote an AI-generated workflow to production after human review.

Review the generated workflow before activating it, especially the credentials it expects and any hard-coded values. A study by Hammond Pearce and co-authors, Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions (IEEE S&P 2022), found that a significant share of AI-assistant-generated code contains identifiable security weaknesses (close to 40% across their test scenarios) when left unreviewed — a finding that applies just as much to an automatically generated n8n workflow as to regular application code.

Don't let the self-correction loop replace your own vigilance. The fact that an agent can test, read the error, and fix itself creates an impression of reliability that can be misleading: Raja Parasuraman and Dietrich Manzey document, in Complacency and Bias in Human Use of Automation: An Attentional Integration (Human Factors, 2010), how excessive trust in an automated system that "fixes itself" reduces human vigilance toward the errors it doesn't catch on its own — typically incorrect business logic that a workflow runs without throwing a technical error.

Finally, keep in mind that the MCP server reads the schema of available credentials, not their content — it can't exfiltrate an existing API key, but a compromised token could still create a workflow that itself exfiltrates data through a maliciously configured HTTP node. Per-user permission granularity remains your first line of defense.

Going further

The instance-level MCP server speeds up the drafting phase, not the design work: a sensitive business workflow — urgency triage, compliance, audit — is better off starting from an already-proven base than from a first draft generated mid-conversation. That's exactly what our packs cover: the Inbox AI Pack (€79) for AI email triage, the Compliance & Audit Pack (€149) for the audit trail and compliance evidence, and the Complete FlowKit Bundle (€269) if you want all three building blocks (Inbox, RAG, Compliance) on workflows that are already tested rather than rebuilding everything through MCP. Use the instance-level MCP server to explore and prototype fast; keep critical workflows on a validated base.