4. MCP for building workflows against non-prod environments

Description

By the end of this lesson you will be able to let an AI assistant —Claude, ChatGPT, Cursor— build and edit workflows inside your n8n instance, through the MCP server, always pointing it at a non-prod environment —dev, never production. You're going to understand what MCP is, how the instance-level server gets enabled, and —most important— the safe loop turning an AI into a collaborator instead of a risk: the AI proposes in dev, Git records the change, the human reviews the diff, and only then does it get promoted. You're going to see why the isolated environments you set up in Module 4 are exactly the safety net making all of this possible.

This matters because it changes how workflows get built, and the change is already here, not in the future. An AI can put together in minutes a workflow that would take you an hour by hand. It's an enormous productivity lever, and also a new way to break production if you use it without discipline. The difference between the two isn't in the AI —the same tool can be an accelerator or a disaster— it's in which environment you point it at and what process you put between what the AI does and what reaches Cumbre's real orders. This lesson gives you that environment and that process.

Connection to the module: lesson 3 taught you to review a change's diff, whether it comes from a person or an AI. This lesson shows you where the AI change comes from: n8n's MCP server. It's the missing piece to close the loop. The AI builds (this lesson), Git records and the human reviews the diff (lesson 3), it gets promoted (lesson 2), and, if something goes wrong, it gets reverted (lesson 5). The principle this lesson installs —never let an AI build directly in prod— rests entirely on Module 4's isolated environments: without them, there'd be no safe dev to let the AI loose in. Everything you did before was building the net; this lesson is where you use it.

About what I can confirm and what you have to check. n8n's MCP server is one of the fastest-evolving areas of the whole product: it changed significantly between minor versions during 2026. Everything I present in this lesson as concrete syntax —environment variable names, the endpoint's URL, a client's configuration— I confirmed against n8n's official docs as of July 2026, and I'll tell you when. Even so, adopt the usual habit: before trusting a concrete MCP fact, check it against your version's documentation and your own instance's interface. This lesson's principle —AI builds in non-prod, human reviews, gets promoted— is stable and isn't going to change; the configuration details might move. When something doesn't match what you see in your n8n, your instance rules.

What MCP is, in plain words

Let's start with the name, because it sounds more intimidating than it is.

MCP stands for Model Context Protocol. It's an open standard defining a common way for an AI assistant to connect to an external tool and use it. Think of it as a shared language: before MCP, every AI talked to every tool its own way, and connecting one to another was custom work. MCP is the "let's all speak the same language" agreement, so any AI speaking it can use any tool speaking it, with no special translation.

The useful analogy is a standard port. Before, every device came with its own charger with its own plug shape, and you needed each one's exact charger. When the industry agreed on a single port —one same connector for everything— any charger works for any device. MCP is that single port between AI assistants and tools: n8n "exposes an MCP port," and any AI speaking MCP —Claude, ChatGPT, Cursor, Windsurf— can plug into it.

What does MCP give the AI regarding your n8n? The ability to do things inside your instance, not just talk about them. Without MCP, you can ask an AI "write me a workflow's JSON" and it pastes it into the chat, but you're the one who imports it into n8n by hand. With n8n's MCP server enabled, the AI can search your workflows, create them, edit them, and run them directly on your instance, with no copying and pasting. The AI stops being an outside advisor and starts having hands inside your n8n.

And that's exactly where both the power and the danger lie. Hands inside your instance are wonderful when that instance is dev, where breaking costs nothing. It's terrifying when it's prod, where breaking costs real orders. This whole lesson revolves around that distinction.

n8n's instance-level MCP server

n8n 2.0 ships its own MCP server, built into the instance. Let's go over what it is and what it does, with facts confirmed as of July 2026.

An MCP server is the "tool" side of the connection: the one exposing the capabilities for an AI (the "client" side) to use. When you enable n8n's MCP server, your instance starts offering a set of tools an AI assistant can invoke: searching workflows, creating them, editing them, running them, reading their execution data. n8n's docs confirm that, from version 2.13 onward, that set includes creating and editing workflows —not just running them, which was all you could do at the start.

