n8n-MCP

Every management tool uses a single long-lived n8n API key supplied in the environment, so the model acts with whatever the key's owner can do on the instance. The server does not ask for a scoped key, split read and write credentials, or check individual requests against a policy; its only narrowing is an operator list of tools or operations to switch off, which is empty by default. Because workflows can use any credential stored in n8n, a misused session reaches every service the instance is connected to.

As a tool server, n8n-MCP leaves approval to the MCP host and gives it risk annotations on every tool. Several tools bundle reads and writes behind one name (for example list, get and delete of executions), and the annotations are not accurate on every mutating tool, so a host cannot always tell a read from a destructive call. There is no read-only mode or server-side confirmation by default; an operator can switch off individual operations, and the server then recomputes the annotations. Workflow edits are backed up locally before they are applied and can be rolled back, but deletes and workflow runs cannot be undone.

Tool arguments are validated with typed schemas, identifiers are encoded before they go into API paths, and the server's own outbound requests pass a careful URL guard that blocks internal and metadata addresses, pins DNS and refuses redirects. But the central tools take whole workflow definitions and agent arguments and pass them to n8n as they are, with no restriction on node types, so the model can build workflows that run code or call any host. All tools are enabled by default; an operator can switch off individual tools or operations.

The server never runs model-written code itself, but it lets the model create workflows containing code and command nodes and run them on the n8n instance, and run n8n agents that use real tools. n8n-MCP adds no isolation of its own around this; its maintainers state that n8n is the security boundary and point to n8n's own Code-node sandbox and settings. Whatever code runs has network access and can use the instance's stored credentials.

The model reads content that others can write: execution data from workflows triggered by outside events, workflow names, notes and parameters, community templates and third-party node documentation. Results come back in a consistent JSON envelope, but nothing marks this content as untrusted or records where it came from, and the default tool set holds no read-only or no-egress mode. The same session can read instance data and create, run or delete workflows, so a successful injection can both leak data and act irreversibly without the server involving a human.

The server keeps no memory that is fed back to the model as instructions; its local store holds workflow backups. At startup, however, it reads settings from the directory it is launched in, without any trust decision. When the host is opened inside a repository, that repository can therefore change the server's configuration, including which tools are offered and how outbound URLs are checked, for every launch from that directory.

The server loads no plugins, MCP servers, downloaded tools or model files at runtime; its tools, templates and documentation are bundled with the package. The optional connection to the n8n instance's own MCP endpoint is a remote API on the operator's instance, and its output is treated in the untrusted-input criterion. How the server itself is installed (npx) is the project's own supply chain and out of scope here.

The API key comes from the environment and is never put into tool output, and credential secrets returned by n8n are stripped before the model sees them. Logs record only argument metadata, not values. Telemetry is on by default and sends tool usage, workflow-change intents and sanitized workflow structures, including surviving node parameters, to the maintainer's telemetry service; sanitization is pattern-based. Workflows returned to the model are not scrubbed of secrets hard-coded in node parameters.

In the default stdio mode the logger drops all output, so tool calls are not recorded anywhere the operator can read. The only durable trace is the local backup store, which saves the previous version of a workflow, with the trigger that caused it, before full or partial updates; deletes, runs and credential changes leave no record. The model can delete or prune those backups with its own tool, and a failed backup does not stop the update.

The server bounds its own work in several places: API calls time out after 30 seconds by default, webhook calls after two minutes, responses over 1 MB are truncated and execution data is trimmed to a couple of items unless asked for more. The model can raise agent and lookup timeouts to ten minutes and request all execution items, and there is no rate or concurrency limit. Workflow and agent runs it starts keep running in n8n after a timeout or after the session stops.