n8n MCP Server Cursor IDE Setup (2026)

How do you connect Cursor to n8n? n8n can act as an MCP server two ways: drop an MCP Server Trigger node into a single workflow and connect Tool nodes to it, which exposes only that workflow's tools; or turn on instance-level MCP access in your n8n settings, which lets you expose tools from multiple workflows through one centralized, authenticated connection. Either way, you add an entry to ~/.cursor/mcp.json pointing at the resulting URL, and Cursor can then call whatever tools you've wired up.

This page works differently from most setup guides on this site. Everywhere else, you're connecting Cursor to a vendor's fixed, pre-built tool set — GitHub's API surface, Stripe's endpoints, whatever the vendor shipped. With n8n, you build the tools. The MCP Server Trigger just exposes whatever nodes you've connected to it as callable functions. That's the actual value: turning a multi-step business process (call an API, transform the response, write to a database, post to Slack) into one thing Cursor can invoke as a single tool call, instead of Cursor trying to orchestrate five separate MCP servers itself.

What This Setup Is Good For (and What It Isn't)

If you just want Cursor to read your Airtable base or post to Slack, use Airtable's or Slack's own MCP server directly — that's less indirection and one less thing to maintain. Reach for n8n's MCP Server Trigger when the thing you want Cursor to call is actually a workflow: multiple steps, conditional logic, or a sequence you've already built in n8n and don't want to re-describe to the AI every time. "Look up this customer, check three different systems for their status, and post a summary to the ops channel" is a good candidate. "Read one Notion page" is not — just use Notion's MCP server.

Prerequisites

Method 1: MCP Server Trigger (Single Workflow, Fastest to Set Up)

Use this to expose one specific workflow's tools without touching instance-wide settings.

Step 1: Add the MCP Server Trigger Node

In your n8n workflow editor, add an MCP Server Trigger node as the workflow's trigger. Connect the Tool nodes you want exposed — each connected tool becomes a callable function for MCP clients.

Step 2: Note the Test URL vs. Production URL

The node shows two URLs, and mixing them up is the most common first-setup mistake:

Point Cursor at the Test URL while you're building and debugging the tool chain; switch to the Production URL only once the workflow is active, or every call will fail.

Step 3: Set Authentication

The node supports three auth modes: Bearer Token, Header Auth (a custom header/value pair), or None. Don't leave a Production URL on None if the workflow touches anything sensitive — an unauthenticated MCP endpoint is just an open webhook that happens to speak MCP.

Step 4: Add to ~/.cursor/mcp.json

For a Bearer Token-secured Production URL, use the mcp-remote proxy:

{
  "mcpServers": {
    "n8n": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "<YOUR_PRODUCTION_URL>",
        "--header",
        "Authorization: Bearer ${AUTH_TOKEN}"
      ],
      "env": {
        "AUTH_TOKEN": "<YOUR_MCP_BEARER_TOKEN>"
      }
    }
  }
}

Replace the URL and token with the values from the node's parameters panel.

Method 2: Instance-Level MCP Access (Multiple Workflows, Centralized)

Use this once you have more than a couple of workflows you want exposed, and want one connection and one auth setup covering all of them instead of a separate mcp.json entry per workflow.

Step 1: Enable Instance-Level MCP Access

In your n8n instance's settings, turn on MCP access and choose which workflows are enabled for it.

Step 2: Choose Authentication

Step 3: Add to ~/.cursor/mcp.json

{
  "mcpServers": {
    "n8n": {
      "type": "http",
      "url": "https://<your-n8n-domain>/mcp-server/http",
      "headers": {
        "Authorization": "Bearer <YOUR_N8N_MCP_TOKEN>"
      }
    }
  }
}

Swap in an OAuth-based config instead if that's the auth method you picked — check your n8n instance's OAuth tab for the exact client details, since those are generated per-instance.

Restart Cursor and Verify

Quit and reopen Cursor. Test in chat with a prompt that should trigger one of your connected tools — for example, if you built a workflow that looks up a customer record:

Look up customer ID 4821 using the n8n tool