Three facts worth being clear on, confirmed against the official docs:

It's in every edition, free included. The MCP server comes built into Cloud, Enterprise, and the free self-hosted Community edition. It isn't a paid feature. This fits the guide's spirit: you can do all of this at zero cost.

It gets enabled at the instance level and per workflow. There are two switches. First you enable the server for the whole instance; then you mark each workflow you want the AI to be able to see or touch as "available in MCP." A workflow you didn't mark, the AI doesn't see. It's a deliberate n8n decision: the AI doesn't have access to everything by default, only to what you exposed.

Access is per user, not per client. Here there's a security nuance the docs explicitly flag and that's worth locking in: access is tied to your user, and it isn't separated per AI client. That means every AI client you connect to your account sees every workflow you marked as available in MCP. You can't give Claude access to one workflow and Cursor to a different one; both see whatever you exposed. This reinforces why the environment matters so much: if you connect the AI to prod, any client you use sees and potentially touches the production workflows.

How it gets enabled (the details you need to check)

Here are the concrete facts, with the usual warning: confirm them on your version, because this area moves fast.

In the interface. The server gets enabled from the instance's settings, in the instance-level MCP section (Instance-level MCP), with an "Enable MCP access" switch. It requires instance owner or admin permissions. This is the recommended route for starting, because it shows you on screen what you're enabling.

With environment variables (self-hosted). If you manage your n8n with Docker —this guide's case— you can control the MCP server with environment variables, which fits your per-environment setup from Module 4. Confirmed as of July 2026:

# Enable MCP access on this instance (from n8n v2.20.0)
N8N_MCP_ACCESS_ENABLED=true

# Optional: lock the setting via environment variable and block changing it from the UI
N8N_MCP_MANAGED_BY_ENV=true

# To fully disable the MCP module (removes endpoints and hides the UI)
N8N_DISABLED_MODULES=mcp

Notice the gem this gives your per-environment setup: you can enable MCP in dev and leave it off in prod, controlling it from each one's environment file. In dev's docker-compose, you put N8N_MCP_ACCESS_ENABLED=true; in prod's, you put N8N_DISABLED_MODULES=mcp so the module doesn't even exist. With that, the AI can't build in production even if someone tries by mistake: the endpoint isn't there. Module 4's environment separation becomes the lock making the worst accident impossible. This is exactly the kind of net this lesson wants you to install.

The endpoint. When the server is active, it exposes an HTTP endpoint. Confirmed as of July 2026, it looks like this:

https://<your-n8n-domain>/mcp-server/http

That's the URL you give your AI client to connect to. For authentication, n8n offers two paths: OAuth2 (you authorize access from n8n) or a personal MCP access token (a Bearer token tied to your user, which n8n generates when you visit the MCP access page). Again: check the exact path and mechanism on your version.

Connecting an AI client (illustrative example)

To close the picture, this is what connecting Claude Desktop to your dev's MCP server looks like, using the access token. Take it as an illustration of the mechanism, not a recipe to copy without checking, because each client's exact configuration changes with its versions:

{
  "mcpServers": {
    "n8n-dev": {
      "command": "npx",
      "args": [
        "-y", "supergateway", "--streamableHttp",
        "https://dev.cumbre.example/mcp-server/http",
        "--header", "Authorization:Bearer <YOUR_DEV_MCP_TOKEN>"
      ]
    }
  }
}

Read the pieces: the name n8n-dev makes it explicit, right in the configuration itself, that this client points at dev —a good habit, naming the environment so you don't get confused— the URL ends in dev.cumbre.example, the development instance, not the production one; and the token is your user's in dev. Each of those three pieces is a chance to point at prod by mistake, and each has to point at dev on purpose.

With Claude Code, the connection is made via command instead of a file, in the form claude mcp add --transport http n8n-dev https://dev.cumbre.example/mcp-server/http. And other clients —ChatGPT, Cursor, Windsurf— follow similar patterns: an endpoint URL and a credential. What doesn't change between clients is what matters: the URL points at dev.

