I built an n8n MCP Server — now Claude controls my workflows in plain English

Built with n8n
1

Hey community,

I’ve been building n8n automations for a while and kept running into the same friction: every time I needed to trigger a workflow, check an execution, or find a workflow ID, I had to open the browser, navigate the dashboard, and click through menus.

So I built an n8n MCP Server workflow that exposes your n8n instance to Claude Desktop or Claude Code via the Model Context Protocol.

**What Claude can do once it’s connected:**

- “List all my active workflows” → returns IDs, names, status

- “Run the invoice workflow” → triggers it, returns execution ID

- “Check if my backup automation ran successfully today” → pulls last 5 executions with status

- “Find all workflows related to Slack” → keyword search across all workflows

**Technical breakdown:**

The workflow has 9 nodes:

1. MCP Server Trigger (SSE endpoint)

2-5. Four Tool nodes: `list_workflows`, `run_workflow`, `get_executions`, `search_workflows`

6-9. Four Code nodes that call the n8n REST API internally

Each tool uses `X-N8N-API-KEY` auth and `$vars.N8N_BASE_URL` — no hardcoded credentials.

**Requirements:**

- n8n 1.70+ (MCP trigger requires this)

- Claude Desktop or Claude Code

- n8n API Key + public URL (or ngrok for local)

**Setup time:** ~15 minutes (mostly the Claude Desktop config)

I packaged it with full documentation and the Claude Desktop config snippet. Available on n8nMarkets: n8n Markets — Buy, Sell & Hire n8n Workflow Experts

Happy to answer questions on how it works!

1 Like
2

Exposing n8n’s API through MCP so Claude can trigger and inspect workflows conversationally is a genuinely useful pattern - the “check if my backup automation ran successfully today” use case alone saves a lot of dashboard navigation. Curious how you’re handling authentication between Claude Desktop and the n8n instance - is it a shared API key per Claude config, or are you doing anything more fine-grained?

3

Great question! Auth is currently straightforward: a single n8n API key stored as an env var in the Claude Desktop config (`claude_desktop_config.json`). The MCP server reads it at startup and uses it for all requests to the n8n REST API:

```json

{

“mcpServers”: {

"n8n": {

  "env": {

    "N8N_API_KEY": "your-key-here",

    "N8N_BASE_URL": "http://localhost:5678"

  }

}

}

}

```

So it’s essentially owner-level access — same permissions as the API key owner. For personal setups this works fine since the key lives locally in Claude’s config and never leaves your machine->n8n path.

The limitation you’re pointing at is real though: n8n’s current API key model doesn’t support native scoping (e.g., “read executions but can’t deactivate workflows”). If you need that, you’d have to add a thin proxy layer that whitelists specific endpoints before forwarding to n8n.

For now I treat it as a personal tool so single-key is fine. If I were exposing it to a team I’d want scoped permissions first — either a per-method whitelist in the server config, or waiting for n8n to ship API key scoping natively (it’s been on the community wishlist for a while).

The “check if my backup ran today” use case is exactly the kind of thing that makes this shine — conversational ops instead of dashboard navigation.