n8n MCP Server Tutorial: Expose and Use MCP Tools in n8n

n8n supports the Model Context Protocol in both directions. The MCP Server Trigger node turns a workflow into an MCP server that Claude, Cursor, or any other MCP client can call. The MCP Client Tool node lets an n8n AI Agent call tools on someone else's MCP server. Recent n8n versions also ship an instance-level MCP server that exposes whole workflows to clients from one settings page.

This tutorial walks through each path step by step, using the node names and settings as n8n documents them, then covers security, a construction example built on our Procore community nodes, common mistakes, and when to move beyond n8n.

MCP in one minute

The Model Context Protocol is an open standard for connecting AI applications to outside systems. An MCP server publishes a list of tools, each with a name, a description, and an input schema. An MCP client (Claude Desktop, Cursor, a coding agent, or an agent platform) reads that list and lets a model call the tools. Messages are JSON-RPC, and the current spec defines two standard transports: stdio for local processes and Streamable HTTP for remote servers. Streamable HTTP replaced the older HTTP+SSE transport, which some servers still support for compatibility.

If you want the construction-specific background first (servers vs. gateways, tool routing, governance), read what MCP is and why it matters for construction.

Three ways n8n and MCP fit together

People searching "n8n MCP server" usually mean one of three different things. Pick the right one before you build.

Per n8n's docs, instance-level access is one connection per instance with centralized auth, while the MCP Server Trigger lives inside a single workflow and exposes only that workflow's tools, which suits a specific, hand-crafted MCP server. This tutorial focuses on the trigger and the client tool.

There is also a standalone MCP Client node that calls one MCP tool as a regular workflow step, without an agent. Use it when you already know exactly which tool to call.

Part 1: Expose an n8n workflow as an MCP server

The MCP Server Trigger is unusual for a trigger. It doesn't pass output to a next node. It only connects to tool nodes, and it exposes a URL that MCP clients use to list those tools and call them. It supports Server-Sent Events (SSE) and streamable HTTP. It does not support stdio, which matters for desktop clients (covered below).

Step 1: Build each tool as a sub-workflow

The cleanest pattern is one sub-workflow per tool:

1. Create a new workflow and add the Execute Sub-workflow Trigger (listed under triggers as When Executed by Another Workflow).
2. Set Input data mode to Define using fields below and declare the inputs the tool needs, for example project_id as a number. Calling nodes pull these fields in automatically.
3. Add the nodes that do the work: an API call, a database query, a transformation.
4. End with a node that returns a small, clean result. Agents do better with ten relevant fields than with a raw API payload.
5. Save and publish the sub-workflow.

Publishing is not optional. n8n's docs warn that when a tool calls a sub-workflow from the database in production, the sub-workflow must be published or the call fails with Workflow is not active and cannot be executed, and that error comes back to the model as the tool result, where it's easy to miss.

Step 2: Add the MCP Server Trigger

1. Create a second workflow, which will be your MCP server.
2. Add the MCP Server Trigger node.
3. Leave Path as the randomly generated value, or set your own. n8n generates a random path by default so multiple MCP Server Trigger nodes don't collide. A custom path (route parameters are supported) gives you a stable URL to put in client configs.

Step 3: Attach tools