The non-negotiable principle: never directly in prod

Everything above is mechanics. This is the lesson's heart, and if you take away one thing, let it be this: an AI never builds or edits directly in production.

The reason is a combination of two things you already know, and that together are dangerous.

First, remember from lesson 3 how the AI works: in a self-correcting loop. n8n's docs describe it proudly: the AI generates the workflow, validates it, runs it —generating test data if needed— reads the error if something fails, corrects itself, and tries again. It's autonomous: there's no human between one iteration and the next. That's wonderful for building fast. But read it again with production eyes: "runs it." If that loop runs in prod, the AI is running workflows against real data as part of its build process —sending test orders to Cumbre's real CRM, triggering effects that can't be undone— without anyone having approved it.

Second, remember the AI doesn't understand business consequences. It can produce a technically valid change that's a disaster for Cumbre, and its self-correction loop wouldn't catch it, because to the AI "it works" means "the JSON is valid and runs with no error," not "it's a good idea for the business."

Put the two together: an AI that runs things as part of building, and that doesn't judge the consequences, running in the environment where the effects are real and irreversible. It's a recipe for an accident. That's why the principle admits no exception: the AI builds in dev. There, its self-correction loop can run everything it wants, because dev uses synthetic data and test credentials (Module 5): if the AI sends a hundred test orders to the sandbox CRM, nothing happens. In prod, those same hundred orders would be a hundred real records in Cumbre's CRM.

Notice that the AI's self-correction loop isn't human review. They're two different things and both are needed. The AI's loop makes sure the workflow works technically; human review makes sure the change is right for the business and hides no surprises. The AI doesn't replace the human who reviews; it builds faster what the human reviews afterward. The day you confuse "the AI validated it" with "it's reviewed," you skipped the step that matters most.

The complete safe loop

Let's put the whole module together in the loop making the AI a safe collaborator. This is the picture summing up lessons 2, 3, and 4:

  1. the AI builds          2. you export          3. Git records
     in dev  (via MCP)  →      and commit     →       the change
     its loop self-            the workflow            (a version
     corrects, runs            the AI touched          with date and reason)
     against test data
            │                                              │
            │                                              ▼
            │                                    4. the human reviews
            │                                       the DIFF (lesson 3):
            │                                       does it do what it says?
            │                                       anything unexpected?
            │                                              │
            ▼                                              ▼
  6. runs in prod  ◄──── 5. it gets promoted ◄──── approved in a
     (Module 5 tested,     to staging and             pull request
      lesson 2 promoted)   to prod (lesson 2)

Walk through it. The AI does its work in dev, where its autonomy is safe because there's nothing real to break (1). You take what it did and put it under version control (2, 3), which turns "the AI touched something" into "there's a change recorded with its diff." A human reads that diff and approves or rejects it (4) —this is the point where business judgment enters, the one the AI lacks. Only what's approved gets promoted (5), passing through staging's test (Module 5) before reaching prod (6).

In that loop, the AI is fast and powerful at step 1, and it doesn't touch any other step. It doesn't commit on its own without you looking, it doesn't approve its own diff, it doesn't promote to production. Every one of those steps has a human or a check in the middle. That's the operational definition of "the AI proposes, the human decides": the AI proposes at step 1, and the human decides at step 4. Everything else is the machinery safely connecting the two.

Why Module 4's isolated environments are the net

It's worth being explicit about a debt of gratitude to Module 4, because without it this lesson would be reckless.

The reason you can let an AI loose to build with its autonomous loop is that the environment you let it loose in —dev— is truly isolated. It isn't "another browser tab"; it's a separate n8n instance, with its own database, its own test credentials, and its own synthetic data, brought up with its own Docker Compose. When the AI runs a workflow there as part of its self-correction, it runs against the sandbox CRM, not the real one. Isolation is what turns the AI's autonomy from a danger into a convenience.

