Manages n8n workflows, executions, and tags via the n8n API, allowing listing, creating, updating, activating/deactivating workflows, and debugging executions.
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-free-mcp list my n8n 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.
Free & open-source MCP server for n8n. Manage your workflows, debug executions and control your self-hosted n8n instance directly from Claude Code, Claude Desktop, Cursor, or any Model Context Protocol client.
ð 100% free, MIT licensed â no paywalls, no telemetry
ð Built for self-hosted / homelab n8n instances (works with n8n Cloud too)
ð Uses n8n's official public API (/api/v1) with your own API key
ðŠķ Tiny: one file, two dependencies (@modelcontextprotocol/sdk + zod)
ð§ Context-friendly: list tools return compact summaries instead of dumping full workflow JSON
Tool | Description |
| List workflows (id, name, active, tags, node count) with filters + pagination |
| Full workflow JSON: nodes, connections, settings |
| Create a new workflow from n8n-format JSON |
| Replace a workflow (read-only fields stripped automatically) |
| Toggle a workflow's triggers |
| Delete a workflow (irreversible â ïļ) |
| List executions, filter by status ( |
| Execution detail â with |
| Delete an execution record |
| List instance tags |
| Verify the instance is reachable and the API key works |
Related MCP server: n8n-manager-mcp
In your n8n instance: Settings â n8n API â Create an API key.
git clone https://github.com/jserna0001/n8n-free-mcp.git
cd n8n-free-mcp
npm install
npm run buildClaude Code:
claude mcp add --scope user n8n \
--env N8N_API_URL=https://your-n8n-instance.com \
--env N8N_API_KEY=your-api-key \
-- node /path/to/n8n-free-mcp/dist/index.jsClaude Desktop / Cursor / other clients (claude_desktop_config.json, mcp.json, etc.):
{
"mcpServers": {
"n8n": {
"command": "node",
"args": ["/path/to/n8n-free-mcp/dist/index.js"],
"env": {
"N8N_API_URL": "https://your-n8n-instance.com",
"N8N_API_KEY": "your-api-key"
}
}
}
}Alternative: .env file. Instead of passing env vars from the client, copy .env.example to .env in the project root and fill it in. Environment variables from the client take precedence.
Ask your assistant things like:
"List my n8n workflows"
"Show me the failed executions of the last runs and diagnose the error"
"Deactivate the workflow called X"
"Duplicate this workflow but change the webhook path"
The n8n public API does not expose credential values (by design). Credential management tools are intentionally out of scope.
update_workflow performs a full replace (PUT), as required by the n8n API â fetch with get_workflow, modify, then update.
n8n API keys are JWTs with an expiration date. If you start getting 401s, generate a new key.
Issues and PRs welcome. Ideas on the roadmap:
Trigger workflows via webhook test URLs
Variables & projects endpoints
npm package (npx n8n-free-mcp)
Docker image
MIT ÂĐ Justine Serna
Activate a workflow (starts running on its triggers).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Workflow ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that activation starts triggers, but does not disclose potential side effects (e.g., idempotency, permission requirements, or what happens if the workflow is already active). This is minimal for a mutation tool.
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, front-loaded sentence with no unnecessary words, earning every character.
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 one-parameter tool with no output schema, the description is reasonably complete. However, it could mention prerequisites (e.g., workflow must be inactive) or that activation triggers execution immediately.
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% for the single parameter 'id', described as 'Workflow ID'. The description adds no additional meaning beyond this, so 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 verb 'activate' and resource 'workflow', with the parenthetical explanation that it starts running on its triggers. This distinguishes it from siblings like 'deactivate_workflow'.
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 for activating an inactive workflow but does not explicitly state when to use it versus alternatives like 'deactivate_workflow' or provide any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify that the n8n instance responds and the API key is valid.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions verifying response and API key validity but does not disclose response format, error behavior, or side effects. Minimal transparency for a simple check.
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, efficient sentence that front-loads the purpose with no unnecessary words or structure.
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's simplicity (no parameters, no output schema, low complexity), the description provides sufficient information for an agent to understand 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?
With 0 parameters and 100% schema coverage, the description adds no extra meaning, but the baseline for 0 params is 4. The description is adequate and does not need parameter details.
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 verb 'Verify' and the specific resources ('n8n instance', 'API key'), distinguishing it from sibling tools that perform CRUD operations on workflows.
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 using this tool before other operations to check connectivity, but it lacks explicit when-not instructions or alternatives, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new workflow (created inactive; use activate_workflow to enable it). 'nodes' and 'connections' are JSON in n8n's standard export format.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Workflow name | |
| nodes | Yes | JSON array of n8n nodes (n8n export format) | |
| settings | No | JSON object of workflow settings (optional) | |
| connections | Yes | JSON object of connections between nodes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the workflow is created inactive, a key behavioral trait. However, it does not mention side effects like idempotency or error conditions (e.g., duplicate name).
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 two sentences, front-loaded with the purpose, and contains no redundant or extraneous 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?
The description covers the purpose, usage, and format, but lacks information about the return value (e.g., workflow ID or status) and any required permissions. For a creation tool with no output schema, this is a missing piece.
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 is 3. The description adds value by clarifying that 'nodes' and 'connections' must be in n8n's standard export format and that the workflow is created inactive, which goes beyond the schema's 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 the verb 'Create' and the resource 'workflow', and differentiates from the sibling tool 'activate_workflow' by noting the created workflow is inactive. It also specifies the format for nodes and connections.
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 says to use this tool for creation and directs to 'activate_workflow' for enabling. It implies this is for initial creation, but does not specify when to use versus 'update_workflow' or other creation-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deactivate a workflow (stops responding to its triggers).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Workflow ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that deactivation stops triggers, but does not mention side effects (e.g., on pending executions), reversibility, or necessary permissions. Basic but incomplete.
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?
A single sentence with no redundant information. It is front-loaded and efficient.
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's simplicity (one required parameter, no output schema), the description is adequate but lacks contextual completeness. It does not mention what happens if workflow is already deactivated, nor related tools like 'activate_workflow' for reversibility.
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 the schema already documents the 'id' parameter. The description adds no additional meaning beyond the schema; baseline 3 applies.
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 verb 'Deactivate' and the resource 'workflow', and explains the effect: 'stops responding to its triggers'. This distinguishes it from siblings like 'activate_workflow' and 'delete_workflow'.
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 deactivation is needed but provides no explicit guidance on when to use vs alternatives, prerequisites (e.g., workflow must be active), or error handling. The context is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an execution record. â ïļ Irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Execution ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description notes that the operation is irreversible, which is a key behavioral trait. However, without annotations, it does not disclose permissions, side effects, or related data impacts beyond the warning.
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 with two short sentences and an emoji for emphasis. No extraneous information, every part earns its place.
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 delete operation with one required parameter and no output schema, the description covers the core action and irreversibility. It is adequate but lacks details on error conditions or return behavior.
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?
The input schema has 100% description coverage for the single parameter 'id' (Execution ID). The description adds no additional meaning beyond this, meeting the baseline but not exceeding it.
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 action 'Delete' and the resource 'execution record', with a distinct purpose that differentiates it from sibling tools like 'get_execution' (read) and 'delete_workflow' (different resource).
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?
No guidance is provided on when to use this tool versus alternatives (e.g., 'delete_workflow') or any prerequisites. The description lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a workflow. â ïļ Irreversible â confirm with the user before using.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ID of the workflow to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
States 'Permanently delete' and 'Irreversible', disclosing destructive nature. No annotations provided, but description covers key behavioral aspect.
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 short sentences, front-loaded with action, 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?
Simple tool with one param, no output schema. Description provides enough context for safe usage.
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 is 3. Description adds no extra meaning beyond the schema for the 'id' parameter.
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 uses clear verb 'delete' and resource 'workflow'. Distinguishes from siblings like activate, create, deactivate.
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?
Includes warning about irreversibility and need for user confirmation. Lacks explicit when-not-to-use but sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the details of an execution. With includeData=true it returns per-node data (can be very large) â ideal for diagnosing errors.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Execution ID | |
| includeData | No | Include node input/output data (default false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions that includeData returns potentially large per-node data, which is helpful, but does not address permissions, rate limits, or any side effects. Since it's a read operation, destructive behavior is not needed, but more context would improve transparency.
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 two sentences long with no extraneous information. It front-loads the core purpose and follows with a useful caution about the optional parameter. Every sentence earns its place.
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's simplicity (2 parameter, no output schema), the description is reasonably complete. It covers the main purpose and the key parameter nuance. The only minor gap is not mentioning that the response includes execution details beyond node data, but it is sufficient for a tool of this complexity.
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?
The input schema has 100% coverage, so it already documents both parameters. The description adds value by explaining the implication of includeData (large response, error diagnosis), which goes beyond the schema's simple description. This helps the agent decide when to set it to true.
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 the details of an execution,' specifying the verb and resource. It also mentions the optional includeData flag, but does not explicitly differentiate from the sibling 'list_executions' tool, though the distinction (single vs. list) is implied.
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 using includeData ('for diagnosing errors'), but does not explain when to use this tool versus alternatives like list_executions or when not to use it. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a full workflow by ID, including nodes, connections and settings.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Workflow ID | |
| excludePinnedData | No | Exclude pinData (default true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It minimally states the data included but lacks information on return format, error handling, or any side effects (though it is a read operation).
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 concise sentence that directly conveys the purpose without any extraneous words, earning a high score for efficiency.
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 retrieval tool with two parameters and no output schema, the description is adequate but could be more complete by mentioning return details or default behavior of excludePinnedData.
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 both parameters described. The description does not add extra meaning beyond what the schema already provides, so baseline score of 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 verb (Get), resource (workflow), and the specific components included (nodes, connections, settings), distinguishing it from siblings like list_workflows.
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 using this tool to retrieve full workflow details by ID but does not explicitly mention when to use it versus alternatives like list_workflows or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List workflow executions. Useful for debugging: filter by status ('error', 'success', 'waiting') or by workflowId.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 100) | |
| cursor | No | Pagination cursor | |
| status | No | Filter by status | |
| workflowId | No | Filter by workflow |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description implies read-only behavior for debugging but omits details on pagination, rate limits, or authentication needs. It covers filtering but lacks comprehensive behavioral disclosure.
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 two sentences long, fully front-loaded, and free of unnecessary words. Every sentence is meaningful and efficient.
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 list tool with well-documented parameters, the description is mostly complete. However, the lack of output schema means the agent must infer return format; a brief note on return structure 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?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds minimal value beyond mentioning filtering and debugging context.
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 action 'List', the resource 'workflow executions', and specifies filtering options by status or workflowId. It effectively distinguishes from sibling tools such as get_execution (single) and delete_execution (delete).
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 identifies the tool as useful for debugging, giving context for use. However, it does not explicitly state when to avoid using it or compare to alternatives like get_execution for single results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the tags available on the n8n instance.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and a brief description that merely restates the title, the agent gains no insight into behaviors such as pagination, sorting, or whether the operation is read-only. The description carries the full burden but offers minimal value beyond the tool's name.
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, concise sentence with no redundant words. However, it is under-specified and could include useful details without becoming verbose, reducing its overall effectiveness.
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 tool with two undocumented parameters and no output schema, the description is severely incomplete. It fails to explain pagination, return format, or any other contextual details the agent needs to use 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?
The input schema includes two parameters (limit, cursor) with no descriptions in the schema (0% coverage). The description does not mention or explain these parameters, leaving the agent without guidance on how to use them effectively.
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 verb 'list' and the resource 'tags', making the action unambiguous. There are no other tag-related sibling tools, so it is well-differentiated.
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?
No guidance is provided on when to use this tool versus alternatives, nor any exclusions or prerequisites. The agent would have to infer usage context from the tool's name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List workflows on the n8n instance. Returns id, name, active state, tags and dates. Supports cursor pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Filter by exact name | |
| tags | No | Filter by tags, comma-separated | |
| limit | No | Max results (default 100) | |
| active | No | Filter by active/inactive workflows | |
| cursor | No | Pagination cursor (nextCursor from a previous response) | |
| excludePinnedData | No | Exclude pinData for lighter responses (default true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses pagination support and returned fields, but lacks details like default limit, authentication needs, or what happens with empty results. It is minimally transparent.
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 with no wasted words. Purpose is front-loaded, and key features (returned fields, pagination) are mentioned efficiently.
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 or annotations, the description adequately covers the tool's purpose, output summary, and pagination. It misses details like default limit (100) and excludePinnedData default, but these are in the schema, so overall complete enough.
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 baseline is 3. The description adds no extra meaning beyond the schema; 'cursor pagination' is already documented in the cursor parameter. No additional clarification or context for parameters.
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 lists all workflows on the n8n instance, specifying the resource (workflows) and action (list). It distinguishes from siblings like get_workflow (single) and update/deactivate, and mentions returned fields.
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 use for listing all workflows but does not explicitly state when to use this tool over others like list_executions. No mention of when not to use or alternatives, leaving it to the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replace an existing workflow (PUT). Pass the full workflow JSON (typically the result of get_workflow with modifications); read-only fields (id, active, tags, dates) are stripped automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ID of the workflow to update | |
| workflow | Yes | Full workflow JSON (name, nodes, connections, settings) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the PUT method and automatic stripping of read-only fields. It does not cover authentication, rate limits, or consequences of partial payloads, but provides key 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The core action and key instruction are front-loaded.
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 no annotations or output schema, the description adequately covers usage context: how to get the payload, what to expect from the tool. Could mention error handling or response, but it's sufficient for a simple update.
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%, but the description adds value by explaining the workflow parameter as 'full workflow JSON' and suggesting it comes from get_workflow, plus noting that read-only fields are stripped.
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 verb 'Replace' and the resource 'workflow', and includes the HTTP method PUT. It distinguishes from siblings like create_workflow by specifying a replacement action.
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 advises to pass the full workflow JSON, typically from get_workflow, and notes that read-only fields are stripped. It lacks explicit when-not-to-use guidance but implies this is for content updates, not state changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct operation: activation, CRUD for workflows, execution management, tag listing, and connection check. No ambiguity between tools with similar verbs (e.g., activate vs. create vs. update) due to clear resource differentiation.
All tool names follow a consistent verb_noun convention in snake_case (e.g., activate_workflow, list_executions, check_connection), making the toolset predictable and easy to navigate for an agent.
With 12 tools covering workflow CRUD, activation, execution management, tags, and connection verification, the count is well-scoped for the n8n domain. Neither too few nor excessive.
The toolset provides comprehensive lifecycle coverage for workflows and executions. A minor gap is the absence of a manual trigger/run tool, but the core operations are fully covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
n8n MCP â query your own n8n instance (BYO).
Self-hosted MCP gateway: turn any API, database or MCP server into AI connectors â no code.
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
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/jserna0001/n8n-free-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
