n8n MCP Server

1What it does

An MCP server that bridges n8n — the workflow-automation platform — into agent sessions. It exposes n8n's API as tools: list workflows, inspect a workflow's nodes and connections, activate or deactivate, trigger executions, and read execution history — so the agent can answer "why did the nightly sync fail?" by reading the actual workflow JSON and execution record rather than you pasting screenshots. The README ships per-client install JSON including an explicit Antigravity mcp_config.json block, which puts it ahead of most community MCP servers on Antigravity coverage. It runs stdio — a Node process launched by the agent with your n8n base URL and API key in environment variables — keeping credentials and traffic local to your machine.

2When to use it

Reach for it when n8n runs infrastructure your code touches — an agent that can read the webhook workflow it feeds, or check whether the downstream automation fired, closes the loop between the repo and its surrounding plumbing. It fits developers who already run self-hosted or cloud n8n; without an n8n instance behind it the server has nothing to do. Skip it if your automation lives elsewhere (Zapier, Make, Temporal) — the tool surface is n8n-specific end to end. Also a reasonable second install alongside github-mcp-server for projects where CI/CD state and automation state both matter to the agent.

3How to get started

Three pieces to assemble: a running n8n instance, an n8n API key (generate under n8n Settings → n8n API), and the mcp_config.json block from the README's Antigravity section — command/args launching the server via node/npx with N8N_API_URL and N8N_API_KEY in env. Restart the agent and verify registration by listing MCP tools, then a smoke test — "list my n8n workflows" — confirms both auth and connectivity in one shot. The repo README is the reference for the exact JSON; the server is a small Node project, so npm install && node from a checkout works where npx-on-demand isn't wanted.

4Configuration

Configuration is the env block: N8N_API_URL (the instance's API base, typically …/api/v1) and N8N_API_KEY. The API key's scope is n8n's own concern — an agent with a key can do whatever that key permits, so generate a dedicated key for the agent rather than sharing a human's, and prefer instances reachable over HTTPS or localhost. mcp_config.json holds the key in plaintext — keep the file's permissions tight and it out of version control. If the agent only needs read access (inspect, don't trigger), the honest answer is behavioral instruction — n8n's API keys aren't permission-scoped per endpoint on all versions.

5Things to know

• Community server (not n8n's own) — verify the API surface against your n8n version; n8n's API moves and a custom server can lag.
• The -custom fork is the one carrying Antigravity install docs — upstream variants exist with different client coverage; check you're on the documented one.
• Triggering workflows through the agent is potent and irreversible-by-side-effect — a "run the deploy workflow" call is a real world action, not a code diff.
• Local stdio keeps n8n credentials off the wire between agent and server; the only network path is server→your n8n instance. - Execution history is the sleeper feature — an agent that can read why the last run failed saves the dashboard round-trip that makes n8n debugging slow.
• Self-hosted n8n instances work the same as cloud — point N8N_API_URL at your instance; the server cares about the API, not the hosting.
• Pairing with the rules layer helps here — a rule requiring the agent to summarize a workflow before triggering it turns a consequential side effect into a reviewable one.
• The tool list is the thing to audit after install — confirm the agent sees read tools and that trigger operations behave as expected on a test workflow before pointing it at production automation.

6Related on the map

References

• Repository
• Antigravity MCP documentation