Connect tool sub-nodes to the trigger. To expose the sub-workflow from Step 1, attach a Call n8n Workflow Tool node (the trigger's docs refer to it as the Custom n8n Workflow Tool) and configure it:

• Description: tell the model when to use the tool and what input it expects. This text is what the client's model sees, so write it like an instruction, not a label.
• Source: choose Database and pick your sub-workflow from the list (or enter its ID).
• Workflow Inputs: select Refresh to pull in the fields you defined. For each field, use a fixed value, an expression, or let the model fill it, either with the AI button next to the field or the $fromAI() function in an expression.

Repeat for each tool. Every tool attached to this trigger is visible to every client that connects to this URL, so group tools by audience, not by convenience.

Step 4: Turn on authentication

In the trigger's Authentication parameter, choose None, Bearer auth, or Header auth. The credentials work the same way as the HTTP Request node's. Use bearer or header auth for anything that touches real project data. A URL is not a secret.

Step 5: Test URL vs. production URL

The node shows two MCP URLs at the top of its panel. Toggle between Test URL and Production URL:

• Test URL: registered when you select Listen for Test Event or Execute workflow while the workflow isn't active. Calls show their data live in the editor. Use it while building.
• Production URL: registered when you publish the workflow. Calls don't display in the editor, but you can review them on the workflow's Executions tab.

Give clients the production URL. A client pointed at the test URL works only while someone has the editor listening, which is the source of many "it worked yesterday" reports.

Connect Claude Desktop and other MCP clients

Claude Desktop to an MCP Server Trigger

Because the trigger speaks SSE and streamable HTTP but not stdio, n8n's docs connect Claude Desktop through a gateway, mcp-remote, that proxies between them. The documented entry for your 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>"
      }
    }
  }
}

Replace <MCP_URL> with the trigger's production URL and <MCP_BEARER_TOKEN> with the token from the trigger's bearer credential. Restart Claude Desktop so it picks up the new server. The model sees your tools through the descriptions you wrote in Step 3.

One documented quirk: claude.ai custom connectors ask users to sign in to n8n even when the trigger's authentication is set to None. n8n says claude.ai is the only client known to do this, because it assumes every MCP endpoint on your domain uses n8n user authentication.

Claude, Cursor, and coding agents via instance-level MCP

If you'd rather expose workflows instance-wide, enable it under Settings > Instance-level MCP (owner or admin required), then mark individual workflows as available. You can toggle Available in MCP in a workflow's settings, enable it from the workflow card menu, or use the Workflows enabled page. Copy the Server URL from the Connect a client dialog. It ends in /mcp-server/http, and it isn't your editor's address.

n8n recommends OAuth, with an API-key option for clients that need a bearer token. The client connection examples give exact steps for Claude Desktop (a custom connector pointed at the server URL), Claude Code, Cursor, VS Code, and other clients.

One security point from the docs: instance-level access isn't scoped per client. Every connected client can see every workflow you've enabled.

Part 2: Use external MCP servers inside an n8n AI Agent

The other direction gives an n8n agent tools that live elsewhere: a vendor's hosted MCP server, an internal server your team runs, or another n8n instance.

1. Add an AI Agent node and connect a chat model. In recent versions, every AI Agent node works as a tools agent, and you must connect at least one tool sub-node.
2. Check the registry first. In the agent's tools panel ("Tool +"), the MCP Servers section lists servers you can connect in one click. You sign in and n8n creates the credential for you.
3. For servers that aren't in the registry, add an MCP Client Tool sub-node.
4. Enter the server's endpoint. The docs list this parameter as SSE Endpoint. Use the URL the server's documentation gives you.
5. Set Authentication: bearer, generic header, multiple headers (for servers that need, say, an API key plus a username), or OAuth2. The MCP OAuth2 credential supports Dynamic Client Registration, which is on by default, so n8n can register itself with servers that support it.
6. Set Tools to Include: All, Selected, or All Except. Choose Selected unless you have a reason not to.

n8n's docs note the tradeoff: a built-in tool node gives tighter control because you fix the operation and pin parameters, while an MCP server gives the agent more room at the cost of control and more context per call. If the agent needs one action, use the node.

How to secure an n8n MCP server

An MCP endpoint backed by a Procore or ERP credential is a production integration a model can trigger.

