n8n-workflow-builder: an MCP server that lets an AI assistant drive your n8n instance

What n8n-workflow-builder actually solves

n8n's own interface is a browser canvas. You drag nodes, wire them together, save, then click execute. That is fine when you are building one workflow by hand. It is slower when you already know the shape of what you want and would rather describe it: "create a workflow that takes a webhook payload and posts it to Slack." The project's stated purpose is to put that description into an AI assistant's hands. The README says the server "bridges the gap between AI assistants (like Claude Desktop, Cline, or any MCP-compatible client) and your n8n automation platform," and lists the operations it exposes: list and browse workflows, create new ones with node configurations, execute them on demand, activate, deactivate, update and delete, and retrieve detailed status. The audience is narrow and specific. You need an existing n8n instance (self-hosted or cloud), an n8n API key, and an MCP-capable client. If you have none of those three, this project has nothing to offer you. It is also not a replacement for n8n itself. Nothing in the README suggests it runs workflows locally or reimplements the n8n execution engine; it calls n8n's official API, which the feature list describes as "n8n's official API with proper authentication." The assistant is a front end. n8n remains the system of record.

How the MCP bridge works between the assistant and the n8n API

The architecture is a three-hop chain. An AI client speaks the Model Context Protocol to this server; the server translates tool calls into HTTP requests against your n8n instance; n8n does the work and returns a result that travels back up the chain. The repository layout matches that description. There is a src/ directory for TypeScript sources, a dist/ directory, a tsconfig.json plus a separate tsconfig.smithery.json for the hosted build path, and a smithery.yaml for Smithery deployment. The package.json declares "type": "module" and exports both an ESM entry pointing at ./src/index.ts and a CommonJS entry at ./build/server.cjs, so the same package serves local Node consumers and the published binary. The build script runs tsc and then renames every emitted .js file to .cjs via a find command, which is why the bin field points at build/server.cjs while the start script points at build/server.js. That mismatch is visible in the files, and it is the kind of detail that bites people running npm start from a fresh clone. The README names the tool categories but does not publish the full JSON schema of each tool in the portion available, so the exact parameter names for workflow creation are not something this article can state. What is clear is the contract: the server holds your n8n host and API key, and every assistant action becomes an authenticated REST call. That means the assistant's blast radius equals the API key's permissions.

Installing n8n-workflow-builder and running a first workflow request

The README gives two install paths. The hosted one runs on Smithery.ai: you visit the site, search for "n8n-workflow-builder", configure your n8n host and API key there, and connect from any MCP-compatible client. The README lists the benefits as no local setup, automatic updates, professional hosting and a tool playground. The local path uses NPX and needs nothing beyond Node.js. Requirements are Node.js v18.0.0 or higher, an n8n instance, and an n8n API key with appropriate permissions.

The shortest local start is a single command. The README gives it verbatim:

npx @makafeli/n8n-workflow-builder

Running that downloads the published package and starts the server process. Because the package declares a bin entry named n8n-workflow-builder pointing at build/server.cjs, NPX resolves the binary without a global install.

If you want to read or modify the source, the README's manual path clones, installs, builds and starts:

# Clone the repository
git clone https://github.com/makafeli/n8n-workflow-builder.git
cd n8n-workflow-builder

# Install dependencies
npm install

# Build the project
npm run build

# Start the server
npm start

The build step is not optional here. The start script runs node build/server.js, and build/ is produced by tsc. Note that npm install triggers the prepare script, which runs npm run build again, so a fresh clone compiles twice. After the server is running, you register it in your MCP client's configuration alongside your n8n host and API key. The README points to a separate GETTING_STARTED.md for what it calls quick setup in under 5 minutes, and that is where the client-specific JSON belongs; the README excerpt does not reproduce it. Once connected, the first real use is a listing request. Ask the assistant to list your workflows. If the tool call succeeds you will see workflow names and identifiers returned from your n8n instance, which confirms authentication and connectivity in one step. Only after that should you ask it to create or execute anything.

