Free · open source · zero telemetry
n8n workflows that actually run. Proven against n8n-mcp — the 21k-star community validator.
A curated n8n knowledge base + known-bug catalog for Claude Code. A Claude Code plugin, benchmarked head-to-head with n8n-mcp on 128 real prompts.
Works in production
80%
n8n-knowledge plugin
Passes the n8n-mcp validator
94%
n8n-knowledge plugin
128-prompt battery · newest run per prompt · data generated 2026-06-25
Install
Open source (MIT) and easy to install
Free, open source, and benchmarked in the open — and running in under a minute. Inside Claude Code, paste these three commands. Prerequisite: a recent Claude Code — check with claude --version.
- 1 Add the marketplace
/plugin marketplace add https://github.com/dbenn8/n8n-knowledge - 2 Install the plugin
/plugin install n8n-knowledge@n8n-knowledge - 3 Activate it (no restart needed)
/reload-plugins
Watch your plugin feed Claude in real-time.
Most of what the plugin does is invisible — it injects n8n docs, node specs, and known-bug warnings straight into the model's turn, where only Claude sees them. To watch the actual context it pulls in, open a second terminal and tail its log:
tail -f ~/.cache/n8n-knowledge/debug.log Every n8n-related question shows exactly which docs and gotchas got injected — the plugin stops being a black box. The log is owner-only and lives under your cache dir (never world-readable /tmp); set the debugRecall plugin option to full for the complete context.
Source, issues, and the benchmark harness: github.com/dbenn8/n8n-knowledge · v0.3.11
Your instance, your keys
Safe by design
The plugin has no access to your n8n instance. It builds and validates workflows as local .json files on your machine — it never connects to your n8n, never asks for or stores your credentials, and never writes to a live workflow. The one network call it makes is read-only recall to the knowledge base. Nothing reaches your instance until you upload it yourself.
How to use it
From prompt to a running workflow in four steps.
- 1
Ask
Ask Claude to build the n8n workflow you want as a JSON file — and to flag anything it needs clarified about your request.
- 2
Let it work
The plugin silently feeds Claude the docs, node specs, and known-bug warnings it needs, then runs the workflow through the n8n-mcp validator and returns any errors — iterating until it passes.
- 3
Import
Import the file into your n8n instance — via JSON upload, the n8n API, or the official n8n MCP.
- 4
Add credentials
Assign credentials to any nodes that need them by double-clicking those nodes in n8n.
Importing a .json workflow to your n8n instance
Move the finished file into your instance:
no setup · recommended
JSON file import
The simplest path — works on any n8n, no API key, nothing to configure. Steps below.
The simplest path — file upload:
- 1 In n8n, open a workflow (or create a new one).
- 2 Click the ⋮ menu in the top-right of the editor.
- 3 Choose Import from File and pick the .json the plugin built.
You can also drag the file onto the canvas, or paste the JSON with Ctrl/Cmd + V. Full guide: n8n's official import docs →
Prefer the API? See the n8n public API reference.
Methodology
How we measured success.
"Better" is a funnel — each stage a stricter bar than the last. The headline metric is the last one.
Valid
Passes the n8n-mcp schema validator. It would import.
Correct
Valid AND does what the prompt asked — scored by a blinded Claude Opus judge.
Works
Correct AND designs around the relevant known n8n bug, so it won't silently fail in production.
A real engine as judge
Every workflow is validated by the n8n-mcp validation engine — an independent open-source project, not a heuristic or an LLM's opinion. Valid means it would import.
A blinded judge for intent, rules for pitfalls
A blinded Claude Opus judge scores intent-fidelity (no knowledge of which tool produced which workflow; verdicts cached). Pitfall avoidance is scored separately by 28 deterministic rules — one per known bug — that read the workflow JSON, so anyone can audit it. Judge where you must, deterministic where you can.
Let the data govern
Several promising changes were reverted because the numbers went the wrong way — a biased timeout, a worse repair mode. The benchmark overrules intuition.
Reproducible
Same prompts, same models, isolated per-run config. The harness and prompt set are public — run it yourself.
Honest scope & limitations — what this does not prove
- Validator ≠ live import. "Valid" means it passes the n8n-mcp validator (the engine n8n ships node definitions from), not that it ran on a live n8n instance. A deliberate, disclosed trade-off for reproducibility.
- Known-bug provenance. Some bug-prompts derive from the same catalog the plugin recalls from, so that metric flatters the tool that draws from it. Reported as a directional signal.
- The judge is an LLM. The Opus judge is blinded and cached, but it's still a model scoring models — a second opinion alongside the deterministic validator, never ground truth alone.
- Snapshot, not variance study. The figures take the newest run per prompt across the 128-prompt battery on a fixed date — coverage, not multi-sample variance.
The proof
Results
Same 128 prompts, same model (Claude Sonnet 4.6), same scoring — the only variable is the tool. Each generated workflow is validated by the n8n-mcp validation engine, a blinded Claude Opus judge scores intent, and 28 deterministic rules check known-bug avoidance.
vs. the status quo — the same model with no tools at all produces a valid, working workflow just 26% of the time on Sonnet (9% on DeepSeek). The plugin takes that to 80% works-in-production.
128-prompt battery · real n8n-mcp validator + blinded Opus judge · reproduce it on GitHub.
Benchmark explorer
Every model & condition
Filter and sort the full benchmark. valid → correct → works is the funnel; pitfall% is over the 28 known-bug prompts. Numbers come straight from the published data, baked in below.
Conditions: both plugin runs inject the same n8n knowledge — node specs, schema, and known-bug warnings — into Claude's context. The difference is the design gate: gate-ON (the shipped default) adds a mandatory step that forces Claude to design around every flagged known bug before finalizing; gate-OFF keeps that knowledge but drops the enforcement, isolating how much the gate adds on its own. mcp swaps in n8n-mcp's tools instead of the plugin; bare is the raw model with no tools. Gate-OFF is hidden by default — tick it to see the gate's contribution.
Credit where it's due
Built on n8n-mcp
The ground-truth validator behind every number here is n8n-mcp — the independent, open-source MCP server by Romuald Członkowski (21k+ ⭐ on GitHub). It bundles the same node definitions n8n ships, which is exactly what makes it a credible oracle.
It's also the tool we benchmark against — so the competitor's own engine judges both tools, the fairest scoring we could ask for. Integrating it rather than rebuilding a validator is what let us move fast and keep the bar honest. This tool wouldn't exist in its current form without it.
n8n-mcp on GitHub · 21k+ ⭐ — go give it a starFree & private
It doesn't watch you back
0
telemetry events
0
trackers
0
accounts required
Free and open source. No telemetry, no tracking, no sign-up. The plugin recalls from the n8n knowledge base to do its job — that's the one call it makes — and it keeps nothing about you.
Under the hood
Powered by Hindsight
The plugin's n8n knowledge lives in Hindsight — an open-source (MIT) agentic-memory engine by Vectorize. Its recall is what surfaces the right docs and the right known-bug warning at the moment Claude needs them. The n8n instance that serves this plugin is open source too — n8n-hindsight on GitHub.
TEMPR retrieval
Temporal Entity Memory Priming Retrieval: four strategies — semantic, BM25 keyword, graph, and temporal — run in parallel, fused with Reciprocal Rank Fusion, then reranked by a neural cross-encoder.
A real knowledge graph
Hindsight extracts structured facts, resolves entities, and tracks temporal & causal links — so recall returns relevant memory, not just nearest-vector soup.
Retain · Recall · Reflect
Three operations: store durable signals, retrieve the right context on demand, and reflect to synthesize across memories.
Hindsight's approach is described in the technical report "Hindsight is 20/20" (arXiv:2512.12818, Dec 2025), co-authored by Vectorize, Virginia Tech, and The Washington Post, and covered independently by VentureBeat.
91.4%
LongMemEval
(Gemini-3)
83.6%
on a 20B open model
vs 60.2% full-context GPT-4o
Live · the knowledge base behind the plugin
Memories
—Documents
—Graph links
—Memory composition
Link types