DEV Community

Penumbra Ghost
Penumbra Ghost

Posted on

I built an n8n MCP Server so Claude can list, run, and monitor my workflows in plain English

#ai

I got tired of opening the n8n dashboard every time I needed to check on a workflow.

You know the drill: open browser → navigate to executions → find the right workflow → check status → close. Five clicks for something that should be instant.

So I built a 9-node n8n workflow that exposes my entire n8n instance to Claude Desktop via the Model Context Protocol (MCP).

Now I just type:

"Did my backup automation run successfully last night?"

And Claude calls my real n8n API and responds with the execution status. No browser. No clicking.

What is MCP?

MCP (Model Context Protocol) is an open standard from Anthropic that lets AI assistants connect to external tools and data sources. Instead of just answering questions from training data, Claude can call real APIs, read live data, and take actions.

n8n already has an MCP Server Trigger node (available in 1.70+). I used it to expose 4 tools to Claude:

Tool What it does
list_workflows Returns all active workflows with IDs and names
run_workflow Triggers any workflow by ID
get_executions Pulls recent execution history with status
search_workflows Keyword filter across all workflow names

How it works

The architecture is simple:

Claude Desktop → mcp-remote → n8n MCP Server Trigger → Code nodes → n8n REST API
Enter fullscreen mode Exit fullscreen mode

Each of the 4 tools is a Code node that calls the n8n REST API internally using X-N8N-API-KEY authentication.

The workflow:

  1. MCP Server Trigger — SSE endpoint that Claude connects to
  2. list_workflows — GET /api/v1/workflows?active=true
  3. run_workflow — POST /api/v1/workflows/{id}/run
  4. get_executions — GET /api/v1/executions?workflowId={id}&limit=N
  5. search_workflows — keyword filter on workflow names

Credentials are stored in n8n Variables ($vars.N8N_BASE_URL and $vars.N8N_API_KEY) — never hardcoded.

The Claude Desktop config 

{
  "mcpServers": {
    "n8n": {
      "command": "npx",
      "args": ["mcp-remote", "https://your-n8n-instance.com/mcp/your-webhook-id/sse"]
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

Restart Claude Desktop. Claude now has access to your n8n instance.

Real examples from last week

Morning check:

"List all my active workflows and tell me which ones ran in the last 24 hours"

Claude lists them, checks execution history, and flags any that didn't run on schedule.

Quick trigger:

"Run the client invoice workflow"

Claude finds the workflow by keyword, triggers it, returns execution ID.

Debugging:

"Show me the last 5 executions of the email automation — did any fail?"

Claude pulls execution data and summarizes results including error messages.

Requirements

  • n8n 1.70+ (cloud or self-hosted)
  • Claude Desktop or Claude Code
  • n8n API Key (Settings → API Keys)
  • Public URL or ngrok for local

Setup: ~15 minutes.

Get the template

Full workflow JSON + Claude Desktop config snippet available on n8nMarkets: https://www.n8nmarkets.com/en/workflow-templates

Search "MCP Server".

All credentials stay in your n8n instance. Claude only sees what the tools return — your API keys never leave your server.

Top comments (1)

Collapse
 
harjjotsinghh profile image
Harjot Singh •

An n8n MCP server so Claude can list, run, and monitor workflows in plain English is a great bridge, because n8n already encodes the deterministic part (the workflow, the steps, the connections) and the agent adds the natural-language control layer on top, which is exactly the right division: the workflow is the reliable backbone, the agent is the flexible interface to it. That combo sidesteps the usual agent failure of improvising a process, because the process already lives in n8n, the model just chooses which to run and reads results, rather than reconstructing the steps each time. The capability I'd think hardest about is run, because list and monitor are read-only and safe, but run mutates the world (your workflows do real things), so that's the verb that needs a gate: which workflows is the agent allowed to trigger, with what parameters, and is anything destructive behind a confirm. Plain-English control is powerful precisely because it lowers the bar to triggering things, which is also why scoping what it can trigger matters. Let it freely list and monitor, gate what it can run. That deterministic-workflow-plus-bounded-agent-control instinct is core to how I think about Moonshift. For the run capability, are you allowlisting which workflows the agent can trigger, or can it run anything in your n8n instance?