You describe, in plain sentences, a process you currently run by hand. A little later your n8n account holds a finished workflow: a trigger, two AI agents, prompts written into the right fields, an email going out at the end. You never dragged a single node onto the canvas. It sounds like an ad, but the mechanism is simple and repeatable. It also has a price: you still have to review what the agent built, because it won't set everything up the way you asked.
I'll cover what Claude Code needs in order to understand n8n, how to set up the project, why you start with a plan, what you check before switching the workflow on, and where the method stops working.
Hands and knowledge: what Claude Code is missing for n8n
Two terms first. A workflow in n8n is an automated sequence of steps that runs on its own, say every morning or whenever a form comes in. Each step is a node: fetch data, ask an AI model, send an email.
Out of the box, Claude Code is capable and it knows JSON, the format n8n stores workflows in. What it doesn't know well is the specific nodes, their parameters, and the expression syntax. An expression is a short piece of notation inside a node field that says "put the output of the previous step here". Without that knowledge the agent guesses, and guessing at configuration gives you a workflow that won't start.
So you give it two things.
Hands: the n8n MCP server. MCP is a standard way to connect a model to outside tools. An MCP server is a plug-in through which the agent can look things up or take actions beyond the chat. The n8n server gives it a catalogue of nodes with their parameters documented, a library of ready-made workflow templates to borrow from, and, most importantly, access to your n8n instance, where it can create, update, validate, and activate workflows. Your instance is simply your n8n account, in the cloud or on your own server.
Knowledge: the n8n skills. A skill is a file of instructions the agent reads only when it needs it. The n8n set teaches it expression syntax, how to use the MCP server's tools, common workflow patterns, validation, node configuration, and writing code nodes in JavaScript and Python. Loading on demand matters. If the agent read the documentation for every node with every message, it would clog its working memory and burn through usage limits. It knows the knowledge exists and reaches for it when the task calls for it.
Both are available as open repositories on GitHub. Together they move the agent from guessing to checking.
The project, CLAUDE.md, and an install you hand to the agent
Setting up Claude Code itself deserves its own article. In short: you install the Claude Code extension in an editor such as VS Code, sign in with your account, and open an empty folder. That folder is your project, and everything the agent prepares lands in it as files.
The first file it should contain is CLAUDE.md. Think of it as the standing system instruction for the project: what environment the agent works in, what the project is for, and which rules to follow. Without it every conversation starts from zero and files pile up with no order.
You don't have to write it yourself. Switch Claude Code to plan mode, where the agent only analyses and proposes and changes nothing, and say it straight: help me create CLAUDE.md for a project where you'll build workflows in my n8n instance using the n8n MCP server and skills. The agent will ask follow-up questions, such as which tools it will get and whether n8n runs in the cloud or on your server. Paste in the addresses of both repositories and it reads them on its own. A good result spells out the order of work (understand the requirements, look through templates, research the nodes, build, validate, deploy) plus a set of safety rules.
The install is the agent's job too. Instead of following the setup steps in each repository, you write: install this server and these skills, and make sure they work in this project. The agent stops the moment it lacks information. Here it will ask for your instance address and an API key, a long string of characters that works as a password for software. You create the key in your n8n settings.
Treat that key as a password to the whole instance, because through it the agent can create and change workflows. The configuration holding the key ends up in a file inside the project, so that file must stay out of shared folders and repositories. Name the key after the project so you can recognise it, give it only the permissions the project needs if your n8n plan allows that, and delete it when the project is over.
After the install, restart Claude Code and test the connection with two questions. First: search for the webhook node through the MCP server. Second: can you create workflows in my instance, and are the n8n skills loaded? If both answers are specific rather than reassuring, you're ready to build.
Plan first, then build
One example shows the whole method. Every day at 7:00 a research agent searches the web for news in your field, a second agent turns the findings into an HTML newsletter, and the result arrives by email through Gmail. Two separate agents, each running the model you choose.
You paste that description in plan mode, not straight into execution. The agent browses the node catalogue and then asks about what you left out: which address should get the newsletter, which web search tool to use, which time zone 7:00 refers to. These are questions you would only discover at the first error if you built it by hand.
Then you get the plan: the architecture, the list of nodes, the configuration of each. Read it before you accept it. In this example the plan was to produce the workflow as a JSON file on disk rather than in the n8n instance. One sentence of correction before execution costs far less than reworking finished output.
Only when the plan is right do you switch the agent to a mode where it carries out steps without asking about each one. Turn on automatic execution only once you trust the plan. Even then the agent will stop and ask if something is missing.
While it builds you see its task list: create the workflow, validate it, report back. Validation does most of the work. The agent sends the workflow to the instance, checks it, and reads the errors: wrong parameters on a code node, a misconfigured messaging node. It fixes each one itself and validates again until the configuration passes. At the end you get a link to the workflow and a list of next steps.
Review before you switch it on: every node goes through your hands
The workflow behind the link looks finished. It isn't. Two things always stay on your side, and a third turns up during review.
You connect the credentials. The agent builds the nodes, but you link the accounts for the search tool, the model provider, and email yourself in n8n. That split works in your favour: the agent never needs your service passwords.
You check the model in every agent node. In this example both agents got older model versions than the description specified. The agent also filled in parameters nobody asked for, such as a response length limit and temperature. The workflow ran, just not the way it was ordered. No validation catches that, because as far as n8n is concerned the configuration is valid.
You read the prompts and expressions in full. The research agent got a sensible role and a list of topics to search, with a request to cite sources. The newsletter writer got an expression in its message that pulls in the previous step's output, plus HTML styling instructions in its system prompt. Check that the expressions point at the right fields. Watch for decisions made on your behalf as well. In the Gmail node the agent switched off the n8n attribution line at the bottom of the email without being asked. Here that happened to be welcome, but it's the kind of thing you want to know before the workflow goes live.
Then you run the workflow manually, as if it were already 7:00, and walk through it step by step: what the research agent found, what the writer received, what landed in the inbox. Only after a run like that do you switch the schedule on.
You request changes in the same conversation: rewrite the prompt, swap the search tool, add a section. The agent updates the workflow in your instance and you see the change in n8n. Repeat the same review after every significant change.
Limits: small pieces, a sketch, and questions
The method has limits, and it pays to know them before you hit them.
Don't order everything at once. Asking for a workflow of several dozen nodes in one go can take your instance down. The agent pushes large changes, hits timeouts, retries, and retries again until the server stops responding. A cloud-hosted n8n instance can stay down for a long time after that and may need the provider's support, since you can't restart it yourself. On your own server you can restart it, but the problem returns with the next oversized request. So you build in pieces: one part of the flow, review, test, then the next part.
Sketch the flow before you describe it. A rough drawing on a whiteboard or in any diagram tool sorts out your own thinking. In my view, a screenshot of that sketch attached to the description gives the agent a better starting point, because it sees the structure you have in mind right away: what triggers the flow, where it branches, where the data goes.
Ask when something doesn't make sense. You don't need to read code to work this way. When the agent does something unclear, write: explain this to me, or why did you set it up like that? Sometimes the agent will also suggest you install or configure something yourself. Then the answer is simple: you do it.
The plan grows with the complexity. On a simple workflow plan mode saves you a few corrections. On a more complex one, where you need to think through what happens to the data along the way, it asks about things you wouldn't have thought of.
The most valuable skill in this kind of work is describing the outcome you expect clearly, the way you'd describe it to a developer or a project manager, and reviewing honestly what you get back. The agent builds; you sign off. Start with one small process you currently do by hand: describe it in plan mode and check every node before you switch it on.