Think of it as a flight simulator. A pilot in training can crash the plane a hundred times in the simulator and learn from every crash, because the simulator is isolated from the real sky: nobody dies in a simulator. That same pilot, practicing risky maneuvers in a real plane full of passengers, would be criminally reckless. dev is the AI's simulator: it can "crash" workflows as much as its self-correction loop needs, because it's disconnected from the real consequences. prod is the real sky with passengers. The AI flies in the simulator; the human decides which tested maneuver moves to the real plane.

That's why this guide's order makes sense: first version (Modules 2-3), then isolate environments (Module 4), then test in sandbox (Module 5), and only now let the AI loose. Each previous module built a piece of the net. Trying to use the AI to build workflows before having isolated environments would be like putting the rookie pilot in the real plane: the tool is the same, but without the net, it's dangerous.

Limits and permissions: worth keeping in mind

Let's close with an honest list of limits and precautions, some confirmed in the docs and others good general judgment. Check the specifics on your version.

• Access isn't separated per client. As we saw, every AI client you connect sees every workflow you marked as available in MCP. There's no fine-grained "this client sees this workflow" permission. Treat it accordingly: whatever you expose in MCP, you expose to any client connected to your account.
• Only mark in MCP what the AI needs to touch. Don't expose every workflow "just in case." Mark as available in MCP only the ones you're currently building or editing with AI, in dev. Less exposed surface, less that can go wrong.
• Execution has modes. The docs note most MCP tools work on unpublished workflows, and that the execution one has a default mode and a manual one. Don't rely on remembering this from memory: check which mode the AI runs in before connecting it to something you care about, and do it in dev where the mode causes no harm.
• You can revoke access. Connected clients show up in a settings tab, and you can revoke any of them. If you're no longer using some client, revoke it: an open connection you don't use is risk surface with no benefit.
• The human remains responsible. No MCP setting removes your responsibility for what reaches prod. The AI builds; you answer for what you promoted. That split doesn't change with any configuration.

The conclusion from all these limits points at the same thing: the safety of using AI on your instance doesn't come from MCP's fine-grained permissions —which today are coarse— it comes from the process you put around it. Point the AI at dev, expose only what's needed, review every diff, promote only what's approved. The process is the safety; MCP's configuration is just the first lock.

Common mistakes

Connecting the AI to the production instance (conceptual and security, the serious mistake). What happens: someone enables the MCP server on their prod n8n —or has a single instance doing everything— and connects Claude or Cursor there, letting them build and run against Cumbre's real data. Why it happens: if you didn't set up separate environments, your only instance is production, and connecting the AI there seems natural. How to spot it: if the URL you gave your AI client points at the instance where real orders run, you have the problem. How to fix it: the AI connects to dev, always. And to make it impossible, disable the MCP module in prod with N8N_DISABLED_MODULES=mcp, so the endpoint doesn't even exist there. Module 4's environment separation is what makes this mistake avoidable by design, not just by discipline.

Confusing the AI's self-correction loop with human review (conceptual). What happens: someone sees the AI "validates and runs" the workflow it built, concludes it's already reviewed, and promotes it without reading the diff. Later the workflow, technically correct, turns out to be a business disaster. Why it happens: the AI's loop is convincing —it says "I validated, I ran it, it works"— and sounds like review. How to spot it: if you promoted something the AI built without having read its diff with human eyes, you skipped the review. How to fix it: the AI's loop verifies the workflow works; human review verifies it is right for the business and hides no surprises. Both are needed. The AI never approves its own work; step 4 of the safe loop is a human reading the diff, and it doesn't get skipped.

Exposing every workflow in MCP "for convenience" (practical and security). What happens: someone marks every workflow as available in MCP to avoid enabling them one by one, and ends up with their whole automation exposed to any connected AI client. Why it happens: enabling each workflow is a step, and skipping it feels efficient. How to spot it: if your AI can see workflows you aren't building or editing with it, you over-exposed. How to fix it: mark in MCP only what the AI needs to touch now, in dev, and remove it when you're done. Less exposed surface is less that can go wrong, especially since access isn't separated per client: whatever you expose, anyone connected sees.

