Cursor n8n Builder

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose targeting specific resources and actions in the n8n domain. There is no overlap between workflow management tools (create, get, update, delete, activate, deactivate), execution tools (list, get, delete), and utility tools (health check, node info, tools help, trigger webhook). The descriptions reinforce these distinctions, making misselection unlikely.
Naming Consistency5/5
All tool names follow a perfect and consistent 'n8n_verb_noun' pattern throughout the set. The verb-noun structure is uniform (e.g., n8n_create_workflow, n8n_get_execution, n8n_health_check), with no deviations in style or convention. This predictability makes the tool set easy to navigate and understand.
Tool Count5/5
With 14 tools, the count is well-scoped for managing n8n workflows and executions. Each tool earns its place by covering essential operations like CRUD for workflows, execution lifecycle management, and necessary utilities. This provides comprehensive coverage without being overwhelming or sparse for the domain.
Completeness5/5
The tool surface offers complete CRUD and lifecycle coverage for workflows (create, get, update, delete, activate, deactivate, list) and executions (list, get, delete), along with utilities for health checks, node information, documentation, and triggering. There are no obvious gaps, and agents can perform all core n8n management tasks without dead ends.
Average 3.3/5 across 14 of 14 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the workflow is created 'in inactive state,' which adds some context about the initial state. However, it lacks critical details such as required permissions, whether this is a destructive operation (e.g., overwriting existing workflows), error handling, or what the response looks like (since there's no output schema). For a creation tool with zero annotation coverage, this is insufficient.
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 concise with two sentences that directly state the purpose and a key behavioral trait (inactive state). It's front-loaded with the main action and avoids unnecessary fluff. However, it could be slightly more structured by explicitly separating purpose from usage notes, but it remains efficient.
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 the complexity (4 parameters with nested objects, no output schema, and no annotations), the description is incomplete. It lacks details on behavioral aspects like permissions, error cases, or response format, and doesn't fully guide usage relative to sibling tools. For a creation tool with significant complexity and no structured support, more comprehensive guidance is needed.
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 schema description coverage is 100%, meaning the input schema already documents all parameters (name, nodes, connections, settings) thoroughly. The description doesn't add any meaningful semantic details beyond what's in the schema, such as examples or constraints not captured in the schema. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 clearly states the action ('Create a new workflow') and the resource ('with nodes and connections'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this from sibling tools like 'n8n_update_workflow' or 'n8n_list_workflows', which would require mentioning it's for initial creation rather than modification or retrieval.
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 minimal guidance by noting the workflow 'will be created in inactive state,' which hints at a prerequisite (activation might be needed later). However, it doesn't specify when to use this tool versus alternatives like 'n8n_update_workflow' for modifications or 'n8n_activate_workflow' for activation, nor does it mention any exclusions or prerequisites beyond the implied inactive state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the effect ('stop it from being triggered'), which implies a mutation, but lacks details on permissions required, reversibility (e.g., via 'n8n_activate_workflow'), side effects, or error handling. This is inadequate for a mutation tool with zero annotation coverage.
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?
The description is a single, clear sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and efficiently communicates the core action, making it highly concise and well-structured for quick understanding.
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 the tool's complexity as a mutation operation with no annotations and no output schema, the description is incomplete. It fails to address critical aspects like return values, error conditions, or behavioral nuances (e.g., what 'deactivate' entails operationally). This leaves significant gaps for an AI agent to understand the full context of use.
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 input schema has 100% description coverage, with the 'id' parameter documented as 'The workflow ID to deactivate.' The description adds no additional meaning beyond this, such as format examples or constraints. Given the high schema coverage, a baseline score of 3 is appropriate as the schema handles the parameter semantics effectively.
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 clearly states the action ('deactivate') and resource ('workflow') with the purpose to 'stop it from being triggered,' which is specific and actionable. However, it doesn't explicitly differentiate from siblings like 'n8n_delete_workflow' or 'n8n_update_workflow,' which could involve similar workflow modifications, so it misses full sibling distinction.
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 implies usage when stopping workflow triggers, but provides no explicit guidance on when to use this tool versus alternatives (e.g., vs. 'n8n_delete_workflow' for permanent removal or 'n8n_update_workflow' for modifications). There's no mention of prerequisites, exclusions, or contextual best practices, leaving gaps in usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Delete') but doesn't clarify if this is reversible, requires specific permissions, has side effects (e.g., affecting workflow runs), or provides confirmation feedback. For a destructive operation with zero annotation coverage, this is a significant gap in transparency.
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?
The description is a single, direct sentence ('Delete an execution record.') with zero wasted words. It is appropriately sized for a simple tool and front-loaded with the core action, making it highly efficient and easy to parse.
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 the tool's destructive nature, lack of annotations, and no output schema, the description is incomplete. It doesn't address critical context like irreversibility, error handling, or what happens post-deletion (e.g., if the execution is removed from lists). For a delete operation, this leaves the agent with insufficient information to use it safely and effectively.
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 input schema has 100% description coverage, with the 'id' parameter clearly documented as 'The execution ID to delete'. The description adds no additional meaning beyond this, such as format examples or sourcing hints. Given the high schema coverage, a baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
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 clearly states the verb ('Delete') and resource ('execution record'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'n8n_delete_workflow' or 'n8n_list_executions', which would require mentioning it specifically targets execution records rather than workflows or other entities.
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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an execution ID from 'n8n_list_executions'), exclusions, or comparisons to siblings like 'n8n_get_execution' for viewing instead of deleting. This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool retrieves 'detailed information' and 'input/output data', but lacks critical details such as whether this is a read-only operation, any authentication requirements, rate limits, error handling, or the format of the returned data. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
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?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence contributes essential information, earning its place.
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 the complexity of retrieving execution data, the lack of annotations and output schema means the description should do more to compensate. It doesn't explain what 'detailed information' includes beyond input/output data, nor does it cover behavioral aspects like safety or response format. For a tool with no structured support, this description is incomplete and leaves the agent with insufficient context.
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 schema already documents both parameters ('id' and 'includeData') with clear descriptions. The description adds no additional meaning beyond what the schema provides, such as examples or context for when to set 'includeData' to false. Baseline 3 is appropriate when the schema handles parameter documentation effectively.
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 clearly states the tool's purpose with a specific verb ('Get') and resource ('detailed information about a specific execution'), including the scope of data (input/output). It distinguishes from siblings like 'n8n_list_executions' by focusing on a single execution rather than listing multiple. However, it doesn't explicitly contrast with 'n8n_get_workflow' or 'n8n_get_node_info', which slightly limits differentiation.
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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an execution ID from 'n8n_list_executions'), exclusions, or comparisons to siblings like 'n8n_get_workflow' for workflow-level details. Usage is implied by the name and parameters but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states the tool 'Get information,' implying a read-only operation, but doesn't clarify aspects like whether it returns static documentation or dynamic data, potential rate limits, authentication needs, or error handling. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
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?
The description is a single, clear sentence that efficiently conveys the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse. Every part of the sentence earns its place by directly contributing to understanding.
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 the complexity of providing node information, the lack of annotations, and no output schema, the description is insufficient. It doesn't explain what 'information' includes (e.g., parameters, usage examples, or links) or the return format, leaving the AI agent with incomplete context for effective tool invocation.
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 input schema has 100% description coverage, with the 'nodeType' parameter well-documented in the schema itself. The description adds no additional meaning beyond what the schema provides, such as examples of common node types or details on configuration information. Given the high schema coverage, a baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 clearly states the tool's purpose: 'Get information about common n8n node types and their configurations.' It specifies the verb ('Get information') and resource ('common n8n node types and their configurations'), making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'n8n_tools_help' or 'n8n_get_workflow', which might also provide information, so it doesn't reach a perfect score.
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 guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'n8n_tools_help' (which might offer broader help) or 'n8n_get_workflow' (which focuses on workflows rather than node types), nor does it specify prerequisites or contexts for usage. This lack of comparative guidance limits its effectiveness for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions filtering capabilities but fails to describe critical behaviors: whether this is a read-only operation, if it supports pagination beyond the 'limit' parameter, what the response format looks like, or any rate limits. For a list tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a list tool and front-loads the core purpose. While it could be slightly more comprehensive, every word earns its place by conveying essential information about the tool's function.
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 the complexity of a list operation with 4 parameters and no output schema, the description is incomplete. It doesn't explain what the tool returns (execution objects with what fields?), whether results are paginated, or any behavioral constraints. With no annotations and no output schema, the description should provide more context about the operation's results and limitations to be truly helpful.
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 schema description coverage is 100%, so the schema already fully documents all 4 parameters. The description mentions filtering by workflow ID and status, which aligns with two parameters but adds no additional meaning beyond what the schema provides. With complete schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't detract either.
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 clearly states the verb ('List') and resource ('workflow executions'), making the purpose immediately understandable. It distinguishes from siblings like 'n8n_get_execution' (singular) and 'n8n_delete_execution' (destructive), though it doesn't explicitly mention these distinctions. The mention of filtering adds specificity but doesn't fully differentiate from all siblings.
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 guidance on when to use this tool versus alternatives. It doesn't mention siblings like 'n8n_get_execution' for single executions or 'n8n_list_workflows' for listing workflows instead of executions. There's no context about prerequisites, typical use cases, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool updates a workflow but fails to mention critical details like whether this requires specific permissions, if changes are reversible, potential side effects (e.g., replacing all nodes/connections), or error handling. This is inadequate for a mutation tool with zero annotation coverage.
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 a single, efficient sentence that front-loads the core action ('Update an existing workflow') and lists updatable elements. There is no wasted text, though it could be slightly more structured (e.g., separating guidance from purpose).
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 the tool's complexity (mutation with 5 parameters, nested objects, no output schema, and no annotations), the description is incomplete. It lacks information on behavioral traits, output format, error conditions, and usage context, making it insufficient for safe and effective agent use despite the comprehensive 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?
The schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds minimal value by listing updatable fields ('name, nodes, connections, or settings'), but this is largely redundant with the schema. It doesn't provide additional syntax, format, or usage details beyond what the schema specifies.
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 clearly states the action ('Update') and resource ('an existing workflow'), specifying what can be updated ('name, nodes, connections, or settings'). It distinguishes from siblings like 'n8n_create_workflow' by focusing on updates rather than creation, though it doesn't explicitly mention all siblings like 'n8n_delete_workflow' or 'n8n_get_workflow'.
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 guidance on when to use this tool versus alternatives such as 'n8n_create_workflow' for new workflows or 'n8n_delete_workflow' for removal. It lacks context on prerequisites (e.g., needing an existing workflow ID) or exclusions, leaving usage implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves 'detailed information' but doesn't specify what that includes beyond 'nodes and connections' (e.g., metadata, status, permissions), whether it's a read-only operation, potential errors, or response format. For a tool with zero annotation coverage, this is a significant gap in transparency.
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?
The description is a single, well-structured sentence that efficiently conveys the core purpose without unnecessary words. It's front-loaded with the main action and resource, making it easy to parse. Every part of the sentence earns its place by specifying what information is retrieved.
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?
Given the tool's moderate complexity (retrieving detailed workflow data), lack of annotations, and no output schema, the description is minimally adequate but incomplete. It covers the basic purpose but misses behavioral details like read-only nature, error handling, and output structure. Without annotations or output schema, more context would be helpful for the agent to use it effectively.
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 input schema has 100% description coverage, with the 'id' parameter documented as 'The workflow ID'. The description adds no additional meaning beyond this, such as format examples or sourcing details. According to the rules, with high schema coverage (>80%), the baseline is 3 even without param info in the description.
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 clearly states the verb 'Get' and resource 'detailed information about a specific workflow including all nodes and connections', which is specific and actionable. It distinguishes from siblings like 'n8n_list_workflows' by focusing on a single workflow's details rather than listing multiple. However, it doesn't explicitly contrast with 'n8n_get_execution' or 'n8n_get_node_info', which slightly reduces clarity.
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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a workflow ID), exclusions, or comparisons to siblings like 'n8n_list_workflows' for overviews or 'n8n_get_execution' for execution data. This leaves the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the prerequisite of a 'valid trigger node' but fails to address critical aspects such as whether this operation requires specific permissions, what happens if activation fails, whether it's reversible, or any rate limits. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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?
The description is extremely concise with only two sentences, both of which are essential: the first states the core action, and the second adds a crucial prerequisite. There is no wasted language, and the information is front-loaded effectively, making it easy to grasp quickly.
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?
Given the tool's complexity as a mutation operation with no annotations and no output schema, the description is minimally adequate. It covers the basic purpose and a key prerequisite but lacks details on behavioral traits, error handling, or return values. While it meets a minimum threshold, it doesn't fully compensate for the absence of structured data, leaving room for improvement in completeness.
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 input schema has 100% description coverage, with the 'id' parameter clearly documented as 'The workflow ID to activate.' The description doesn't add any additional meaning beyond what the schema provides, such as format examples or constraints. Given the high schema coverage, the baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
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 clearly states the action ('Activate a workflow') and the resource ('workflow'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this from sibling tools like 'n8n_deactivate_workflow' or 'n8n_update_workflow' beyond the obvious activation vs. deactivation distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some contextual guidance by mentioning that 'The workflow must have a valid trigger node,' which implies a prerequisite for usage. However, it doesn't offer explicit guidance on when to use this tool versus alternatives like 'n8n_deactivate_workflow' or 'n8n_update_workflow,' nor does it specify any exclusions or edge cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the return format (IDs, names, active status) which is helpful, but doesn't disclose pagination behavior (implied by limit parameter), authentication requirements, rate limits, error conditions, or whether this is a read-only operation (though 'List' suggests it).
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?
Two concise sentences with zero waste: the first states the action and scope, the second specifies the return format. Every word earns its place, and the most important information (what it does) is front-loaded.
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?
For a read operation with 2 parameters and 100% schema coverage, the description provides adequate purpose and return format. However, without annotations or output schema, it lacks details on authentication, error handling, pagination beyond the limit parameter, and explicit safety assurances (read-only nature).
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 schema fully documents both parameters (limit and active). The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score of 3 for adequate coverage through structured data alone.
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?
The description clearly states the specific action ('List all workflows'), target resource ('in the n8n instance'), and scope ('Returns workflow IDs, names, and active status'). It distinguishes from siblings like n8n_get_workflow (single workflow) and n8n_list_executions (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying it returns 'all workflows' with certain fields, suggesting it's for browsing/overview purposes. However, it doesn't explicitly state when to use this versus alternatives like n8n_get_workflow for detailed info or n8n_list_executions for execution data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 prerequisites (active workflow, Webhook trigger node) but lacks details on behavioral traits like error handling, response format, rate limits, authentication needs, or side effects. For a tool that likely makes external HTTP calls, this is a significant gap in transparency.
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?
The description is front-loaded with the core purpose in the first sentence and adds essential prerequisites in the second. Both sentences earn their place by providing critical information without redundancy or fluff, making it efficient and well-structured.
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?
Given the tool's complexity (triggering external workflows via HTTP) and lack of annotations or output schema, the description is incomplete. It covers the basic purpose and prerequisites but omits details on behavior, response handling, and error scenarios, which are important for an agent to use this tool effectively.
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 schema already documents all parameters thoroughly. The description does not add any parameter-specific information beyond what the schema provides, such as examples for data format or header usage. Baseline 3 is appropriate when the schema does the heavy lifting.
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?
The description clearly states the specific action ('Trigger a workflow') and mechanism ('via its webhook URL'), with explicit mention of prerequisites ('workflow must be active and have a Webhook trigger node'). It distinguishes from siblings like n8n_activate_workflow or n8n_create_workflow by focusing on webhook-based triggering rather than workflow management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool (when triggering via webhook URL) and includes prerequisites (active workflow with Webhook trigger node). However, it does not explicitly state when not to use it or name specific alternatives among the sibling tools, such as n8n_activate_workflow for activation without triggering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions checking connection and verifying credentials, which implies a read-only diagnostic operation without side effects. However, it doesn't specify error conditions, response format, or any rate limits or authentication requirements beyond the verification aspect.
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?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core purpose and avoids redundancy, making it easy to understand quickly.
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?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but minimal. It covers the basic purpose but lacks details on what the check entails, expected outputs, or error handling. For a health check tool, more context on what 'verification' means would enhance completeness.
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?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to add parameter details, but it effectively explains what the tool does without parameters, maintaining clarity. Baseline is 4 for 0 parameters as per guidelines.
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?
The description clearly states the tool's purpose with specific verbs ('check connection', 'verify API credentials') and identifies the target resource ('n8n instance'). It distinguishes itself from sibling tools like workflow management or execution tools by focusing on system health and authentication verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (verifying API credentials and connection status), which suggests using this tool for initial setup or troubleshooting connectivity. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools, though the purpose naturally differentiates it from workflow-related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates the destructive nature ('Permanently delete') and irreversible consequence ('This action cannot be undone'), which are critical for a deletion tool. However, it doesn't mention authentication requirements, error conditions, or what happens to associated executions.
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?
The description is perfectly concise with two sentences that each serve distinct purposes: the first states the action, the second warns about consequences. There's no wasted language, and the most critical information (permanent deletion) is front-loaded.
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?
For a destructive operation with no annotations and no output schema, the description does well by emphasizing the irreversible nature. However, it could be more complete by mentioning what happens to associated executions or providing guidance on prerequisites (e.g., workflow must be deactivated first). The sibling context suggests this is part of a workflow management system where such considerations might be relevant.
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 schema description coverage is 100%, with the single parameter 'id' clearly documented in the schema. The description doesn't add any parameter-specific information beyond what the schema already provides, so it meets the baseline expectation for high schema coverage.
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?
The description clearly states the specific action ('Permanently delete') and target resource ('a workflow'), distinguishing it from siblings like n8n_deactivate_workflow or n8n_update_workflow. It uses precise language that leaves no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool (to permanently delete a workflow) and implicitly distinguishes it from deactivation (n8n_deactivate_workflow). However, it doesn't explicitly mention alternatives or provide specific exclusion criteria beyond the irreversible nature of the action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 describes the tool's behavior as retrieving documentation, which implies a read-only, non-destructive operation. However, it lacks details on output format, potential errors, or any rate limits. The description adds basic context but misses richer behavioral disclosure expected for a tool with zero annotation coverage.
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?
The description is two concise sentences that are front-loaded with the core purpose and followed by usage guidance. Every sentence earns its place by providing essential information without redundancy or fluff, making it highly efficient.
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 the tool's low complexity (single parameter with full schema coverage) and lack of output schema, the description is mostly complete. It clearly states the purpose and when to use it. However, without annotations or output schema, it could benefit from more details on what the documentation output looks like (e.g., format, structure) to fully guide the agent.
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?
The input schema has 100% description coverage, documenting the single parameter 'topic' with its enum values and descriptions. The description does not add any parameter-specific information beyond what the schema provides. With high schema coverage and only one parameter, the baseline is strong, but no extra semantic value is added in the description.
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?
The description explicitly states the tool's purpose: 'Get documentation and usage guide for n8n MCP tools.' It specifies the verb ('Get') and resource ('documentation and usage guide'), and distinguishes itself from sibling tools by focusing on help/documentation rather than operational actions like creating or managing workflows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Call this first to understand available capabilities.' This clearly indicates when to use this tool (as an initial step for learning) versus alternatives (the sibling tools for actual operations), offering strong contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![cursor-n8n-builder MCP server](https://glama.ai/mcp/servers/alicankiraz1/cursor-n8n-builder/badges/card.svg)](https://glama.ai/mcp/servers/alicankiraz1/cursor-n8n-builder)

Score Badge

Copy to your README.md:

[![cursor-n8n-builder MCP server](https://glama.ai/mcp/servers/alicankiraz1/cursor-n8n-builder/badges/score.svg)](https://glama.ai/mcp/servers/alicankiraz1/cursor-n8n-builder)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/alicankiraz1/cursor-n8n-builder'

If you have feedback or need assistance with the MCP directory API, please join our Discord server