Which integrations are available for this server?

Allows listing n8n workflows, triggering specific workflows with custom data, and calling webhooks (GET and POST) on n8n workflows.

How do I use MCP n8n API Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP n8n API Server list all my workflows" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

MCP n8n API Server

by ahmadsoliman

Overview Schema Source Related Servers Discussions Admin

JavaScript

Hybrid

MCP n8n API Server

An mcp server that provides an interface to interact with n8n workflows through the Model Context Protocol (MCP).

Features

List all n8n workflows
Trigger specific workflows with custom data
Integration with Claude Desktop and other MCP clients

Related MCP server: n8n MCP Server

Installation

Global Installation (Recommended for Remote Usage)

npm install -g @ahmad.soliman/mcp-n8n-server

Then configure your n8n connection:

Create a .env file in your working directory
Add your n8n API information (see Configuration section below)

Using with npx (No Installation Required)

You can run the server directly with npx:

npx -y @ahmad.soliman/mcp-n8n-server

Local Installation

git clone https://github.com/ahmadsoliman/mcp-n8n-server.git
cd mcp-n8n-server
npm install

Configuration

Create a .env file with the following variables:

# n8n Host URL (required)
N8N_HOST_URL=https://your-n8n-instance.com

# n8n Project ID (optional - only needed for cloud instances)
PROJECT_ID=your_project_id_here

# n8n API Key (required)
N8N_API_KEY=your_api_key_here

Usage

As a Remote MCP Server

After installing globally, you can use it as a remote MCP server with Claude AI:

Configure Claude AI to use this as a remote MCP server using the following JSON configuration:

{
  "mcpServers": {
    "n8n": {
      "command": "npx",
      "args": ["-y", "@ahmad.soliman/mcp-n8n-server"],
      "env": {
        "N8N_HOST_URL": "",
        "PROJECT_ID": "",
        "N8N_API_KEY": ""
      }
    }
  }
}

Add the following to your prompt or instructions to Claude:

You have access to a remote MCP server for n8n integration. Use it to:
- List all n8n workflows
- Trigger webhooks and workflows
- Get information about available webhooks

As a Local MCP Server

You can run the server locally and connect to it from Claude Desktop:

# Start the server
npm start

Then configure Claude Desktop to use this MCP server:

Edit ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "n8n": {
      "command": "npx",
      "args": ["-y", "@ahmad.soliman/mcp-n8n-server"],
      "env": {
        "N8N_HOST_URL": "",
        "PROJECT_ID": "",
        "N8N_API_KEY": ""
      }
    }
  }
}

Alternatively, if you've cloned the repository locally:

{
  "mcpServers": {
    "n8n-server": {
      "command": "node",
      "args": ["/ABSOLUTE/PATH/TO/server-n8n/build/index.js"]
    }
  }
}

Setup

Install dependencies:

npm install

Configure environment variables:

