n8n-MCP

Server Quality Checklist

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

Latest release: v2.68.4
Disambiguation3/5
Tools are mostly distinct, but there is potential confusion between validate_workflow and n8n_validate_workflow, which both perform workflow validation. Additionally, the large number of workflow-related tools (create, get, update full/partial, delete, list, validate, autofix, test, executions, evaluations, versions) may lead to misselection if descriptions are not carefully read.
Naming Consistency3/5
Naming is inconsistent: some tools use the 'n8n_' prefix (e.g., n8n_create_workflow), while others have no prefix (e.g., search_nodes, get_node) or use 'tools_' prefix (tools_documentation). This mix of conventions reduces predictability, though verb_noun structure is generally followed.
Tool Count4/5
24 tools is on the high side for a single server, but the n8n domain is complex and the tools cover a wide range of functionality including workflows, nodes, templates, credentials, executions, and auditing, making the count reasonable.
Completeness4/5
The tool surface covers most major operations for n8n management: CRUD for workflows, nodes, templates, credentials, and data tables; plus execution, testing, validation, versioning, and auditing. Minor gaps exist, such as no direct tool for managing workflow tags (handled via partial update) and no import/export functionality.
Average 4.1/5 across 24 of 24 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 92 of 94 community issues answered or closed in the last 6 months
- 110 commits in the last 12 weeks
- Last stable release on August 9, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint: true and readOnlyHint: false, so the description adds some context (e.g., 'Schema is immutable after creation'). However, it does not elaborate on safety or side effects beyond what annotations provide.
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 (one sentence plus structured schema). It front-loads the list of actions. The schema is well-organized with clear per-parameter details. No unnecessary text.
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?
With 14 parameters, high complexity, and no output schema, the description provides a minimal overview. It covers actions but lacks context on return values, error handling, or workflow. The schema fills many gaps, but the description alone is incomplete.
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 baseline is 3. The description groups actions with parameter usage (e.g., 'For createTable: table name'), adding marginal value but not deeply explaining parameter interactions or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Manage n8n data tables and rows' and lists 10 actions, which is clear enough but generic. It does not differentiate from sibling tools beyond the specific domain of data tables, but the sibling tools are mostly workflow/credential management, so differentiation is minimal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It simply lists actions without context for selection. The description does not provide any usage boundaries or recommendations.
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?
Annotations already provide read-only, open-world, and idempotent hints. Description adds that it returns errors/warnings/suggestions but does not elaborate on response structure or edge cases.
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 conveying core purpose and output. No redundant information, well front-loaded.
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?
No output schema, so description should detail return format. Lacks explanation of validation profiles, which are documented only via enum values. Does not address potential confusion with sibling 'validate_workflow'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed property descriptions. Description restates the parameters' purpose without adding new meaning or examples.
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?
Description clearly states it validates a workflow by ID, checking nodes, connections, expressions, and returning results. However, it does not differentiate from the sibling 'validate_workflow', which may cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like n8n_audit_instance or n8n_health_check. Does not specify prerequisites or when not to use.
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?
The description reinforces the destructive hint from annotations by stating 'cannot be undone', but adds no new behavioral details beyond what annotations already provide.
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?
Extremely concise with two sentences, no superfluous information, and the key point 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 simple deletion tool with one parameter and annotations covering destructiveness, the description is adequate; however, it does not specify return value or confirmation behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds no extra meaning to the single parameter (id) beyond its schema documentation.
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 action (permanently delete) and the resource (workflow), distinguishing it from sibling tools like creation or listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no conditions or prerequisites mentioned, and no indication of when deletion is appropriate.
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?
Annotations already indicate the tool is not read-only and not destructive, and the description adds valuable context: 'Created inactive' and 'Returns workflow with ID'. It does not disclose potential side effects or permission requirements, but the annotations plus these key behaviors provide adequate 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 two concise sentences: the first states the core action, the second lists requirements and key behavior. It is front-loaded and every sentence adds necessary information without redundancy.
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 moderate complexity (nested nodes/connections) and no output schema, the description covers the essential behavior (inactive creation, return with ID) and requirements. The schema fills in parameter details, so the description is adequate for invoking the tool correctly, though it could add more on connection structure or activation steps.
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 covers all parameters with descriptions, so the baseline is 3. The description only reiterates that name, nodes, and connections are required, and does not add semantic depth beyond the schema. It is not misleading or insufficient, but it adds minimal value.
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 verb 'Create' and the resource 'workflow', distinguishing it from sibling tools like n8n_update_partial_workflow and n8n_delete_workflow. It also specifies the required fields, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides prerequisites but gives no explicit guidance on when to use this tool versus alternatives like n8n_update_full_workflow or n8n_deploy_template. It does not mention when not to use it or how it differs from update/delete operations, leaving usage context largely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description includes delete action, which is destructive, but annotations set destructiveHint: false. This contradiction undermines transparency. However, the description itself is otherwise detailed about behaviors like NOT_SUPPORTED errors and security logging.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph with key info front-loaded. Somewhat dense but efficient for the complexity. Could benefit from bullet points but still readable.
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?
Covers usage guidelines, edge cases (NOT_SUPPORTED), pagination, security, and parameter interactions. Lacks output format details but no output schema exists. Adequately complete for a multi-action tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, yet description adds significant value: explains cursor origin, includeUsage behavior (full scan, ignores limits), getSchema for data fields. This goes well beyond the schema descriptions.
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 manages n8n credentials and lists all actions (list, get, create, update, delete, getSchema). It differentiates from sibling tools which handle templates, health, workflows, etc., making the purpose distinct and specific.
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?
Provides explicit guidance: use getSchema before create, pagination with cursor for list, and notes on deployment compatibility affecting list/get. Does not explicitly state when not to use the tool, but contextual hints are sufficient.
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?
Annotations indicate idempotentHint=true and destructiveHint=false, consistent with a non-destructive fixer. The description adds that fixes can be previewed or applied, and lists specific issue types. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loading the action and purpose in a single short paragraph. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool does and lists fix types, but does not describe the output format or return value. Given no output schema, this is a gap for agents needing to parse results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description lists fixTypes but does not add significant meaning beyond the enum values. Parameters are adequately described in the schema.
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 automatically fixes common workflow validation errors, with explicit examples of fix types (expression format, typeVersion, etc.). It distinguishes from sibling tools like validate_workflow by mentioning both preview and apply modes.
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 implies usage for fixing validation errors but does not provide explicit when-to-use vs when-not-to-use guidance or compare with alternatives like manual updates via n8n_update_*. No exclusions mentioned.
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?
Annotations indicate it's a write operation (readOnlyHint: false) and not destructive. The description adds context: deploys first then auto-fixes common issues, and returns workflow ID, required credentials, and fixes applied. This adds value beyond annotations.
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?
Description is concise with two sentences: first states the main action, second summarizes key feature and output. No unnecessary words.
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 five parameters and no output schema, the description lacks details on parameter behavior (e.g., what happens if autoFix is false), error cases, or prerequisites. It covers the core but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter is well-described in the schema. The description does not add meaningful detail beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool deploys a workflow template from n8n.io to the instance, with specific verb 'deploy' and resource 'workflow template from n8n.io'. It distinguishes from siblings like n8n_create_workflow or n8n_update_full_workflow by focusing on marketplace templates.
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 implies usage for deploying marketplace templates but does not explicitly state when to use this versus n8n_create_workflow or other sibling tools. No guidance on prerequisites or exclusions.
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?
Annotations already declare readOnlyHint, idempotentHint, and no destructive effects. Description adds minimal extra behavioral context beyond purpose, but does not contradict annotations.
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 sentences, front-loaded with key purpose, no unnecessary words.
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?
No output schema, and description does not mention return values. For a health check tool, missing output details reduces completeness, but basic usage is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and well-described. Description adds value by explaining diagnostic mode includes env vars and tool status, but does not elaborate further, keeping it at baseline level.
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?
Clearly states the tool checks n8n instance health and API connectivity. Distinguishes two modes. No sibling tool with similar purpose.
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?
Explicitly recommends using diagnostic mode for detailed troubleshooting, providing context for when to choose that mode. However, no guidance on when not to use the tool or alternatives.
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?
Annotations declare readOnlyHint and idempotentHint, which the description aligns with by describing a read-only search operation. The description adds value by specifying the maximum result limit (20) and the token impact of includeOperations ('~100-300 tokens per result'), going beyond what annotations provide. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three short sentences that front-load the main purpose, provide example usage, and state key behavior. Every sentence is necessary and informative with zero waste.
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?
There is no output schema, so the description should explain the return structure. It only mentions 'Returns max 20 results' but does not specify what fields each result contains (e.g., node name, description, type). Given the tool has 6 parameters, this lack of return value detail makes it somewhat incomplete.
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 baseline is 3. The description contributes little extra meaning beyond the schema; it gives an example query ('query="webhook"') and mentions the token cost for includeOperations, but these are minor additions. Adequate but not exceptional.
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 searches n8n nodes by keyword, provides example queries, and distinguishes itself from siblings like get_node (which retrieves a specific node) and search_templates (which searches templates). The verb 'Search' with resource 'n8n nodes' is specific and unambiguous.
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 gives clear usage instructions: pass a query string, returns up to 20 results, and explains when to use optional parameters like includeExamples and includeOperations. It provides context for when to use this tool versus alternatives (e.g., search vs. get_node), though it does not explicitly state 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations confirm read-only, idempotent, and non-destructive behavior. The description adds value by detailing the deep workflow scanning (50+ regex patterns), checks (unauthenticated webhooks, etc.), and output format (markdown report). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the tool's purpose, and provides specific details without unnecessary words. Every sentence adds value.
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 4 parameters, no output schema, and a complex tool, the description covers the audit scope, checks, and output type. It mentions remediation using sibling tools, which aids completeness. Could include more on output structure, but sufficient for an audit tool.
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?
All 4 parameters have schema descriptions (100% coverage). The description mentions 'all 5' and 'all 4' default checks, which is already in the schema. It does not add significant meaning beyond the schema, earning the baseline 3.
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 'Security audit of n8n instance' and lists specific areas (credentials, database, nodes, instance, filesystem) and custom checks. It distinguishes from sibling tools by focusing on auditing and remediation, not workflow management or creation.
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 mentions returning an actionable markdown report with remediation steps using sibling tools, implying when to use it (for security audit). However, it does not explicitly state when not to use it or provide alternatives, though the read-only nature suggests safe usage anytime.
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?
Discloses destructive capability (delete) and provides mode details for get actions. Annotations already indicate destructiveHint=true; description adds context on when data is modified or read. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey purpose and usage pattern. Front-loaded with key information, no extraneous content.
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 16 parameters and no output schema, description provides a high-level guide. Schema supplies detailed conditional logic. Could be more structured by action group, but sufficient for understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value by linking actions to relevant parameters (e.g., id for get/delete, mode for get), but does not significantly expand on schema descriptions.
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?
Clearly states it manages workflow executions with three specific actions (get, list, delete). Distinguishes from sibling tools which focus on workflows, nodes, templates, etc.
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?
Provides explicit usage pattern: 'Use action=get with id...' etc. Does not explicitly mention alternatives, but sibling tools are sufficiently different, so context is clear.
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?
Annotations already indicate destructive behavior (destructiveHint=true) and non-read-only. The description adds n8n version requirements, the projectId default to 'personal', and the critical limitation that folder contents are only visible as counts. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four information-dense sentences, front-loaded with purpose and version requirements. Every sentence adds value and there is no filler or repetition.
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 complex 10-parameter tool with no output schema, the description plus schema covers actions, requirements, defaults, cross-tool relationships, and a key API limitation. Minor omissions like error handling or permission requirements are not critical given the schema's richness.
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 baseline 3. The description repeats the projectId default and mentions parentFolderId in other tools, but adds no new parameter semantics beyond what the schema already provides.
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 manages workflow folders and enumerates six specific actions (create, list, get, rename, move, delete). The note that the API cannot report which folder a workflow is in further distinguishes this tool's scope from sibling workflow-management tools.
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?
It explicitly directs workflow-folder placement to n8n_create_workflow and n8n_update_partial_workflow, clarifying the boundary between folder management and workflow-to-folder association. It also gives version/instance requirements and warns about the API limitation, providing strong context. It could be more explicit about 'when not to use' but the guidance is solid.
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?
Annotations indicate readOnlyHint=false and destructiveHint=false, which the description does not contradict. The description adds transparency by stating it auto-detects trigger type and supports webhook/form/chat, but it does not detail behavior like waiting for response or error handling. Overall, it provides useful context beyond annotations.
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: two sentences plus a note. It front-loads the purpose and immediately provides actionable details. Every sentence is essential, with no fluff or repetition.
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 complexity of 10 parameters with conditional behavior across trigger types, the description covers the core functionality well. However, it does not explain the output or return value (no output schema), and it could better detail parameter usage per trigger type. Still, the schema descriptions compensate, making it reasonably complete.
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?
With 100% schema description coverage, the input schema already documents each parameter thoroughly. The description adds value by summarizing supported trigger types and auto-detection, but it does not explain parameter relationships or conditional usage (e.g., which parameters apply to which trigger type). It meets the baseline for high 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 tool's purpose: 'Test/trigger workflow execution.' It specifies auto-detection of trigger type and lists supported types (webhook, form, chat), which distinctively sets it apart from sibling tools that edit, validate, or retrieve workflows.
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 a clear context for when to use the tool (testing/triggering workflows) and includes a constraint note about external execution only for specific trigger types. However, it does not explicitly address when not to use the tool or mention alternatives among sibling tools, leaving some ambiguity.
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?
The description implies a full replacement behavior by requiring complete nodes and connections, which adds some context beyond annotations. However, it does not elaborate on side effects, return values, or error scenarios. Annotations cover read-only and destructive hints, so the bar is lowered, but the description still contributes limited behavioral detail.
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 front-loads the purpose, states the key requirement, and names the alternative. Every word adds value with no redundancy or filler.
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 7 parameters and nested objects, the description is brief, but the schema provides rich parameter details and the description successfully conveys the critical distinction from the partial update tool. It lacks explicit mention of return behavior and the effect of omitting optional fields, but overall it is sufficiently complete for an agent given the schema richness.
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 has 100% parameter coverage with descriptive text for each field, including 'Complete array of workflow nodes' and 'Complete connections object'. The description merely repeats the completeness requirement without adding new meaning, so it stays at the baseline 3.
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 identifies the action as a 'Full workflow update' and specifies the resource. It explicitly distinguishes itself from the sibling tool by naming n8n_update_partial_workflow, making its purpose unambiguous and distinct.
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?
It provides explicit guidance by stating 'Requires complete nodes[] and connections{}' and directing users to the partial update tool for incremental changes. This gives clear when-to-use and when-not-to-use context.
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?
Annotations already declare readOnlyHint and idempotentHint, so safety is clear. The description adds behavioral context by explaining the modes and profiles, and includes an example. No contradictions. It could mention that it doesn't modify state, but annotations already cover that.
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 sentences and an example. First sentence states purpose, second gives usage guidance. No redundancy. The example is placed at the end for reference. Every part earns its place.
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 existence of an output schema (not shown) and the detailed parameter descriptions, the description is largely complete. It explains modes and profiles. It could mention the output structure (errors/warnings/suggestions) but that is covered by the output schema. Overall sufficient for the complexity.
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 baseline is 3. The description adds an example and hints about simple vs complex nodes, but the schema already provides detailed descriptions for each parameter. The added value is moderate.
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 validates n8n node configuration, specifies two modes (full/minimal), and provides a concrete example. This distinguishes it from sibling validation tools like validate_workflow by focusing on node-level validation.
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 gives explicit guidance on when to use each mode ('full' for comprehensive, 'minimal' for quick check). It does not explicitly exclude alternatives or state when not to use it, but the context implies it's for node config vs workflow validation. A clear use case is provided.
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?
Annotations already declare readOnlyHint and idempotentHint, indicating safe, repeatable usage. The description adds value by stating that it returns errors/warnings/fixes, providing behavioral context beyond annotations.
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 sentences that are front-loaded with the purpose, clearly stating the scope, return type, and usage context. Every sentence earns its place with no waste.
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 complexity (nested parameters, output schema), the description covers the core purpose, validation scope, and return type. It could mention validation profiles but that is covered by the schema, so overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description lists validated categories (structure, connections, expressions, AI tools) which map to the schema's options but adds no essential meaning beyond what the schema provides.
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 starts with 'Full workflow validation' and specifies the validated aspects: structure, connections, expressions, AI tools. It clearly distinguishes from sibling tools like deploy or health check by stating 'Essential before deploy'.
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 by stating 'Essential before deploy', guiding the agent to use this tool before deployment. It does not explicitly state when not to use or list alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. The description adds value by clarifying the minimal metadata return and pagination behavior (hasMore/nextCursor). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the main purpose. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with no output schema, the description fully covers return fields, pagination, and metadata scope. No additional details are 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?
Schema coverage is 100% with descriptions for all 6 parameters. The description does not add new parameter details beyond what the schema provides, so baseline 3 is appropriate.
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 it lists workflows with minimal metadata, specifies returned fields (id/name/active/dates/tags), and mentions pagination. This distinguishes it from sibling tools like 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing workflows with limited data and pagination, but does not explicitly state when to avoid or use alternatives. The mention of minimal metadata helps agents infer appropriate context.
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?
Annotations indicate readOnlyHint and idempotentHint, which the description supports. It adds behavioral context like 'lightweight workflow pattern summaries mined from 2700+ templates,' without contradicting annotations.
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 sentences, front-loaded with the main purpose, and efficiently covers five modes without waste. Every sentence adds value.
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?
No output schema is provided, and the description does not detail return values beyond mentioning 'lightweight workflow pattern summaries' for one mode. While parameters specify filtering, the response format is unclear, leaving some gaps.
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?
Schema coverage is 100%, and the description adds value by explaining how parameters are used in different modes (e.g., 'task' for by_task vs patterns). This supplements the schema descriptions well.
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 'Search templates with multiple modes' and enumerates five distinct modes, making the tool's purpose specific and differentiating it from sibling tools like search_nodes.
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 explicitly lists when to use each search mode (e.g., 'use searchMode=''keyword'' for text search'), providing clear context for selection. It does not explicitly state when not to use this tool, but the guidance is sufficient.
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?
Annotations declare readOnlyHint and idempotentHint, indicating safe, read-only behavior. The description adds detail about mode options, which is consistent and useful beyond what schema provides.
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 sentences: first states purpose, second explains mode. No redundancy, front-loaded, and every word adds value.
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 simple retrieval tool with two parameters and no output schema, the description is adequate. It covers purpose and parameter usage. Could mention permissions or return format, but not critical given annotations.
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?
Schema coverage is 100% with descriptions. The description adds a concise summary of mode options with their meanings, supplementing the enum descriptions.
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 retrieves a template by ID, with a specific verb and resource. It distinguishes from sibling tools like n8n_deploy_template or validate_workflow, which have different purposes.
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 guidance on using the 'mode' parameter to control response size, but does not explicitly state when to use this tool over alternatives. However, the purpose is clear enough.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. The description adds valuable context: explains the n8n draft/publish model, what each mode returns, and that active mode requires a live version. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph with no wasted sentences. It is well-organized, starting with the core purpose, then explaining the draft/publish model, then listing modes compactly. Every sentence adds value.
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 complexity (multiple modes, draft/publish model), the description covers key aspects. It explains what each mode returns, though a brief example of the output structure would enhance completeness. No output schema exists, but the description adequately hints at return types.
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?
Schema has 100% coverage, so baseline is 3. The description adds meaning beyond schema: explains the draft/publish model, clarifies that mode='active' returns published graph, and suggests using mode='structure' first to discover node names for mode='filtered'.
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 'Get workflow by ID with different detail levels.' It specifies the verb (Get), resource (workflow), and the key differentiator (different detail levels). This distinguishes it from sibling tools like get_node or get_template.
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 explicit context for each mode (e.g., 'use mode='active' to see the published graph', 'use mode='filtered' to read one heavy node'). It also warns that mode='active' errors if no live version. It could be improved with a more explicit 'use this when... and not when...' but is still clear.
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?
The description goes beyond annotations by enumerating all operation types and detailing specific requirements for patchNodeField, setNodeGroups, and moveToFolder (including version note). This enriches the behavioral profile significantly, though it omits return format and potential side effects of removal operations. The annotation destructiveHint=false is not directly contradicted because the description does not explicitly claim non-destructive behavior.
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 dense but well-structured: one clear opening sentence, a list of operation types, and three specific clarifications. Every sentence adds value, and the final pointer to tools_documentation avoids redundancy. It is slightly long but appropriate for the tool's complexity.
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 tool this complex, the description covers the main operation categories and critical constraints, including version requirements. However, it lacks specification of return values and error/atomicity behavior (though continueOnError is in the schema). The explicit reference to tools_documentation for full details partially compensates, but the absence of output description is a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, giving baseline 3, but the description markedly enhances parameter understanding: it clarifies that operations must have a 'type' field and provides concrete shapes for key operations (e.g., patchNodeField with fieldPath and patches, setNodeGroups with name/nodeNames). This is far more informative than the generic array description in the schema.
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 starts with 'Update workflow incrementally with diff operations,' clearly stating the specific verb (update), resource (workflow), and mode (incremental diff). This distinguishes it from sibling tools like n8n_update_full_workflow and n8n_create_workflow, making its purpose immediately obvious.
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 phrase 'incrementally' implies usage for partial changes, contrasting with full replacement, but the description does not explicitly state when to use this tool over n8n_update_full_workflow or provide exclusions. It conveys clear context without naming alternatives or when-not cases.
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?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds valuable behavioral details: rollback creates a backup, prune keeps N most recent versions, and old backups are automatically pruned. It does not contradict annotations and provides useful context beyond them.
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 overall purpose, followed by bullet-style mode explanations. Every sentence adds value without redundancy. It is concise and well-structured, allowing quick scanning.
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 complexity (7 parameters, 5 modes, no output schema), the description covers all modes, parameter requirements, and automatic pruning behavior. It does not detail return values or error handling, but the schema and context signals fill gaps. Overall, it is sufficiently complete.
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?
Schema coverage is 100%, so parameters are already documented. The description enriches semantics by specifying mode-specific requirements (e.g., workflowId required for list, rollback, delete, prune) and explaining behavior like validation before rollback and deleteAll flag. This adds meaning beyond the schema.
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: 'Manage workflow version history, rollback, and cleanup.' It distinguishes from sibling tools by focusing specifically on versioning operations, and enumerates five distinct modes (list, get, rollback, delete, prune) that cover the functionality.
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 for each mode (e.g., 'list: Show version history for a workflow') and notes that versions are scoped to the n8n instance. It does not explicitly state when to use alternative sibling tools (e.g., n8n_delete_workflow for deleting workflows), but the mode descriptions sufficiently guide appropriate usage.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the tool is safe. The description adds context about parameter effects (quick start vs specific docs, depth levels), which goes beyond annotations and helps the agent understand 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?
Three sentences, no wasted words. The first sentence states the purpose, followed by usage guidance. Perfectly front-loaded and concise.
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?
The description covers purpose and usage but does not mention the output format (e.g., returns text/markdown). However, given the tool's simplicity and no required parameters, it is mostly complete. An explicit note about return type would raise it to 5.
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?
Schema coverage is 100%, with both parameters documented. The description adds usage patterns: 'Call without parameters for quick start guide' and specific parameter uses, enriching the schema meaning with real-world invocation scenarios.
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 uses the specific verb 'Get documentation' for 'n8n MCP tools', clearly defining the tool's purpose. It distinguishes from sibling tools by being a meta-documentation tool, not a node or workflow tool.
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 usage patterns: 'Call without parameters for quick start guide', 'Use topic parameter to get documentation for specific tools', and 'Use depth="full" for comprehensive documentation'. It doesn't explicitly state when not to use this tool or mention alternatives, but the guidance is sufficient for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. Description adds substantial behavioral context: token estimates for detail levels, mode behaviors, and default values. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, then detail and mode explanations, ending with usage tips. Every sentence adds value; no redundancy.
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?
Covers key output characteristics (token estimates) and mode behaviors. Could mention response format or structure, but given read-only nature and no output schema, it is sufficiently complete for an info-retrieval tool.
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?
Schema coverage is 100%, so baseline is 3. Description adds value by clarifying token estimates for detail levels and usage advice for modes (e.g., 'standard=essential properties (recommended)'), exceeding minimal schema info.
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 'Get node info' with specific verb and resource. It distinguishes from sibling tools like search_nodes and validate_node by focusing on retrieving schema info with detail levels and modes.
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?
Provides explicit guidance for mode usage: 'Use format="docs" for readable documentation, mode="search_properties" with propertyQuery for finding specific fields.' Does not explicitly exclude scenarios, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description discloses version gating, API key scope requirements, the need for workflow:execute permission, and a performance warning for list_cases ('paginate - cases can be large'). It also explains what cancel does ('stop a running run'). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with a clear summary and then requirements and an action list. Every sentence carries substantive information (prerequisites, action semantics, pagination warning) with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains key return concepts: 'aggregated metrics' for get_run, 'per-case results' for list_cases, and 'list runs for a workflow' for list_runs. It also covers prerequisites, action semantics, and pagination guidance. This is complete for a multi-action tool with six parameters.
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?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining run requires an evaluation trigger, get_run returns aggregated metrics, and list_cases can be large and needs pagination, which enriches the meaning of the action parameter and relates to limit/cursor. It does not cover all parameters, but it goes beyond the schema.
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 opens with 'Run and read evaluation test runs for a workflow,' which is a specific verb+resource statement. It clearly distinguishes this tool from siblings like n8n_executions and n8n_test_workflow by focusing on 'evaluation' test runs, and then enumerates the five actions.
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 explicit context for when the tool can be used, including version requirements (n8n >= 2.30 for reading, >= 2.32 for run/cancel) and permission requirements (API key scope, workflow:execute). It does not name alternative tools for exclusion, but the 'evaluation' qualifier and action list make the intended use clear.
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:

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

Score Badge

Copy to your README.md:

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

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/czlonkowski/n8n-mcp'

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