Ask an AI coding agent to wire up an n8n workflow and it'll hand you clean-looking JSON in seconds — a node name, a set of parameters, maybe a resource ID pulled from a dropdown. Import it and sometimes it just works. Other times, part of what it gave you doesn't exist. Not a typo. Not a version mismatch. A node, a property, or an ID the model invented because it looked like something that should be there.
That's the failure mode a small n8n-focused corner of X has been comparing notes on lately: agents that write workflow JSON confidently, using node names and fields that sound exactly right and aren't.
Why the model does this
n8n's node catalog is bigger than most people building with it realize. The open-source n8n-mcp project, which indexes the full set for AI tools, currently tracks 2,864 nodes — 836 core nodes plus 2,028 community nodes, 1,674 of which are verified. Coverage of individual node properties sits at 99%, but operation-level coverage is only 66.5%, and that gap is where trouble starts.
A model trained on a snapshot of n8n's documentation and public workflow examples has seen plenty of Slack nodes, HTTP Request nodes, and Google Sheets nodes. It's absorbed the shape of what a "channel" field or a "method" parameter usually looks like. So when it hits a node — or a specific operation on a node — it hasn't seen enough of, it doesn't say so. It pattern-matches to the nearest thing it knows and produces a field that fits the shape. The JSON parses. It imports. It looks done.
A hallucinated node isn't a syntax error. It imports clean and fails quietly at 2am, which is worse.
The fix isn't a longer prompt
The instinct is to add more instructions — "only use real n8n nodes," a list of examples, a stern warning about accuracy. None of that closes the actual gap. The model isn't being careless. It doesn't have the ground truth to check itself against, and no amount of prompt engineering manufactures knowledge that was never in the training data. What actually works is giving the agent something to look up before it writes the config, not a longer set of instructions to follow while guessing.
Give the agent the real schema
That's the specific thing n8n-mcp does, and why the recommendation shows up whenever this problem comes up. It's an MCP server — installed as the n8n-mcp npm package, or run via Docker or Railway — that exposes n8n's actual node catalog to any MCP-compatible AI assistant: Claude Code, Cursor, Windsurf, VS Code.
It ships 28 tools in two groups. Seven are documentation tools — search_nodes, get_node, validate_node, search_templates — for looking up what a node actually accepts before the agent writes a single field. The other 21 talk to a live n8n instance: n8n_validate_workflow checks a finished workflow through what the project calls multi-level validation, from a quick structural pass up to a full configuration profile, and n8n_autofix_workflow can correct common mistakes automatically.
One tool matters as much as the node names: n8n_explore_node_resources resolves the dynamic dropdowns — which Slack channel, which Airtable base — against your actual connected credentials. That closes a second, quieter version of the same problem: an agent guessing at a resource ID that has the right shape but doesn't point at anything real.
What changes in the actual build
Without something like this, the agent writes the whole workflow from memory in one pass, you import it, and you find out what's wrong when a run fails — sometimes immediately, sometimes only on the input that hits the one field it guessed at. With schema access wired in, the agent looks up the node before configuring it, runs the workflow through validation once it's assembled, and only hands you something after it passes. The failure shifts from "silent break after deploy" to "the agent flags it before you ever click import."
We build a fair amount of n8n automation for clients, often starting from a workflow a coding agent drafted. The difference between reviewing that draft and rebuilding half of it by hand usually comes down to whether the agent had real node data to check against while it was writing.
What it still won't catch
Schema validation is not the same as correctness. A workflow that references every node and field accurately can still send the wrong email to the wrong list, or route a refund through the wrong approval path. n8n-mcp closes the "does this node and field actually exist" gap. Whether the logic does what you meant is still a human review question, exactly like it was before any of this tooling existed.
If you're already letting a coding agent produce n8n workflows for you, this is a low-effort fix for a specific, recurring failure — set it up once and an entire category of "why did this break" debugging goes away. It's part of how we build and maintain AI automation for clients, and if you want the wider picture on how n8n's own MCP support fits into this, we covered that separately.
— Cole
Sources
- n8n-mcp on GitHub — node counts, tool counts, and coverage figures cited above, verified directly from the project repository
- X thread on agents inventing fake n8n nodes — the discussion that prompted this post