n8n Workflow Builder MCP Server: Natural Language Workflow Management for n8n via AI Assistants

The Gap This Server Fills Between AI Assistants and n8n

n8n is a self-hosted workflow automation platform. Its web interface handles workflow creation and management visually, but accessing it requires switching out of a development context to a browser. The n8n Workflow Builder MCP Server implements the Model Context Protocol, which allows AI assistants that support MCP (Claude Desktop, Cline for VS Code, and other compatible clients) to communicate with n8n through a structured tool interface. Once configured, a developer can ask an AI assistant to list workflows, create a new one, activate an existing automation or check execution status, all in the same conversational session where they are already working. The server translates those requests into calls against the n8n REST API and returns the structured results to the assistant as tool call responses.

What the Server Can and Cannot Do

The README describes the core capabilities as full CRUD operations: list existing workflows, create new ones with complex node configurations, execute workflows on demand, activate and deactivate workflows, update definitions and delete workflows. The server communicates with n8n through its official REST API, so it requires an n8n API key with appropriate permissions granted in the n8n settings panel. Anything the n8n REST API does not expose is not accessible through this server. Complex visual workflow layouts, drag-and-drop node positioning and the n8n canvas experience remain in the n8n web UI. The server is a programmatic control layer, not a replacement for the visual editor. It also does not store credentials or workflow state independently: everything goes through the connected n8n instance.

Installing and Configuring the Server

The server is published to npm as @makafeli/n8n-workflow-builder and requires Node.js 18.0.0 or later. The quickest path is running it with npx without any local installation:

npx @makafeli/n8n-workflow-builder

Two environment variables are required: N8N_HOST (the URL of your n8n instance, such as http://localhost:5678) and N8N_API_KEY (your n8n API key, generated from Settings then API Keys in the n8n interface). Set them before starting the server:

export N8N_HOST="http://localhost:5678"
export N8N_API_KEY="your-api-key-here"
npx @makafeli/n8n-workflow-builder

For development or customization, clone the repository, install dependencies and build:

git clone https://github.com/makafeli/n8n-workflow-builder.git
cd n8n-workflow-builder
npm install
npm run build
npm start

Node.js version 18.0.0 or later is required.

Wiring Up Claude Desktop and Cline

To add the server to Claude Desktop, edit the claude_desktop_config.json file and add an entry under mcpServers:

{
  "mcpServers": {
    "n8n-workflow-builder": {
      "command": "npx",
      "args": ["@makafeli/n8n-workflow-builder"],
      "env": {
        "N8N_HOST": "http://localhost:5678",
        "N8N_API_KEY": "your-api-key-here"
      }
    }
  }
}

The same JSON structure works for Cline under its MCP settings. Claude Desktop starts the npx process when it needs the server and passes the environment variables directly. The README also describes a hosted option on Smithery.ai where the server runs remotely, requiring no local installation. With Smithery, you configure the n8n host and API key in the Smithery interface and connect from any MCP-compatible client without managing a local process.

Repository State and the Smithery Hosted Option

The package on npm is currently versioned 0.11.0 as declared in package.json, while the most recent GitHub release is v0.10.1, tagged in July 2025. The server is written in TypeScript and compiles to CommonJS modules in the build/ directory. The src/ directory contains the TypeScript source, and the dist/ directory holds an alternative build artifact. The test suite uses Jest and is divided into unit and integration test paths, with separate jest.config.cjs and jest.config.ci.cjs configurations for local and CI runs. A separate smithery.yaml and tsconfig.smithery.json configure the Smithery.ai deployment target, which is the hosted path the README recommends as the primary installation method. The RELEASE_SETUP.md and SMITHERY_DEPLOYMENT.md files document the processes for publishing new npm versions and deploying to Smithery respectively. The repository includes additional documentation files covering use cases (e-commerce, data processing, API integrations), a comparison with alternatives and a troubleshooting guide. The last push to the repository was on 2026-03-19, and no update has been made since.

How This Compares to n8n's Web UI and to Zapier

The repository includes a COMPARISON.md that positions the MCP server against several alternatives. The n8n web UI offers the canvas-based visual editor, which is the right tool for designing new workflows, debugging node connections or working with n8n's credential UI. The MCP server is intended for operational tasks: reading what is deployed, triggering a run, activating or deactivating a workflow without leaving your AI assistant session. The USE_CASES.md file in the repository describes practical scenarios including e-commerce automation, data processing pipelines and API integrations, which give a sense of the kinds of workflows this server is most useful for managing conversationally. Against Zapier and Make.com, the key difference is that n8n itself runs on your infrastructure or cloud account, and the MCP server is just an API bridge to it. Zapier and Make.com are managed platforms where the automation runs externally and workflows are created through their own interfaces. The MCP server does not replicate those platforms: it is a control plane for an n8n deployment you already manage. If you are evaluating whether to use n8n at all versus Zapier, that decision happens before this server is relevant.

Where the MCP Approach Has Limits

MCP clients send tool calls to the server and receive structured responses, but building a workflow through conversation still requires the AI assistant to construct valid n8n node configuration JSON. If the assistant generates an incorrect node schema, the n8n API will return an error and the workflow will not be created. There is no visual preview of a workflow before it is submitted. Users who regularly create complex multi-step workflows with custom node configurations may find the web UI more reliable for the initial creation step and use the MCP server primarily for status checks and simple activations. The server also does not handle n8n's credential management: API keys, OAuth tokens and other credentials that n8n workflows depend on must be configured in the n8n interface directly. N8N_HOST must include the full base URL of your instance including the /api/v1 path when using a self-hosted instance behind a reverse proxy, since a misconfigured host URL is a common source of authentication failures. The README provides a dedicated TROUBLESHOOTING.md for common connection and authentication errors, which is worth consulting before raising a support question.

Editorial conclusion

Teams already using n8n who also use a Claude Desktop or MCP-compatible AI assistant will find the bridge useful for managing and triggering workflows without switching applications. Users who do not have a running n8n instance or who have no MCP-capable AI assistant get no benefit. The last push to the repository was on 2026-03-19. Anyone adopting it for a production integration should verify the current state of the source code against the v0.10.1 release from July 2025, as no push has occurred since March 2026.

Frequently asked questions

Official sources

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