Copy .env.example to .env (if not already done)
Update the following variables in .env:
- N8N_API_URL: Your n8n instance URL (default: http://localhost:5678)
- N8N_API_KEY: Your n8n API key

Start the server:

# Start the MCP server (for integration with Claude Desktop and other MCP clients)
npm run mcp

For development with auto-reload:

npm run dev

MCP Tools (for LLM Integration)

The MCP server exposes the following tools for use with Claude Desktop or other MCP clients:

List Workflows

The list-workflows tool returns a list of all available n8n workflows.

List Workflow Webhooks

The list-workflow-webhooks tool returns all webhooks from a specific workflow.

Parameters:

id: The ID of the workflow to get webhooks from

Call Webhook (GET)

The call-webhook-get tool allows calling a webhook with a GET request.

Parameters:

url: The webhook URL to call

Call Webhook (POST)

The call-webhook-post tool allows calling a webhook with a POST request.

Parameters:

url: The webhook URL to call
data: Data to send in the POST request body

Available Tools

4 tools

call_webhook_getB

Call a GET webhook

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	The webhook URL to call

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided to disclose safety or side effects. Description only states action, not behavior like idempotency, timeouts, error handling, or data effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single, concise sentence. While minimal, it is appropriately sized for a simple tool with one parameter. No unnecessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and minimal description, the tool lacks completeness. No information on return values, URL validation, or behavior expectations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with parameter 'url' described. Description adds no extra meaning beyond schema, meeting baseline expectation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description explicitly states verb 'call' and resource 'GET webhook', clearly differentiating from sibling 'call_webhook_post' by specifying HTTP method.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like 'call_webhook_post' or when not to use it. Lacks context for selecting among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

call_webhook_postC

Call a POST webhook

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	The webhook URL to call
`data`	Yes	Data to send in the POST request body

TDQS

C2.7/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description does not disclose any behavioral traits such as side effects (e.g., triggering external actions), idempotency, or authorization requirements. The agent cannot assess the tool's safety or impact.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at four words, which is efficient and front-loaded. However, it could be slightly more informative without becoming verbose, hence a 4 rather than 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a network operation like a webhook call, the description lacks completeness: no mention of HTTP behavior, potential errors, rate limits, or return values. Without output schema or behavioral notes, the agent is under-informed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds no meaning beyond the input schema, which already describes both parameters (url and data) with 100% coverage. The schema provides sufficient detail, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Call a POST webhook' clearly identifies the action (call) and resource (POST webhook), and implicitly distinguishes from the sibling 'call_webhook_get' by specifying the HTTP method. However, it lacks further context about what calling a webhook entails.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no explicit guidance on when to use this tool versus alternatives such as 'call_webhook_get' or 'list_workflows'. The agent must infer usage from the name and sibling list, which is insufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_workflowsA

Get all n8n workflows

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden but only states it retrieves all workflows; does not discuss return format, pagination, or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no filler, directly conveys the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and simple behavior, the description is mostly complete but could mention expected response structure for better guidance.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so schema coverage is 100% trivially; description adds nothing beyond schema, but baseline is 4 for zero-param tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the action ('Get') and resource ('all n8n workflows'), distinguishing it from sibling tools focused on webhooks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives; no mention of limitations or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_workflow_webhooksB

Get all webhooks in a workflow

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	The ID of the workflow to get webhooks from

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description only says 'Get all webhooks in a workflow', which implies a read operation but lacks details on permissions, pagination, or error behavior. The description carries the full burden but adds minimal behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no extraneous information, perfectly concise for the purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is minimal but adequate for a simple list operation with one required parameter. However, it does not specify output format, pagination, or handling of missing workflows, leaving some gaps for a tool with no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameter 'id' is already documented in the schema. The tool description adds no further semantic meaning beyond what the schema provides, resulting in baseline score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description specifies a clear action ('Get') and resource ('all webhooks in a workflow'), distinguishing it slightly from siblings like list_workflows or call_webhook_get, but does not explicitly differentiate usage.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., call_webhook_get for specific webhook calls). The description merely states what it does, not when to prefer it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv1.0.3Jun 12, 2026
- First observedcall_webhook_get
- First observedcall_webhook_post
- First observedlist_workflow_webhooks
- First observedlist_workflows

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.4/5.0

Scored 2026-06-12 10:56 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: two for calling webhooks with specific HTTP methods, and two for listing workflows and their webhooks. No ambiguity.

Naming Consistency5/5

All tool names follow the verb_noun pattern in snake_case, with modifiers for method variation. The naming is predictable and consistent.

Tool Count5/5

With 4 tools, the count is well-scoped for a focused API server that covers both webhook invocation and workflow/webhook listing.

Completeness3/5

The tool set covers core operations for webhooks and workflow listing, but lacks create/update/delete workflows or webhook management, which limits full API coverage.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

mcp-serverOAuth
com.make
Give your AI agents the tools to build, manage, and run automation workflows.
App Automation Developer Tools Workplace & Productivity
2
StewAI A
com.stewai
Discover, preview, estimate, run, and retrieve reusable AI workflows.
AI & Machine Learning Autonomous Agents
141
Workflow A
io.github.Jonnyton
Create, browse, remix, collaborate on, and run durable AI workflow nodes from MCP hosts.
Autonomous Agents App Automation Workplace & Productivity
21
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216

Related MCP Servers

MCP File & Git Manager Server
File Systems Version Control Developer Tools
osamaloup
F
license
Not graded
quality
D
maintenance
Provides file system operations (read, write, list, delete) and Git repository management (status, commit, push, pull, diff) for n8n workflows through the Model Context Protocol.
Updated 10 months ago (2025-11-07 01:14 UTC)
-
n8n MCP Server
App Automation Developer Tools Workplace & Productivity
guinness77
A
license
B
quality
D
maintenance
Enables Large Language Models to interact with n8n automation instances through the Model Context Protocol. Supports workflow management, execution, credentials handling, and security audits through natural language commands.
Updated a year ago (2025-06-20 00:48 UTC)
33
48 npm
3
MIT
n8n MCP Server
App Automation Developer Tools Workplace & Productivity
sonnd08
A
license
Not graded
quality
F
maintenance
Provides AI assistants with direct access to the n8n automation platform to manage and execute workflows, variables, and credentials. It features 18 integrated tools that allow for seamless automation management via the Model Context Protocol.
Updated 23 days ago (2026-08-21 15:15 UTC)
59 npm
3
MIT
n8n MCP Server
App Automation Workplace & Productivity
dopehunter
A
license
Not graded
quality
D
maintenance
Enables management of n8n workflows directly within LLMs through the Model Context Protocol, including listing, executing, and monitoring workflows.
Updated 2 years ago (2025-03-09 18:30 UTC)
55 npm
18
ISC