• Always authenticate. Bearer or header auth on the MCP Server Trigger. OAuth for instance-level access, and restrict Allowed callback URLs to trusted URLs instead of the default "any".
• Use the production URL for clients, and keep the workflow published. Never hand out the test URL.
• Least privilege on the backend credential. The n8n credential behind your tools defines what any connected client can do. If it's an admin token, every client effectively has admin rights.
• Expose the smallest tool set. One trigger per audience, read-only tools first, Selected instead of All on the client side.
• Keep results narrow. Return the fields the question needs, not the whole API response.
• Review executions. Production calls land on the Executions tab. Look at them weekly: what was called, with what inputs, and what failed.
• Add writes deliberately. One workflow at a time, with validation in the sub-workflow and human approval where the impact warrants it. For n8n's own agents, n8n documents human-in-the-loop review for agent tools. For tools that external clients call through the trigger, build the approval into the sub-workflow before it writes anything.

These match the principles we apply everywhere: least privilege by default, evidence on every output, and boring where it counts. The longer version is in governing AI agents in construction.

Construction example: a Procore RFI lookup as an MCP tool

Here is an example pattern, not a description of a specific client deployment. The goal: a project manager in Claude Desktop asks "What RFIs are still open on the Main Street job?" and gets an answer from live Procore data, without anyone handing Claude a Procore token.

1. Install the nodes. Our n8n-nodes-procore package provides Procore triggers and actions for n8n, and n8n-nodes-buildflows bundles Procore, Autodesk, HCSS, and Power BI in one node pack. Install either as a community node, then create a Procore credential scoped to a service account with read access to the projects in question.
2. Build the sub-workflow get_open_rfis. Execute Sub-workflow Trigger with a project_id input, then a Procore node configured to list the project's RFIs (an HTTP Request node against the Procore API works too if you need an operation the node doesn't cover), then a filter for open items, then an Edit Fields (Set) node that keeps number, subject, ball-in-court, and due date.
3. Build a second sub-workflow find_project that takes a name fragment and returns matching project IDs. Many Procore calls need IDs the user doesn't know, so give the model a way to look them up instead of guessing.
4. Create the server workflow. An MCP Server Trigger with bearer auth and a custom path such as procore-readonly, plus two Call n8n Workflow Tool nodes pointing at the sub-workflows. Write descriptions like: "Find Procore project IDs by name. Call this before any project-specific tool."
5. Publish all three workflows and give the production URL and token to the people who need them, through the mcp-remote config above.

The same shape works for Autodesk document lookups with n8n-nodes-autodesk. You can see the nodes in action in the n8n construction nodes demo. For the Procore side of the integration (auth, company and project IDs, rate limits), see our Procore API integration guide.

Troubleshooting: common n8n MCP mistakes

When to graduate to a dedicated MCP server or gateway

n8n is a fast way to put a handful of well-described, workflow-shaped tools in front of an AI client. It starts to strain when:

• The tool count grows into the hundreds. Each tool's description and schema goes into the model's context. Generating one tool per endpoint from Procore's OpenAPI specs produced 2,755 tools in our Procore MCP server, which is why we route through a small set of discovery and dispatch meta-tools instead. See routing 2,755 Procore API tools.
• Different users need different tools. A trigger exposes the same tools to everyone with the URL, and instance-level access isn't scoped per client. A gateway can issue per-key access to specific servers and tools, with rate limits.
• You need audit-grade telemetry. The Executions tab is fine for debugging, not for answering "who called what, with which inputs, across every server" for security review. Our Tool Runtime gateway logs organization, user, key, server, input, and output on every call. More in MCP gateway telemetry.
• Multiple organizations share the deployment. Tenant isolation of credentials belongs in the server or gateway, not in workflow conventions.

The common end state is a mix: purpose-built MCP servers for large APIs, a gateway in front, and n8n handling workflow-shaped tools and automations.

Where to go next

• Watch the n8n construction nodes demo to see Procore, Autodesk, HCSS, and Power BI in one workflow layer.
• Read what MCP is and why it matters for construction for servers, gateways, and governance in depth.
• See how a gateway controls access and logs every call in the Tool Runtime demo.
• Want your project data reachable by AI under rules you set? Tell us what you want to build.