Copying this guide's client configuration without checking your version's (practical). What happens: someone copies the Claude Desktop JSON configuration block as is, it doesn't work for them, and they get frustrated. Why it happens: each AI client's exact configuration and the MCP endpoint's syntax change with versions, and this guide is a snapshot from July 2026. How to spot it: if the connection doesn't establish and you're using literally what this lesson says with no verification, that's the point. How to fix it: use this guide's example to understand the mechanism —an endpoint URL pointing at dev, a credential, a name saying the environment— but pull the exact details from your version's official docs and your own instance's connection page. The principle is stable; the syntax isn't.

Exercises

Exercise 1 — Explain the principle in your own words. In three or four sentences, explain to a colleague why an AI can build workflows with its autonomous loop in dev with no problem, but must never do so in prod. Use the flight simulator analogy if it helps.

Exercise 2 — Design the per-environment lock. You have three environments in Docker Compose: dev, staging, and prod. You want the AI to be able to build in dev, and for it to be impossible for it to build in prod, not just discouraged. Which environment variables do you put in each one's file, and why does that make the accident impossible instead of just unlikely?

N8N_MCP_ACCESS_ENABLED=true

N8N_DISABLED_MODULES=mcp

Exercise 3 — Order the safe loop. You're given these six steps, out of order. Put them in the safe loop's correct order, and mark which is the only step where the AI acts and which is the only one where a human must approve: (i) it gets promoted to staging and to prod; (ii) the AI builds the workflow in dev; (iii) the human reviews the diff and approves in a pull request; (iv) it runs in prod; (v) you export and commit the workflow the AI touched; (vi) Git records the change with date and reason.

Summary and next step

In this lesson you opened the door to building workflows with AI, with the discipline making it safe. You understood MCP is a standard protocol —a "single port"— letting an AI assistant use external tools, and that n8n's MCP server gives the AI hands inside your instance: searching, creating, editing, and running workflows directly. You saw the facts confirmed as of July 2026 —it's in every edition including Community, it's enabled at the instance level and per workflow, access is per user and not per client, with the /mcp-server/http endpoint and the N8N_MCP_ACCESS_ENABLED and N8N_DISABLED_MODULES variables— and the warning to check every detail on your version, because this area moves fast. You installed the non-negotiable principle: the AI builds in dev, never in prod, because its self-correction loop runs things as part of building, and in prod that run would touch real, irreversible data. And you assembled the complete safe loop —the AI proposes in dev, Git records, the human reviews the diff, it gets promoted— resting on the net Module 4 built: the isolated environments that are the flight simulator where the AI can get it wrong with no consequences.

Before moving on you should be able to: explain what MCP is and what it gives the AI regarding your n8n; say why the AI builds in dev and never in prod, with the simulator analogy; order the safe loop's steps and point out where the AI acts and where the human approves; and design the per-environment lock with Docker Compose variables.

Lesson 5 completes the safety net from the other side. Up to here you built the road forward —promoting— and its quality control —reviewing. But no system is safe without an emergency exit. Lesson 5 is the rollback: what you do when a change, human or AI's, reached prod and broke something. You're going to learn to go back to the repository's last good JSON and re-import it into the affected environment, and to write a runbook —a numbered procedure someone else could follow under pressure, at three in the morning, without thinking. Because rollback gets rehearsed before the incident, not during it.

Resources

• Set up and use the n8n MCP server — n8n Docs — the official docs for the instance-level MCP server: how to enable it, what the AI can do, and versions. The source I confirmed for this lesson; check the details on your version, since they change fast.
• Connect to the n8n MCP server — n8n Docs — how to connect Claude Desktop, Claude Code, Cursor, and ChatGPT to the endpoint, with OAuth2 or token authentication; where the connection examples come from.
• Model Context Protocol — official site — what MCP is as an open standard, beyond n8n; useful for understanding the "single port" connecting AIs with tools.
• Manage instance settings using environment variables — n8n Docs — n8n's environment variable reference, including MCP's and N8N_DISABLED_MODULES, for configuring the per-environment lock.
• Release notes 2.x — n8n Docs — the version history; essential for MCP, since the capabilities for building and editing workflows arrived and changed between minor versions.