Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| N8N_HOST | Yes | URL of the n8n API | http://localhost:5678/api/v1 |
| CACHE_TTL | No | Cache TTL in seconds | 300 |
| LOG_LEVEL | No | Logging level | info |
| N8N_API_KEY | Yes | API key for n8n authentication | |
| SERVER_NAME | No | Name of the MCP server | n8n-workflow-builder |
| CACHE_ENABLED | No | Enable caching | false |
| SERVER_VERSION | No | Version of the MCP server | Package version |
| OUTPUT_VERBOSITY | No | Output verbosity level (concise or full) | concise |
Schema
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| n8n Workflows | List of all workflows in n8n |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_available_nodes | Lists all available nodes in the n8n instance. Use this tool BEFORE creating or updating workflows to ensure you only use valid node types. This helps prevent errors caused by using node types that do not exist in the current n8n instance. |
| list_workflows | Lists all workflows from n8n with their basic information including ID, name, status, creation date, and tags. Use this tool to get an overview of available workflows before performing operations on specific workflows. Results can be filtered by active status, tags, or name. |
| create_workflow | Creates a new workflow in n8n with specified nodes and connections. Note that only workflows with automatic trigger nodes (schedule, webhook, etc.) can be activated - workflows with only manual triggers cannot be activated. Returns the created workflow with its assigned ID. |
| get_workflow | Retrieves complete details of a specific workflow by its ID, including all nodes, connections, settings, and metadata. Use this tool when you need to examine a workflow's structure before updating it or to understand how it works. |
| update_workflow | Updates an existing workflow with new configuration. Typically used after retrieving a workflow with get_workflow, modifying its structure, and then saving the changes. The entire workflow structure must be provided, not just the parts being changed. |
| delete_workflow | Permanently deletes a workflow by its ID. This action cannot be undone, so use with caution. Consider deactivating workflows instead if you might need them again later. |
| activate_workflow | Activates a workflow by its ID, enabling it to run automatically based on its trigger (schedule, webhook, etc.). Note that only workflows with automatic trigger nodes can be activated - workflows with only manual triggers cannot be activated. |
| deactivate_workflow | Deactivates a workflow by its ID, preventing it from running automatically. The workflow will still exist and can be manually executed or reactivated later. Use this instead of deleting workflows that you might need again. |
| list_executions | Lists workflow execution history with details on success/failure status, duration, and timestamps. Use this tool to monitor workflow performance, troubleshoot issues, or verify that workflows are running as expected. Results can be filtered by workflow ID, status, and limited to a specific number. |
| get_execution | Retrieves detailed information about a specific workflow execution, including execution time, status, and optionally the full data processed at each step. Particularly useful for debugging failed workflows or understanding data transformations between nodes. |