If real data comes back (or a sensible error from the underlying step, like "customer not found"), the connection and auth are working.

Practical Workflows

Multi-Step Customer Lookup

Build a workflow that queries your CRM, your billing system, and your support ticket history for a given customer, then merges the results. Expose it via MCP Server Trigger, and Cursor can answer "what's going on with customer X" in one call instead of you manually checking three tabs.

Turn a Recurring Manual Process into a Tool

If you already have an n8n workflow that, say, generates a weekly report by pulling from two APIs and formatting the output, exposing it via MCP means you can ask Cursor to "run this week's report" from chat instead of triggering it manually in n8n.

Gate Access Through Existing Workflow Logic

Because the exposed "tool" is really a workflow, you can put approval steps, rate limiting, or conditional branches inside it — logic that a raw API-wrapping MCP server wouldn't have — before the actual action happens.

The Reverse Direction: n8n Calling Other MCP Servers

Worth knowing this exists so you don't confuse the two: n8n also has an MCP Client node, which lets an n8n workflow call other MCP servers as part of its own automation — the mirror image of what this guide covers. This page is about exposing n8n workflows to Cursor; the client-side direction (n8n calling out to, say, a GitHub or Slack MCP server from inside a workflow) is a separate setup with its own node and credentials.

Troubleshooting

Test URL stops responding
Expected — it's only live while "Listen for Test Event" is active in the editor. Reactivate listening mode, or switch to the Production URL if the workflow is published.

Production URL returns a 404 or connection error
The workflow isn't active. The MCP Server Trigger's Production URL only responds once you've published the workflow, not just saved it.

"Unauthorized" on every call
Confirm the auth mode set on the trigger node (Bearer Token, Header Auth, or None) matches what you configured in mcp.json. A mismatched header name or a stale token is the usual cause.

Cursor connects but no tools show up
Check that you actually connected Tool nodes to the MCP Server Trigger — the trigger alone exposes nothing. Each tool the AI can call has to be an explicit node wired into it.

Instance-level access doesn't show a workflow you expect
Confirm that specific workflow was enabled for MCP access in the instance settings — enabling instance-level access overall doesn't automatically expose every workflow you have.

Frequently Asked Questions

Q: What's the actual difference between the MCP Server Trigger and instance-level MCP access?
A: The MCP Server Trigger is configured inside a single workflow and exposes only the Tool nodes connected to that one trigger. Instance-level access is a separate, centralized connection covering multiple workflows at once, with its own OAuth2 or access-token authentication independent of any single workflow's settings.

Q: Why does my Test URL stop working when I switch tabs?
A: The Test URL is only active while the workflow is in test/listening mode in the editor — it's meant for building and debugging, not ongoing use. For a connection that stays live, publish the workflow and use the Production URL instead.

Q: Is authentication required on the MCP Server Trigger?
A: No, "None" is a valid option, but it means the endpoint is unauthenticated — anyone with the URL can call it. Use Bearer Token or Header Auth for any workflow that touches real data or takes real actions.

Q: Should I use n8n's MCP Server Trigger instead of a vendor's official MCP server?
A: Not as a replacement — use the vendor's own MCP server (Slack's, Airtable's, GitHub's) for direct access to that single tool. Reach for n8n's MCP Server Trigger when what you want to expose is a multi-step workflow with its own logic, not a single API call you could make directly.

Q: Can n8n both expose tools to Cursor and call other MCP servers itself?
A: Yes, but those are two separate features. The MCP Server Trigger (covered here) exposes n8n workflows outward to clients like Cursor. A separate MCP Client node lets a workflow call out to other MCP servers as part of its own automation — the two can be combined in the same n8n instance but are configured independently.

Q: If what I actually want is AI-driven admin work inside an internal-tools platform, not workflow automation — is that a different server?
A: Yes. n8n's MCP Server Trigger is for exposing your own workflow logic as tools. If instead you want an AI client to manage users, audit access, or query connected resources inside an internal-tools platform like Retool, that's a separate vendor server — see the Retool MCP server setup guide.

Related Guides

---