Before a meeting, a sales manager wants to ask Claude where a client's file stands and whether the client has paid the last invoice. The answers live in the CRM and in the invoicing tool. The fastest fix would be to plug the assistant straight into those tools with an account that can see and change everything. Nobody wants to grant that level of access, especially to invoicing.
A middle path is to expose a few n8n workflows to Claude, each limited to one specific action, such as finding a client record or returning an invoice status. The assistant sees those tools and never the whole CRM. The credentials stay in n8n, and every call leaves a trace in the execution history.
Here is how an n8n MCP server built with the MCP Server Trigger node works, which actions to expose first, which ones to keep out of reach, and how to run it on a self-hosted instance.
What is an n8n MCP server
According to its official documentation, the Model Context Protocol (MCP) is an open-source standard for connecting AI applications such as Claude to external systems. The specification describes what a server can offer a client: resources, prompt templates and tools, meaning functions the model can execute.
The MCP Server Trigger node turns n8n into an MCP server. It exposes a URL that MCP clients call. Unlike other triggers, it connects only to tool nodes, which it runs.
To turn an existing workflow into a tool, you attach it to the trigger with the Custom n8n Workflow Tool node, now documented as Call n8n Workflow Tool. The chain: Claude calls the n8n MCP URL, n8n runs the "find client record" sub-workflow, and that sub-workflow queries the CRM with its own credentials and returns a handful of fields.
Why go through n8n instead of connecting each tool directly
Specific actions instead of full access. A direct connection gives the assistant everything the connected account can do. An n8n tool only does what its workflow defines.
Credentials stay in n8n, and every call is traced. Claude authenticates with n8n, n8n authenticates with the CRM, and every call becomes an execution you can inspect in the Executions tab. The MCP security best practices describe "token passthrough", forwarding to an API a token that was not issued for the MCP server, as an anti-pattern forbidden by the MCP authorization specification. Here, Claude's token only opens n8n.
Reuse. An existing workflow, like the one in the article on Plaud, n8n and MCP, becomes a tool without a rewrite. On splitting roles, see also n8n and Claude Code: making them work together.
Which actions to expose to Claude, and which to keep away
I recommend moving in levels, reviewing the logs before each step up.
| Level | Examples | Rule |
|---|---|---|
| Targeted read | Client record, invoice status, order status | Few fields returned, capped number of results |
| Reversible write | Add a CRM note, create a task, prepare a draft | Every write tagged as coming from the assistant |
| Action with approval | Send a quote, change a due date, follow up with a client | The tool creates a request, a person approves |
| Out of scope | Payments, transfers, bank detail changes, deletions, bulk sends, permission management, full export | No MCP tool |
For the third level, I advise against keeping the MCP call waiting during the human decision. The tool records the request and replies "request created, awaiting approval", then a separate workflow gets the approval of the person in charge before acting. See the article on human approval for AI agents.
Be careful as well with tools that read text coming from outside the company (emails, meeting notes): it can contain hidden instructions. Do not put such a tool on the same server as a tool that sends anything outside the company.
Configuring the MCP Server Trigger in n8n
The path. By default, the node generates a random URL path, which does not replace authentication.
The two URLs. The documentation distinguishes the test URL, active when you listen for a test event in the editor, from the production URL, registered when the workflow is published. Never hand the test URL to users.
One published sub-workflow per tool. With the "Database" source, the called sub-workflow must be published for runs in production (the test panel is not affected). Otherwise, according to the node documentation, the production call fails with the error Workflow is not active and cannot be executed, which is returned to the model as the tool result. The user only reads that the assistant could not find the information.
The description. The Description field tells the model when to use the tool. It says what the tool does, what it expects and what it does not do: "Finds a client record from the client's name or SIREN (French company registration number). Returns the name, main contact and status. Changes nothing."
The parameters. Sub-workflow inputs can be fixed, computed with an expression, or left to the model, notably with the $fromAI() function. Fix everything the model has no reason to choose (pipeline, maximum number of results) and leave it only the search term. The sub-workflow then checks the values it receives.
The server instructions. This optional field, sent to clients on connection, is usually added to the system prompt by clients that support it. It guides the model but protects nothing: a real restriction belongs in the workflow or in permissions.
Authentication and access rights
The node offers four options:
| Option | What it does | Recommended use |
|---|---|---|
| None | No check | Never on a production URL |
| Bearer auth | A shared token in the Authorization header | A small group, one token per server |
| Header auth | A custom header | Same logic as bearer |
| n8n User Auth (OAuth2) | Each caller signs in with their n8n account and grants consent | Larger teams, one access per person |
With a bearer or header token, anyone holding the token can reach every tool on the server without being identified.
The n8n User Auth (OAuth2) option is available from version 2 of the node. It adds three settings. Require Workflow Execute Permission, on by default, requires the user to have permission to execute the workflow in their project. Trusted Source Name or ID designates the identity provider whose tokens are accepted. Include User in Output, from version 2.1, passes the caller's ID, email and name into the trigger output and into the request the connected tools receive.
The documentation does not say that this data reaches a sub-workflow called through Call n8n Workflow Tool, which receives its defined inputs. If a sub-workflow needs to filter by person or log a name, design it explicitly, for example with a user field among its inputs. Then check that this field really holds the caller and that the model cannot fill it in.
I also recommend one server per group of users, for example one for the sales team and one for accounting, rather than a single server exposing everything to everyone.
Connecting Claude Desktop and claude.ai
The MCP Server Trigger supports two transports, Server-Sent Events (SSE) and streamable HTTP, but not standard input/output (stdio).
Claude Desktop. The n8n documentation suggests going through a gateway, mcp-remote, launched with npx, which relays SSE messages to stdio. The Claude Desktop configuration looks like this:
{
"mcpServers": {
"n8n": {
"command": "npx",
"args": ["mcp-remote", "<MCP_URL>", "--header", "Authorization: Bearer ${AUTH_TOKEN}"],
"env": { "AUTH_TOKEN": "<MCP_BEARER_TOKEN>" }
}
}
}
The token is then stored on each computer. Keep a record of who has one, and rotate it when someone leaves the company.
claude.ai. According to the n8n documentation, claude.ai custom connectors ask you to sign in to n8n even when authentication is set to None. The instance offers n8n user authentication for other triggers, and claude.ai assumes every MCP endpoint on the domain uses it. My inference (the documentation does not say this) is that n8n User Auth is the most consistent option with claude.ai. It means one n8n account per user: check what your n8n edition and licence allow for multiple users.
Another consequence: according to Claude's help center, Claude reaches custom connectors from Anthropic's cloud infrastructure, not from the user's device. The server must be reachable over the public internet from Anthropic's IP addresses; behind a VPN or on a private network, it will not connect. A self-hosted instance therefore has to be exposed to the internet. I then recommend HTTPS, authentication on every MCP URL and, if claude.ai is the only client, filtering on Anthropic's addresses. The same page lists access conditions by Claude plan.
Consent. The MCP specification (version 2026-07-28) asks host applications to obtain explicit user consent before invoking a tool. Clear descriptions and a short training session for your teams help everyone understand what they are approving.
Finally, whatever a tool returns goes to the model provider: return the minimum number of fields. To choose a model according to data sensitivity, see open vs proprietary AI models.
Running an n8n MCP server in production
The reverse proxy. SSE and streamable HTTP rely on persistent connections. Behind nginx, the documentation asks you to disable proxy buffering for the MCP endpoint, as well as gzip compression (n8n handles it) and chunked transfer encoding, and to clear the Connection header:
location /mcp/ {
proxy_http_version 1.1;
proxy_buffering off;
gzip off;
chunked_transfer_encoding off;
proxy_set_header Connection '';
}
For a setup on Hetzner and Coolify, see the article on the self-hosted stack.
Queue mode. With several webhook replicas, all /mcp* requests must go to one dedicated replica. Otherwise, the documentation warns, connections drop often or deliver events incorrectly.
Logs. For a weekly review, each tool can write to a table: date, tool, parameters, number of results, and the user if you passed it to the sub-workflow. Check how long executions are retained, since they contain client data.
Alerts. Set an error workflow on every sub-workflow, and turn business anomalies into errors with Stop and Error, as described in the article on n8n error handling. An error returned to the model as text alerts nobody. After every n8n update, test Claude's connection and one call of each tool.
Pre-launch checklist
- The list of tools is written down, and the first batch is read-only.
- No tool pays, deletes, sends in bulk or changes permissions.
- Each sub-workflow has dedicated credentials with minimum rights, and checks its inputs.
- The production URL is protected by authentication, never None.
- An error workflow alerts someone when a tool fails.
- The reverse proxy and replica routing are configured for
/mcp*. - Someone owns the server, with a backup, and reviews the logs every week.
Start small
Begin with two or three read-only tools, open to a few people. Review the logs for a few weeks (failed calls, data that left the company), then expand one tool at a time. At Kirako, we design n8n automation and AI agents, including this kind of MCP server.
Sources
Consulted on 9 November 2026: n8n documentation (MCP Server Trigger, Call n8n Workflow Tool), Model Context Protocol (introduction, specification, version 2026-07-28, security best practices), Claude help center (custom connectors using remote MCP).
Also available: Read in French