# An MCP server that puts n8n workflow CRUD behind an assistant > A TypeScript Model Context Protocol server that connects AI assistants to an existing n8n instance so workflows can be listed, created, executed, activated and deleted in conversation. Configuration is two environment variables, and the documented installation paths are a hosted registry, a one-line package run, or a build from source. **makafeli/n8n-workflow-builder** — AI assistant integration for n8n workflow automation through Model Context Protocol (MCP). Connect Claude Desktop, ChatGPT, and other AI assistants to n8n for natural language workflow management. - Repository: https://github.com/makafeli/n8n-workflow-builder - Stars: 545 · Forks: 128 - Language: JavaScript - License: MIT - Published: 2026-09-15 · Updated: 2026-09-15 · Language: en - Canonical page: https://hysenlabs.com/projects/makafeli-n8n-workflow-builder ## The whole workflow lifecycle, including delete The tool surface is a complete set of create, read, update and delete operations over n8n workflows, and the individual capabilities are listed plainly. An assistant can list and browse the workflows that already exist, create new ones with complex node configurations, execute a workflow on demand, and manage the lifecycle: activate, deactivate, update and delete. It can also monitor workflow status and pull back detailed information about one. Everything goes through n8n's own API with an API key, rather than by driving the web interface. That distinction matters more than it sounds: the web editor has state and undo that an API does not, so an assistant editing a workflow through this route is not doing what you would be doing by hand in the browser. Delete and activation being in the same tool set is worth noting on its own. A bridge that could only read would be a safe thing to connect; one that can activate and deactivate is making live changes to automation that may be running in production. The requirements are modest: a Node runtime, an n8n instance that may be self-hosted or cloud, and an API key with appropriate permissions. ## Two variables, and the key comes from inside n8n Configuration is two environment variables, and the documentation is specific about the shape of both. The first is the host. The examples given are a bare local address and a full API path, which suggests the server is tolerant of either form, but it is worth confirming which one your instance expects before troubleshooting anything else. The second is the API key, and the example shows a fixed prefix. Keys are not created outside n8n: the documented procedure is to open the instance, go to the settings page to the API keys section, create one, and copy the generated value. That means the permission scope of the bridge is exactly the permission scope you chose when creating the key, and nothing in this tool narrows it further. Given that the capability set includes deletion and activation, the key is the only place where that restriction can live. ```bash # For local testing export N8N_HOST="http://localhost:5678" export N8N_API_KEY="your-api-key-here" ``` The same two variables appear inside the client configuration rather than your shell, which is the form most assistants actually read. ## Three install routes, and the readme numbers them wrong There are three documented ways to get it running, and they differ mostly in who maintains the process. The hosted route is offered first and described as recommended. You find the server on a public registry, configure it with your n8n host and key, and connect to it from any compatible assistant. The stated benefits are no local setup, automatic updates, hosting somebody else handles, and a playground for trying tools before using them. The tradeoff is the obvious one: your n8n credentials are handed to a third-party host. The local route is a single package invocation with no install step: ```bash npx @makafeli/n8n-workflow-builder ``` The third route is a clone, install, build and start, for development or customisation. A small documentation bug is worth noting so it does not waste your time: the third section is labelled as a second method, so the readme appears to contain two method twos and no method three. Beyond the readme there are four separate documents covering a short setup guide, real-world scenarios, a comparison against several alternatives including a hosted automation platform and the n8n interface itself, and troubleshooting. ## The build renames its own output after compiling There is a small piece of build machinery that explains a surprising amount about how the package works. The build is a TypeScript compile followed by a second step that walks the output directory and renames every compiled file from a .js extension to .cjs. There is a separate compile for the hosted deployment target and a clean step that removes both build directories. The reason is the module type. The package declares itself as a module, which means a plain .js file inside it would be interpreted as an ES module. Renaming the compiled output to the CommonJS extension sidesteps that mismatch, so the same directory can hold CommonJS output inside a package marked as ESM. That rename step is also why the start script is slightly inconsistent with the binary entry, which points at the renamed file while the start script names the original extension. Small thing, but it is the kind of thing that makes a fresh clone look broken when it is not. The prepare script runs the build, which is what makes a plain install compile the project without you asking. That is the mechanism behind the claim of working out of the box with the package runner. Development is a watch-mode compile, and the test suite runs on a JavaScript test runner with a separate configuration for continuous integration. ## The import entry points at a file the package does not ship There is an inconsistency in the published package definition that is worth understanding before you depend on it. The package exports a module entry that resolves to a TypeScript source file inside the source directory, alongside a require entry that resolves to the compiled server file. But the files list for publication contains only the compiled build output, the readme and the licence. The source directory is not in it. So the ESM import entry references a file that is not shipped. Anyone consuming the published package through the import condition rather than the require condition would resolve to something that does not exist on disk. In practice this may be invisible, because the most common way to use the package is as a server launched through the package runner, which uses the binary entry and never touches the exports map at all. It would matter if you tried to import the server as a library, and it is the kind of packaging bug that a type-checking consumer would catch immediately and a runtime consumer might not. The test scripts are also partitioned by file rather than by behaviour, with one target skipping several named test files and another running only those. That implies a deliberate separation between tests that exercise real error paths and the rest of the suite. ## Build output and test results are committed to the repository A few repository-level details tell you what state the project is in. Two directories that are usually ignored are present at the top level: the compiled output directory and a test results directory. Both appear to be tracked, which means diffs carry build artefacts unless something outside the readme is preventing that. The manifest version is ahead of the last published release. The single tagged release is from July 2025, the manifest declares a later patch version, and the last push to main is dated 2026-03-19. The repository is not archived. Those three facts together suggest a project where development has continued past the last release but the release process is not keeping pace, which is a pattern worth confirming directly rather than inferring. There is a release setup document and a deployment document for the hosted registry, plus a deployment manifest at the top level, so the machinery exists and may simply not have been run recently. The remaining structure is conventional: a source directory, a scripts directory, tests, two test runner configurations, two TypeScript configurations for the main and hosted builds, and an editor configuration directory. ## Conclusion This suits someone who already runs n8n and wants an assistant to drive it rather than clicking through the editor, since the tool exposes the full lifecycle including activation and deletion rather than only reading. It suits you less if you are deciding whether n8n is the right platform, because this is a bridge to an existing instance and contains no workflow logic of its own. Before letting an assistant near it, scope the API key to the permissions it actually needs, because the documented capability set includes delete, and remember that the manifest version sits ahead of the last published release. ## FAQ ### What can n8n Workflow Builder actually do? It lets an assistant list and browse existing workflows, create new ones with complex node configurations, execute them on demand, manage their lifecycle by activating, deactivating, updating and deleting, and monitor their status. All of it goes through the n8n API rather than the web interface. ### What do I need to configure n8n Workflow Builder? Two environment variables: the n8n host URL and an API key. The key is created inside n8n itself, through its settings and API keys page, so the bridge inherits exactly the permissions you granted that key. ### How do I install n8n Workflow Builder locally? Run the package with the package runner and no install step. For development you can instead clone the repository, install dependencies, build and start, and the package also builds itself during install. ### What are the requirements for running n8n Workflow Builder? A Node runtime, an n8n instance that can be self-hosted or cloud, and an n8n API key with appropriate permissions. The project is written in TypeScript and uses the current Model Context Protocol SDK. ### Which assistants can use n8n Workflow Builder? Any MCP-compatible client. Configuration is given for Claude Desktop and for the Cline extension, both using the same shape: the package runner as the command, the package as the argument, and the host and key in an environment block. ### Does n8n Workflow Builder contain workflow logic itself? No. It is a bridge to an n8n instance you already run. Everything it does is an operation against that instance through the official API, so all workflow logic lives in n8n. ## Sources - [Issues](https://github.com/makafeli/n8n-workflow-builder/issues) - [License: MIT](https://github.com/makafeli/n8n-workflow-builder/blob/main/LICENSE) - [makafeli/n8n-workflow-builder on GitHub](https://github.com/makafeli/n8n-workflow-builder) - [README](https://github.com/makafeli/n8n-workflow-builder/blob/main/README.md) - [Releases](https://github.com/makafeli/n8n-workflow-builder/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/makafeli-n8n-workflow-builder