Connect Claude Code to n8n via MCP

Most teams use Claude Code to write and debug code. Plug it into n8n's MCP server and it starts doing something more useful: actually running your automations from the same chat window.

This post is the shortest reliable path to that setup — server-side toggles, agent-side config, and a verification step.

What you get

With n8n's instance-level MCP enabled, Claude Code can:

• List every workflow you've flagged "Available in MCP"

• Trigger any of them with structured inputs

• Build a new workflow from a prose description (n8n 1.88+)

• Pull execution logs to debug failed runs

No middleware. No third-party packages. The MCP server is built into n8n.

Step 1 — Enable MCP in n8n

You need owner or admin role.

1. Open Settings → n8n API
2. Toggle MCP Server on
3. Copy the access token

Treat the token like a password. It scopes to the user that generated it, so don't paste it into shared config.

Step 2 — Mark workflows as available

Nothing is exposed by default. For each workflow you want Claude to reach:

1. Open the workflow
2. Settings (top right) → toggle Available in MCP
3. Publish the workflow (drafts don't show up)

Both flags must be on. This is the single most common reason a workflow goes missing in the agent.

Step 3 — Configure Claude Code

Create .mcp.json at the project root (or edit ~/.claude/settings.json for a global config):

{
  "mcpServers": {
    "n8n": {
      "type": "http",
      "url": "https://YOUR-SUBDOMAIN.app.n8n.cloud/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_MCP_ACCESS_TOKEN"
      }
    }
  }
}

Self-hosted? Replace the URL with your instance's address — for local dev that's typically http://localhost:5678/mcp. Add .mcp.json to .gitignore so the token doesn't get committed.

Step 4 — Verify

Restart Claude Code (or reload the window) and ask:

List my available n8n workflows

You should get back names and IDs. If you don't, the issue is almost always one of:

• A workflow isn't published (drafts are invisible)

• The token belongs to a viewer-role user (needs owner/admin)

• A reverse proxy is stripping the Authorization header or buffering SSE

What to do once it's running

Trigger a workflow:

Run the "Send Weekly Report" workflow with week: 2026-W18

Build a workflow from prose:

Create an n8n workflow that receives a webhook, looks up the email in HubSpot,
and posts a Slack message with the contact's name.

n8n generates the workflow and Claude returns the workflow ID with a direct link.

Debug a failed run:

Show me the last execution log for the Lead Enrichment workflow.

Make it stick — install the skill file

By default, Claude knows nothing about n8n's MCP quirks. It learns the patterns each session and forgets them the next.

A short skill file fixes that. Drop it into .claude/skills/ and Claude loads it automatically at the start of every session — already aware that workflows must be published, that tokens are per-user, that "list first, then call by ID" is the reliable pattern.

git clone https://github.com/arturl95/n8n-agent-skills .claude/skills/n8n

The repo also has a workflow-level skill for the per-workflow MCP Server Trigger — useful if you want to expose just one automation as a typed tool.

Token scope, briefly

Each MCP token is tied to one n8n user. There's no shared service-account option yet. Cleanest setup for a team:

• Each developer generates their own token

• Tokens live in a project-level .mcp.json that's .gitignore-d

• Share the workflow definitions, not the credentials

If you genuinely need shared access today, the workaround is a shared n8n account — not ideal, but it works until n8n ships team-scoped tokens.

That's the full setup. The most useful next move is picking the right workflows to expose — start with the three or four you trigger manually most often. The agent earns its keep by replacing those clicks.