Provides comprehensive access to n8n node documentation, properties, and operations, enabling AI assistants to understand and work with n8n nodes effectively.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@n8n-mcp show me the properties of the HTTP Request node"
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.
A Model Context Protocol (MCP) server that provides AI assistants with comprehensive access to n8n node documentation, properties, and operations. Deploy in minutes to give Claude and other AI assistants deep knowledge about n8n's 2,063 workflow automation nodes (816 core + 1,247 community).
n8n-MCP serves as a bridge between n8n's workflow automation platform and AI models, enabling them to understand and work with n8n nodes effectively. It provides structured access to:
2,063 n8n nodes - 816 core nodes + 1,247 community nodes (1,113 verified)
Node properties - 99% coverage with detailed schemas
Node operations - 63.6% coverage of available actions
Documentation - 87% coverage from official n8n docs (including AI nodes)
AI tools - 265 AI-capable tool variants detected with full documentation
Real-world examples - 156 ranked configurations extracted from popular templates
Template library - 2,352 workflow templates with 99.96% AI metadata coverage
Community nodes - Search verified community integrations with source filter
Related MCP server: Caipher MCP
n8n-mcp started as a personal tool but now helps tens of thousands of developers automate their workflows efficiently. Maintaining and developing this project competes with my paid work. Your sponsorship helps me dedicate focused time to new features, respond quickly to issues, keep documentation up-to-date, and ensure compatibility with latest n8n releases. Become a sponsor
NEVER edit your production workflows directly with AI! Always:
Make a copy of your workflow before using AI tools
Test in development environment first
Export backups of important workflows
Validate changes before deploying to production
AI results can be unpredictable. Protect your work!
The fastest way to try n8n-MCP - no installation, no configuration:
Free tier: 100 tool calls/day
Instant access: Start building workflows immediately
Always up-to-date: Latest n8n nodes and templates
No infrastructure: We handle everything
Just sign up, get your API key, and connect your MCP client.
Want to self-host? See the Self-Hosting Guide for npx, Docker, Railway, and local installation options.
Want to use n8n-MCP with your n8n instance? Check out our comprehensive n8n Deployment Guide for:
Local testing with the MCP Client Tool node
Production deployment with Docker Compose
Cloud deployment on Hetzner, AWS, and other providers
Troubleshooting and security best practices
n8n-MCP works with multiple AI-powered IDEs and tools:
Claude Code - Quick setup for Claude Code CLI
Visual Studio Code - VS Code with GitHub Copilot integration
Cursor - Step-by-step Cursor IDE setup
Windsurf - Windsurf integration with project rules
Codex - Codex integration guide
Antigravity - Antigravity integration guide
Supercharge your n8n workflow building with specialized skills that teach AI how to build production-ready workflows!
Learn more: n8n-skills repository
For the best results when using n8n-MCP with Claude Projects, use these enhanced system instructions:
You are an expert in n8n automation software using n8n-MCP tools. Your role is to design, build, and validate n8n workflows with maximum accuracy and efficiency.
## Core Principles
### 1. Silent Execution
CRITICAL: Execute tools without commentary. Only respond AFTER all tools complete.
### 2. Parallel Execution
When operations are independent, execute them in parallel for maximum performance.
### 3. Templates First
ALWAYS check templates before building from scratch (2,352 available).
### 4. Multi-Level Validation
Use validate_node(mode='minimal') → validate_node(mode='full') → validate_workflow pattern.
### 5. Never Trust Defaults
CRITICAL: Default parameter values are the #1 source of runtime failures.
ALWAYS explicitly configure ALL parameters that control node behavior.
## Workflow Process
1. **Start**: Call `tools_documentation()` for best practices
2. **Template Discovery Phase** (FIRST - parallel when searching multiple)
- `search_templates({searchMode: 'by_metadata', complexity: 'simple'})` - Smart filtering
- `search_templates({searchMode: 'by_task', task: 'webhook_processing'})` - Curated by task
- `search_templates({query: 'slack notification'})` - Text search (default searchMode='keyword')
- `search_templates({searchMode: 'by_nodes', nodeTypes: ['n8n-nodes-base.slack']})` - By node type
**Filtering strategies**:
- Beginners: `complexity: "simple"` + `maxSetupMinutes: 30`
- By role: `targetAudience: "marketers"` | `"developers"` | `"analysts"`
- By time: `maxSetupMinutes: 15` for quick wins
- By service: `requiredService: "openai"` for compatibility
3. **Node Discovery** (if no suitable template - parallel execution)
- Think deeply about requirements. Ask clarifying questions if unclear.
- `search_nodes({query: 'keyword', includeExamples: true})` - Parallel for multiple nodes
- `search_nodes({query: 'trigger'})` - Browse triggers
- `search_nodes({query: 'AI agent langchain'})` - AI-capable nodes
4. **Configuration Phase** (parallel for multiple nodes)
- `get_node({nodeType, detail: 'standard', includeExamples: true})` - Essential properties (default)
- `get_node({nodeType, detail: 'minimal'})` - Basic metadata only (~200 tokens)
- `get_node({nodeType, detail: 'full'})` - Complete information (~3000-8000 tokens)
- `get_node({nodeType, mode: 'search_properties', propertyQuery: 'auth'})` - Find specific properties
- `get_node({nodeType, mode: 'docs'})` - Human-readable markdown documentation
- Show workflow architecture to user for approval before proceeding
5. **Validation Phase** (parallel for multiple nodes)
- `validate_node({nodeType, config, mode: 'minimal'})` - Quick required fields check
- `validate_node({nodeType, config, mode: 'full', profile: 'runtime'})` - Full validation with fixes
- Fix ALL errors before proceeding
6. **Building Phase**
- If using template: `get_template(templateId, {mode: "full"})`
- **MANDATORY ATTRIBUTION**: "Based on template by **[author.name]** (@[username]). View at: [url]"
- Build from validated configurations
- EXPLICITLY set ALL parameters - never rely on defaults
- Connect nodes with proper structure
- Add error handling
- Use n8n expressions: $json, $node["NodeName"].json
- Build in artifact (unless deploying to n8n instance)
7. **Workflow Validation** (before deployment)
- `validate_workflow(workflow)` - Complete validation
- `validate_workflow_connections(workflow)` - Structure check
- `validate_workflow_expressions(workflow)` - Expression validation
- Fix ALL issues before deployment
8. **Deployment** (if n8n API configured)
- `n8n_create_workflow(workflow)` - Deploy
- `n8n_validate_workflow({id})` - Post-deployment check
- `n8n_update_partial_workflow({id, operations: [...]})` - Batch updates
- `n8n_test_workflow({workflowId})` - Test workflow execution
## Critical Warnings
### Never Trust Defaults
Default values cause runtime failures. Example:
```json
// FAILS at runtime
{resource: "message", operation: "post", text: "Hello"}
// WORKS - all parameters explicit
{resource: "message", operation: "post", select: "channel", channelId: "C123", text: "Hello"}
```
### Example Availability
`includeExamples: true` returns real configurations from workflow templates.
- Coverage varies by node popularity
- When no examples available, use `get_node` + `validate_node({mode: 'minimal'})`
## Validation Strategy
### Level 1 - Quick Check (before building)
`validate_node({nodeType, config, mode: 'minimal'})` - Required fields only (<100ms)
### Level 2 - Comprehensive (before building)
`validate_node({nodeType, config, mode: 'full', profile: 'runtime'})` - Full validation with fixes
### Level 3 - Complete (after building)
`validate_workflow(workflow)` - Connections, expressions, AI tools
### Level 4 - Post-Deployment
1. `n8n_validate_workflow({id})` - Validate deployed workflow
2. `n8n_autofix_workflow({id})` - Auto-fix common errors
3. `n8n_executions({action: 'list'})` - Monitor execution status
## Response Format
### Initial Creation
```
[Silent tool execution in parallel]
Created workflow:
- Webhook trigger → Slack notification
- Configured: POST /webhook → #general channel
Validation: All checks passed
```
### Modifications
```
[Silent tool execution]
Updated workflow:
- Added error handling to HTTP node
- Fixed required Slack parameters
Changes validated successfully.
```
## Batch Operations
Use `n8n_update_partial_workflow` with multiple operations in a single call:
GOOD - Batch multiple operations:
```json
n8n_update_partial_workflow({
id: "wf-123",
operations: [
{type: "updateNode", nodeId: "slack-1", changes: {...}},
{type: "updateNode", nodeId: "http-1", changes: {...}},
{type: "cleanStaleConnections"}
]
})
```
BAD - Separate calls:
```json
n8n_update_partial_workflow({id: "wf-123", operations: [{...}]})
n8n_update_partial_workflow({id: "wf-123", operations: [{...}]})
```
### CRITICAL: addConnection Syntax
The `addConnection` operation requires **four separate string parameters**. Common mistakes cause misleading errors.
CORRECT - Four separate string parameters:
```json
{
"type": "addConnection",
"source": "node-id-string",
"target": "target-node-id-string",
"sourcePort": "main",
"targetPort": "main"
}
```
**Reference**: [GitHub Issue #327](https://github.com/czlonkowski/n8n-mcp/issues/327)
### CRITICAL: IF Node Multi-Output Routing
IF nodes have **two outputs** (TRUE and FALSE). Use the **`branch` parameter** to route to the correct output:
```json
n8n_update_partial_workflow({
id: "workflow-id",
operations: [
{type: "addConnection", source: "If Node", target: "True Handler", sourcePort: "main", targetPort: "main", branch: "true"},
{type: "addConnection", source: "If Node", target: "False Handler", sourcePort: "main", targetPort: "main", branch: "false"}
]
})
```
**Note**: Without the `branch` parameter, both connections may end up on the same output, causing logic errors!
### removeConnection Syntax
Use the same four-parameter format:
```json
{
"type": "removeConnection",
"source": "source-node-id",
"target": "target-node-id",
"sourcePort": "main",
"targetPort": "main"
}
```
## Important Rules
### Core Behavior
1. **Silent execution** - No commentary between tools
2. **Parallel by default** - Execute independent operations simultaneously
3. **Templates first** - Always check before building (2,352 available)
4. **Multi-level validation** - Quick check → Full validation → Workflow validation
5. **Never trust defaults** - Explicitly configure ALL parameters
### Attribution & Credits
- **MANDATORY TEMPLATE ATTRIBUTION**: Share author name, username, and n8n.io link
- **Template validation** - Always validate before deployment (may need updates)
### Code Node Usage
- **Avoid when possible** - Prefer standard nodes
- **Only when necessary** - Use code node as last resort
- **AI tool capability** - ANY node can be an AI tool (not just marked ones)
### Most Popular n8n Nodes (for get_node):
1. **n8n-nodes-base.code** - JavaScript/Python scripting
2. **n8n-nodes-base.httpRequest** - HTTP API calls
3. **n8n-nodes-base.webhook** - Event-driven triggers
4. **n8n-nodes-base.set** - Data transformation
5. **n8n-nodes-base.if** - Conditional routing
6. **n8n-nodes-base.manualTrigger** - Manual workflow execution
7. **n8n-nodes-base.respondToWebhook** - Webhook responses
8. **n8n-nodes-base.scheduleTrigger** - Time-based triggers
9. **@n8n/n8n-nodes-langchain.agent** - AI agents
10. **n8n-nodes-base.googleSheets** - Spreadsheet integration
11. **n8n-nodes-base.merge** - Data merging
12. **n8n-nodes-base.switch** - Multi-branch routing
13. **n8n-nodes-base.telegram** - Telegram bot integration
14. **@n8n/n8n-nodes-langchain.lmChatOpenAi** - OpenAI chat models
15. **n8n-nodes-base.splitInBatches** - Batch processing
16. **n8n-nodes-base.openAi** - OpenAI legacy node
17. **n8n-nodes-base.gmail** - Email automation
18. **n8n-nodes-base.function** - Custom functions
19. **n8n-nodes-base.stickyNote** - Workflow documentation
20. **n8n-nodes-base.executeWorkflowTrigger** - Sub-workflow calls
**Note:** LangChain nodes use the `@n8n/n8n-nodes-langchain.` prefix, core nodes use `n8n-nodes-base.`
Save these instructions in your Claude Project for optimal n8n workflow assistance with intelligent template discovery.
tools_documentation - Get documentation for any MCP tool (START HERE!)
search_nodes - Full-text search across all nodes. Use source: 'community'|'verified' for community nodes, includeExamples: true for configs
get_node - Unified node information tool with multiple modes:
Info mode (default): detail: 'minimal'|'standard'|'full', includeExamples: true
Docs mode: mode: 'docs' - Human-readable markdown documentation
Property search: mode: 'search_properties', propertyQuery: 'auth'
Versions: mode: 'versions'|'compare'|'breaking'|'migrations'
validate_node - Unified node validation:
mode: 'minimal' - Quick required fields check (<100ms)
mode: 'full' - Comprehensive validation with profiles (minimal, runtime, ai-friendly, strict)
validate_workflow - Complete workflow validation including AI Agent validation
search_templates - Unified template search:
searchMode: 'keyword' (default) - Text search with query parameter
searchMode: 'by_nodes' - Find templates using specific nodeTypes
searchMode: 'by_task' - Curated templates for common task types
searchMode: 'by_metadata' - Filter by complexity, requiredService, targetAudience
get_template - Get complete workflow JSON (modes: nodes_only, structure, full)
These tools require N8N_API_URL and N8N_API_KEY in your configuration.
n8n_create_workflow - Create new workflows with nodes and connections
n8n_get_workflow - Unified workflow retrieval (modes: full, details, structure, minimal)
n8n_update_full_workflow - Update entire workflow (complete replacement)
n8n_update_partial_workflow - Update workflow using diff operations
n8n_delete_workflow - Delete workflows permanently
n8n_list_workflows - List workflows with filtering and pagination
n8n_validate_workflow - Validate workflows in n8n by ID
n8n_autofix_workflow - Automatically fix common workflow errors
n8n_workflow_versions - Manage version history and rollback
n8n_deploy_template - Deploy templates from n8n.io directly to your instance with auto-fix
n8n_test_workflow - Test/trigger workflow execution (webhook, form, chat)
n8n_executions - Unified execution management (list, get, delete)
n8n_manage_datatable - Manage n8n data tables and rows (list, get, create, update, delete)
n8n_manage_credentials - Manage n8n credentials (list, get, create, update, delete, getSchema)
n8n_audit_instance - Security audit combining n8n's built-in audit API with deep workflow scanning
n8n_health_check - Check n8n API connectivity and features
For governance-sensitive environments, use both env vars together. Fully disable tools that are write/destructive or handle sensitive data (n8n_manage_credentials and n8n_manage_datatable also offer read operations, but are removed entirely here because even reads expose sensitive material):
DISABLED_TOOLS=n8n_create_workflow,n8n_update_full_workflow,n8n_update_partial_workflow,n8n_delete_workflow,n8n_autofix_workflow,n8n_deploy_template,n8n_test_workflow,n8n_manage_credentials,n8n_manage_datatableFor tools that bundle read and write operations under one name, block only the destructive operations while keeping list and get:
DISABLED_TOOL_OPERATIONS=n8n_workflow_versions:delete,rollback,prune;n8n_executions:deleteCombine with a read-only n8n API key (Settings → API in your n8n instance) for defence in depth. See Read-Only Deployment Recipe for the full setup guide.
Self-Hosting Guide - npx, Docker, Railway, and local installation
Security & Hardening - Trust model, hardening options, workflow restrictions
n8n Deployment Guide - Production deployment with n8n
Database Configuration - SQLite adapters and memory optimization
Privacy & Telemetry - What we collect and how to opt out
Workflow Diff Operations - Token-efficient workflow updates
HTTP Deployment - Remote server setup
Change Log - Complete version history
MIT License - see LICENSE for details.
See CONTRIBUTING.md for development setup, testing, and contribution guidelines.
See Acknowledgments for credits and template attribution.
Get node info with progressive detail levels and multiple modes. Detail: minimal (~200 tokens), standard (~1-2K, default), full (~3-8K). Modes: info (default), docs (markdown documentation), search_properties (find properties), versions/compare/breaking/migrations (version info). Use format='docs' for readable documentation, mode='search_properties' with propertyQuery for finding specific fields.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Operation mode. info=node schema, docs=readable markdown documentation, search_properties=find specific properties, versions/compare/breaking/migrations=version info | info |
| detail | No | Information detail level. standard=essential properties (recommended), full=everything | standard |
| nodeType | Yes | Full node type: "nodes-base.httpRequest" or "nodes-langchain.agent" | |
| toVersion | No | Target version for compare mode (e.g., "2.0"). Defaults to latest if omitted. | |
| fromVersion | No | Source version for compare/breaking/migrations modes (e.g., "1.0") | |
| propertyQuery | No | For mode=search_properties: search term to find properties (e.g., "auth", "header", "body") | |
| includeExamples | No | Include real-world configuration examples from templates. Only applies to mode=info with detail=standard. Adds ~200-400 tokens per example. | |
| includeTypeInfo | No | Include type structure metadata (type category, JS type, validation rules). Only applies to mode=info. Adds ~80-120 tokens per property. | |
| maxPropertyResults | No | For mode=search_properties: max results (default 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds significant value by disclosing token estimates for each detail level (e.g., ~200 tokens for minimal, ~1-2K for standard), output types per mode (e.g., markdown for docs), and combining parameters. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. Each sentence adds unique information: overview, detail/mode explanations, and usage tips. No redundant or vague statements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers modes, detail levels, token costs, and parameter combinations well, but it doesn't explicitly describe the overall output format (e.g., JSON structure for standard info mode). Given no output schema, a brief mention of return shape would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description adds meaningful context beyond parameter descriptions, such as token size expectations for detail, usage examples (e.g., 'Use format='docs'), and combining mode with propertyQuery. This helps the agent make informed parameter choices.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get node info' with specific verb and resource. It details progressive detail levels and multiple modes (info, docs, search_properties, versions, etc.), which distinguishes this tool from siblings like get_template or search_nodes. The purpose is unambiguous and well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides internal usage guidance (e.g., 'Use format='docs' for readable documentation, mode='search_properties' with propertyQuery for finding specific fields') but does not explicitly address when to use this tool versus sibling tools like search_nodes or get_template. Missing cross-tool alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get template by ID. Use mode to control response size: nodes_only (minimal), structure (nodes+connections), full (complete workflow).
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Response detail level. nodes_only: just node list, structure: nodes+connections, full: complete workflow JSON. | full |
| templateId | Yes | The template ID to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint, indicating safe read-only operation. The description adds behavioral context by explaining how the mode parameter controls response size (nodes_only, structure, full), which is useful beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no wasted words. It front-loads the purpose and then explains the mode parameter, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with two parameters and no output schema, the description covers the essential behavior. It lacks explicit mention of return format (e.g., template object), but the mode descriptions imply it returns workflow data. Minor gap, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and both parameters are fully described. The description adds a concise summary of the mode options but no new semantic information beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get template by ID' with a specific verb and resource. It distinguishes from sibling tools like search_templates (search vs get by ID) and get_node (different resource). The mode parameter further clarifies the response granularity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a specific template ID. It does not explicitly exclude other scenarios or compare to search_templates, but the purpose is clear enough. A brief note on when not to use it (e.g., searching) would improve it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search n8n nodes by keyword with optional real-world examples. Pass query as string. Example: query="webhook" or query="database". Returns max 20 results. Use includeExamples=true to get top 2 template configs per node.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | OR=any word, AND=all words, FUZZY=typo-tolerant | OR |
| limit | No | Max results (default 20) | |
| query | Yes | Search terms. Use quotes for exact phrase. | |
| source | No | Filter by node source: all=everything (default), core=n8n base nodes, community=community nodes, verified=verified community nodes only | all |
| includeExamples | No | Include top 2 real-world configuration examples from popular templates (default: false) | |
| includeOperations | No | Include resource/operation tree per node. Adds ~100-300 tokens per result but saves a get_node round-trip. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses return limit (max 20 results) and the effect of includeExamples (top 2 template configs). The annotations already declare readOnlyHint and idempotentHint, so the tool is safe. The description adds useful behavioral details beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences) and front-loaded with the main action. Every sentence adds value: search purpose, parameter usage, limit, and examples option. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters and no output schema, the description covers input usage well but lacks details on return format, sorting, or pagination beyond the limit. It is mostly complete for a search tool, but could mention whether results are sorted by relevance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters, so baseline is 3. The description provides a usage example for 'query' and paraphrases the intent of includeExamples, but adds minimal new semantic value beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches n8n nodes by keyword with optional examples. It distinguishes from sibling tools like 'get_node' (which retrieves a specific node) and 'search_templates' (which searches templates) by specifying that it searches nodes and can optionally include template configurations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage instructions (e.g., 'Pass query as string. Example: query="webhook" or query="database".') and explains when to use optional parameters. However, it does not explicitly state when not to use this tool or list alternatives, but given the sibling context, the guidance is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search templates with multiple modes. Use searchMode='keyword' for text search, 'by_nodes' to find templates using specific nodes, 'by_task' for curated task-based templates, 'by_metadata' for filtering by complexity/setup time/services, 'patterns' for lightweight workflow pattern summaries mined from 2700+ templates.
| Name | Required | Description | Default |
|---|---|---|---|
| task | No | For searchMode=by_task: the type of task. For searchMode=patterns: optional category filter (omit for overview of all categories). | |
| limit | No | Maximum number of results. Default 20. | |
| query | No | For searchMode=keyword: search keyword (e.g., "chatbot") | |
| fields | No | For searchMode=keyword: fields to include in response. Default: all fields. | |
| offset | No | Pagination offset. Default 0. | |
| category | No | For searchMode=by_metadata: filter by category (e.g., "automation", "integration") | |
| nodeTypes | No | For searchMode=by_nodes: array of node types (e.g., ["n8n-nodes-base.httpRequest", "n8n-nodes-base.slack"]) | |
| complexity | No | For searchMode=by_metadata: filter by complexity level | |
| searchMode | No | Search mode. keyword=text search (default), by_nodes=find by node types, by_task=curated task templates, by_metadata=filter by complexity/services, patterns=lightweight workflow pattern summaries | keyword |
| targetAudience | No | For searchMode=by_metadata: filter by target audience (e.g., "developers", "marketers") | |
| maxSetupMinutes | No | For searchMode=by_metadata: maximum setup time in minutes | |
| minSetupMinutes | No | For searchMode=by_metadata: minimum setup time in minutes | |
| requiredService | No | For searchMode=by_metadata: filter by required service (e.g., "openai", "slack") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations readOnlyHint=true and idempotentHint=true already indicate safety. Description adds behavioral clarity about mode behavior, but doesn't mention pagination or rate limits. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single long sentence that front-loads the core purpose. It could be more structured (e.g., bullet points) but remains concise given the complexity. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While schema covers parameters, the description does not describe the response format or pagination behavior. With no output schema, the description should hint at what the response contains. This is a gap, but the tool is read-only and search-oriented, so moderate completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The description enhances understanding by linking parameters to specific search modes (e.g., 'For searchMode=by_nodes: array of node types'). This adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches templates and lists five distinct search modes. It distinguishes from sibling tools like search_nodes and get_template by focusing on templates and detailing mode-specific purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use each search mode (e.g., 'Use searchMode='keyword' for text search'). It implicitly differentiates from siblings by focusing on templates. Missing explicit 'when not to use' but sufficient for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get documentation for n8n MCP tools. Call without parameters for quick start guide. Use topic parameter to get documentation for specific tools. Use depth='full' for comprehensive documentation.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | Level of detail. "essentials" (default) for quick reference, "full" for comprehensive docs. | essentials |
| topic | No | Tool name (e.g., "search_nodes") or "overview" for general guide. Leave empty for quick reference. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds that it returns documentation but no additional behavioral traits beyond the implied read-only nature from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, and each sentence adds distinct value. No redundant or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two optional parameters and no output schema, the description covers the main use cases. It could mention that the output is documentation text, but the purpose is clear. The annotations provide additional safety context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the parameters. The description adds usage context (e.g., 'use topic parameter to get documentation for specific tools') but does not add meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get documentation for n8n MCP tools.' It distinguishes from siblings by specifying it covers tool documentation, not node or template details. The two usage modes (quick start vs. specific/comprehensive) are immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use each parameter: call without parameters for a quick start guide, use topic for specific tools, and depth='full' for comprehensive docs. It does not explicitly mention when not to use the tool, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate n8n node configuration. Use mode='full' for comprehensive validation with errors/warnings/suggestions, mode='minimal' for quick required fields check. Example: nodeType="nodes-base.slack", config={resource:"channel",operation:"create"}
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Validation mode. full=comprehensive validation with errors/warnings/suggestions, minimal=quick required fields check only. Default is "full" | full |
| config | Yes | Configuration as object. For simple nodes use {}. For complex nodes include fields like {resource:"channel",operation:"create"} | |
| profile | No | Profile for mode=full: "minimal", "runtime", "ai-friendly", or "strict". Default is "ai-friendly" | ai-friendly |
| nodeType | Yes | Node type as string. Example: "nodes-base.slack" |
| Name | Required | Description |
|---|---|---|
| valid | Yes | |
| errors | No | |
| summary | No | |
| nodeType | Yes | |
| warnings | No | |
| displayName | Yes | |
| suggestions | No | |
| workflowNodeType | No | |
| missingRequiredFields | No | Only present in mode=minimal |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe, side-effect-free operation. The description adds behavioral context by explaining that 'full' mode returns errors/warnings/suggestions and 'minimal' does a quick required field check, going beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with one informative sentence and an example. It is front-loaded with the purpose. Could be slightly more structured (e.g., bullet points for modes), but it is efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, enums, nested objects, and an output schema, the description covers the essential usage (modes, example) and the schema details each parameter. The output schema is not described but exists separately, so the description is sufficient for an AI to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described. The description adds value by providing a concrete example (nodeType="nodes-base.slack", config={resource:"channel",operation:"create"}) that illustrates how parameters like nodeType and config interact, and explains mode values in context. This goes beyond the schema's individual descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Validate n8n node configuration' with a specific verb and resource. It distinguishes from sibling tools like validate_workflow (for workflows) and get_node/search_nodes (for fetching/searching), making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use 'full' vs 'minimal' modes and includes a concrete example. However, it does not explicitly compare to sibling tools like validate_workflow or search_templates for when not to use this tool, though the context implies the distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full workflow validation: structure, connections, expressions, AI tools. Returns errors/warnings/fixes. Essential before deploy.
| Name | Required | Description | Default |
|---|---|---|---|
| options | No | Optional validation settings | |
| workflow | Yes | The complete workflow JSON to validate. Must include nodes array and connections object. |
| Name | Required | Description |
|---|---|---|
| valid | Yes | |
| errors | No | |
| summary | Yes | |
| warnings | No | |
| suggestions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnly and idempotent; description adds behavioral detail like returning errors/warnings/fixes and being essential before deployment. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first defines tool, second gives purpose (before deploy). Front-loaded with key information; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, description appropriately covers validation scope and use case. Adds detail about AI tools validation not in schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description does not add parameter-level detail beyond what schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Full workflow validation' and lists specific aspects: structure, connections, expressions, AI tools. Distinguishes from sibling 'validate_node' by scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Essential before deploy', providing usage context. Lists validation categories, but lacks explicit when-not-to-use or mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: get_node and get_template fetch details, search_nodes and search_templates search, tools_documentation provides MCP documentation, validate_node and validate_workflow perform validation. No overlap.
Most tools follow verb_noun snake_case pattern (get_node, search_nodes, etc.). tools_documentation is a slight deviation (noun_noun), but still readable and not confusing.
7 tools is well-scoped for a server focused on node/workflow exploration and validation. Each tool earns its place without redundancy.
The tool set covers retrieval, search, validation, and documentation for nodes and templates. Missing a 'list all' function and mutation operations, but this appears intentional for a read/validate server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
MCP server for AI agent profiles and smart notes. 60+ coding prompt packs with expert personas.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mirza-javed/n8n-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