Where the tool model breaks down

The honest limitation is that an MCP tool call is a request, not a guarantee. The README claims "Complete Workflow Management" and full CRUD, and the tool list supports that claim at the API level. But creating a workflow through a conversational assistant means the assistant writes the node graph. If it produces a node configuration with a wrong parameter name or a missing credential reference, n8n may accept the workflow and fail at execution time. Nothing in the available README describes a validation or dry-run step before execution, and there is no mention of rollback. Treat every execute call as production traffic. The permission model is the second constraint. The README says the server uses "n8n API key with appropriate permissions" but does not define what "appropriate" means or whether the server can be scoped to read-only. Since delete is among the exposed operations, an unrestricted key plus an assistant that misreads a request is a deletion path. The third issue is client variance. The README names Claude Desktop, Cline and "any MCP-compatible client," but MCP clients differ in how they surface tool confirmation prompts. If your client auto-approves tool calls, you have removed the last human checkpoint. Finally, this is the wrong tool if you want a visual builder. It has no canvas. It is also the wrong tool if you do not already run n8n, because it manages an n8n instance rather than providing one.

How this differs from Zapier, Make.com and the n8n web UI

The repository ships a COMPARISON.md that positions the server against Zapier, Make.com, the n8n Web UI and the n8n CLI. The meaningful distinction is where the authoring happens. Zapier and Make.com are hosted platforms with their own visual editors and their own execution environments; you build inside their product and pay per task. This server has no editor and no execution environment of its own. It is an interface layer over n8n, so the work still runs on your n8n instance, self-hosted or cloud, and the cost model is whatever your n8n deployment costs. Against the n8n Web UI, the difference is input method rather than capability: the Web UI gives you a canvas and immediate visual feedback, while this server gives you a text channel where the assistant composes the graph. Against the n8n CLI, the difference is that the CLI is a scriptable command surface for humans and shell scripts, whereas this is a tool surface for a language model. That matters because a model can be wrong in ways a shell script cannot: a script fails deterministically, an assistant can produce a plausible workflow that is subtly incorrect. If your team already automates n8n through the CLI or the REST API directly, this server adds a layer without adding capability. Its value is conversational authoring, and that value is real only if you find conversational authoring faster than dragging nodes.

Maintenance, licence and what upgrading costs you

The repository is not archived, and the last push was on 2026-03-19. That is roughly six months before today, so the project sits at the edge of what you could call current; the release history shows v0.10.1 tagged on 2025-07-25, while package.json on the main branch declares version 0.11.0. That gap is worth understanding before you pin a version: the branch is ahead of the last tagged release, so installing from npm and cloning from main may give you different code. The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. This article is not legal advice, and if you redistribute the package inside a product you should read the LICENSE file in the repository rather than relying on a summary. Upgrade cost is low in the ordinary case, because the package is a single Node process with no database and no migration path; you change the version and restart. The cost that is not low is the MCP SDK dependency. The README describes the architecture as built with TypeScript and the latest MCP SDK, and MCP is a young protocol, so client and server versions can drift. The repository carries both a jest.config.cjs and a jest.config.ci.cjs plus a test:core script that excludes credentials, tags and newWorkflowTools test files, which suggests those areas are the ones exercised against mocks rather than live services. If you depend on credential or tag management, that is the part to test yourself.

Editorial conclusion

Adopt n8n-workflow-builder if you already run n8n and want an MCP-compatible assistant to list, create, execute and manage workflows without leaving the chat client. Skip it if you need a visual drag-and-drop builder, a hosted SaaS, or a tool that validates workflow correctness before execution; the README describes tool calls, not validation. Before pointing it at anything real, verify that your Node.js version is 18.0.0 or higher, that your n8n API key carries the permissions the tools need, and that the published package version matches the 0.11.0 in package.json rather than the 0.10.1 release note.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. makafeli/n8n-workflow-builder on GitHub
4. README
5. Releases