n8n MCP Server

by verzth

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct resource-action pair (workflow, execution, credential, tag, variable, project, user, package). Similar operations like delete vs archive are explicitly distinguished in descriptions, leaving no ambiguity.
Naming Consistency4/5
All tools consistently use the n8n_ prefix with a verb_noun pattern. Minor deviations include plural nouns for lists (list_workflows) versus singular for single items (get_workflow), and a few non-verb-first names like n8n_discover and n8n_get_credential_schema, but the overall pattern remains predictable.
Tool Count4/5
With 39 tools, this is a large set, but it spans the full n8n API surface across workflows, executions, credentials, tags, variables, projects, users, and community packages. Each tool serves a clear purpose, so the count is justified by the broad domain.
Completeness4/5
Core workflows have full lifecycle coverage (CRUD, activate, archive, tags), and executions/credentials also have comprehensive operations. Minor gaps exist for projects (only list/create) and users (only list), but these do not block primary workflow management workflows.
Average 4/5 across 39 of 39 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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?
Annotations already indicate this is a mutation (readOnlyHint false), non-idempotent, and non-destructive. The description adds only the purpose clause, offering no extra behavioral context such as name uniqueness, permissions, or side effects. It does not contradict annotations but contributes little beyond what structured data already conveys.
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 short and front-loaded with the main action. The 'Args' block duplicates schema information, adding minor redundancy, but overall it remains concise and well-structured.
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?
With no output schema, the description should clarify return values or creation effects; it does not. It explains what a project is for but omits any prerequisite or post-creation behavior. For a simple tool, this is a notable gap that leaves the agent uncertain about what happens after the call.
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 fully documents the single 'name' parameter with type, minLength, and description. The description repeats this as 'Args: name (string): Project name', adding no new semantic detail. Baseline 3 is appropriate since the schema carries the full burden.
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 'Create a new project for organizing workflows and credentials.' It identifies the specific verb (create) and resource (project), and differentiates from sibling create tools (workflow, credential, tag, variable) by naming the resource type and its purpose.
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 when one needs a project to organize workflows and credentials, but it provides no explicit when-to-use guidance or alternatives. No exclusions or prerequisites are mentioned, so the agent gets minimal direction on selecting this tool over other n8n create tools.
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?
Annotations indicate readOnlyHint=false and idempotentHint=false, but the description only says 'Checks for...' which sounds read-only, and does not disclose any potential side effects, report output format, or operational requirements. The description adds little beyond the annotations, and the lack of detail about mutation risk is notable.
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 brief and structured with an Args list. However, the 'etc.' is filler and the prose is slightly redundant with the schema, but it remains easily scannable and appropriately sized for a simple tool.
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?
The tool has no output schema, yet the description does not explain what the audit report contains or how it is returned (e.g., as a response project, file, or console output). It also omits behavior when categories are omitted (though the schema covers this). The description lacks sufficient context for an agent to invoke the tool and interpret the result robustly.
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 both parameters, and the description's Args section mostly duplicates the schema (including enum values and default). It provides no additional semantics, examples, or parameter interactions, so a 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 the tool generates a security audit report for the n8n instance, listing specific check areas (security misconfigurations, abandoned workflows, credential exposure). This specific verb+resource distinguishes it from sibling CRUD tools like n8n_list_workflows or n8n_delete_execution.
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 purpose implies it is used for security audits, but there is no explicit when-to-use guidance or mention of alternatives. The sibling context makes the usage fairly clear, but the description itself lacks direct exclusions or comparative guidance.
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 adds minimal behavioral context beyond the annotations: it notes the tag name must be unique, which implies a duplicate will fail. However, this constraint is already present in the schema, and no additional behaviors (e.g., error handling, auth requirements, side effects) are disclosed. Annotations already indicate non-read-only and non-destructive, so the description does not contradict them.
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 succinct and front-loaded with the main action. It includes an Args list, which is somewhat redundant with the schema but still clear and compact. No wasted words, though the Args section adds little value given the schema.
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 create operation with one parameter, no output schema, and adequate annotations, the description is mostly complete. It explains the purpose and the uniqueness constraint. It could optionally mention what happens on duplicate, but that is not essential for tool selection.
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%, with the single parameter 'name' documented as 'Tag name (must be unique)'. The description repeats this in its Args list without adding any new meaning beyond the schema, so it earns the baseline score.
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 creates a new annotation tag for organizing workflows, using a specific verb and resource. It distinguishes itself from sibling tools like n8n_update_tag and n8n_delete_tag by focusing on creation.
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 is provided on when to use this tool versus alternatives such as n8n_list_tags, n8n_update_tag, or n8n_delete_tag. There is no mention of prerequisites, exclusions, or comparison to other tag-related operations.
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?
The description adds no behavioral context beyond what the annotations already provide. It does not mention what happens if the tag does not exist, error behavior, or that it is idempotent. The phrase 'existing tag' hints at a precondition, but the description is essentially a tautology of the title and offers no new insights.
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 a single purpose sentence and a compact argument list. It is front-loaded and contains no redundant or filler content. Every element serves a clear function.
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 tool is simple and has no output schema, but the description lacks details on return values, error conditions, or side effects. The provided information covers the basic operation and arguments, but it is not fully complete for an agent that might need to know what happens on success or failure.
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?
Both parameters are fully described in the input schema (id: 'Tag ID', name: 'New tag name'), and the description repeats the same information without adding extra meaning. Schema coverage is 100%, so the baseline is 3; the description does not enhance understanding 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 'Rename an existing tag' uses a specific verb (rename) and resource (tag), clearly distinguishing it from sibling tools like n8n_create_tag, n8n_delete_tag, and n8n_list_tags. It also matches the tool title and leaves no ambiguity about what operation is performed.
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 the tool is for renaming existing tags, which is a clear context, but it does not explicitly mention when to use it versus alternatives like create or delete. No exclusions or comparisons are provided, so it relies on the reader's inference from the purpose.
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 is consistent with annotations (readOnly, idempotent, non-destructive) but adds no extra behavioral context such as error handling or return format. Annotations cover the safety profile, so it's acceptable but not enriched.
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 and front-loaded with the purpose, followed by the parameter list. Every word earns its place with 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?
For a simple one-parameter, read-only tool with rich annotations, the description is sufficiently complete. It could mention the return format, but the action 'Get the tags' strongly implies the output, and no output schema is present.
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%; the description repeats the same 'id' parameter definition without adding new meaning. It contributes no additional semantic value beyond the schema.
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 retrieves tags for a specified workflow, using a specific verb ('Get') and resource ('tags'). It implies differentiation from sibling tools like n8n_list_tags by focusing on 'a specific workflow', but does not explicitly name alternatives.
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?
Usage context is implied by the action and parameter: you need a workflow ID and want its tags. However, there is no explicit guidance on when to use this vs. alternative tools, nor any exclusions or prerequisites.
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=false, destructiveHint=false, and idempotentHint=true, which outline the safety profile. The description adds no behavioral details beyond the action 'update'—for example, whether it overwrites the entire value, requires an existing variable, or returns the updated object. It neither contradicts the annotations nor enriches them, so a mid-range score is appropriate.
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: a one-sentence purpose followed by a clean, bullet-style Args list. Every word earns its place, and the structure front-loads the core action before parameter details. No redundant fluff exists.
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 update tool with only three required parameters, no output schema, and annotations covering safety semantics, the description is largely sufficient. It states the operation and lists all arguments, though it lacks any mention of return values or when a variable must already exist. This minor gap keeps it from a perfect score.
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%, and the description repeats the same parameter descriptions as the schema (id, key, value). No additional meaning is added regarding value format, key semantics, or relationship between id and key. Since the schema already fully documents parameters, the baseline of 3 applies.
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 action: 'Update a workflow variable's value.' This specifies a distinct verb (update) and resource (workflow variable), and the sibling set includes create and delete variants, so it is clearly differentiated from alternatives.
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 creating or deleting a variable. It does not mention any prerequisites, such as needing an existing variable, nor does it reference sibling tools for alternative actions. The 'Args' section only restates parameter names, not usage 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 destructiveHint=true, lowering the bar. The description adds critical context by stating 'Removes it from all workflows that use it,' which goes beyond a generic delete and informs the agent of the cascading side effect. This is valuable behavioral disclosure beyond the annotation.
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 prose is tight: two sentences that state purpose and side effect. However, the 'Args' block duplicates the schema's parameter description, which is redundant and slightly wasteful. It's still concise overall but not as lean as it could be.
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 single-parameter delete tool with complete annotations and schema coverage, the description adequately covers the action and its primary side effect. It doesn't mention return values or error handling, but for a destructive operation with no output schema, the absence is not a significant gap. The description is reasonably complete for the tool's simplicity.
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%: the 'id' parameter is described as 'Tag ID to delete' in the schema. The description repeats this in the Args section without adding new meaning (e.g., format, constraints, or behavior). Since the schema already fully documents the parameter, the baseline of 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 uses the specific verb 'Delete' with the resource 'a tag' and immediately clarifies the scope: 'Removes it from all workflows that use it.' This distinguishes it from sibling delete tools like n8n_delete_workflow or n8n_delete_execution, making the purpose unmistakable.
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 explicit guidance on when to use this tool versus alternatives. It doesn't mention that deleting a tag is different from unassigning it (e.g., via n8n_set_workflow_tags), nor does it state any prerequisites or exclusions. The usage is only implied by the tool name and purpose, not explicitly guided.
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 the tool as read-only, non-destructive, and idempotent. The description adds the scope that this lists all tags instance-wide, which is useful behavior context not present in annotations. However, it does not disclose additional traits like pagination behavior, ordering, or error conditions. This is an acceptable but not rich addition 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 concise and well-structured. It leads with a clear one-sentence purpose, followed by a compact list of parameters. Every line provides necessary information, and there is no redundant filler.
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 tool is simple and the annotations cover safety, but there is no output schema and the description does not explain the structure of the returned tags (e.g., fields like id and name). For an agent to fully understand what it will receive, some return-format description would be helpful. The description covers pagination and limit, but misses explaining the expected output shape.
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 provides no descriptions for properties (0% coverage), so the description carries the burden. It explains 'limit' as 'Max results (1-250, default 20)' and 'cursor' as 'Pagination cursor', both of which add semantic meaning beyond the raw schema. While not deeply detailed, it compensates for the missing 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 uses the specific verb 'list' with a clear resource ('annotation tags') and scope ('all... in the n8n instance'). It clearly differentiates from sibling tools like n8n_get_workflow_tags (which is scoped to a workflow) and n8n_create_tag (which is a write operation).
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 does not explicitly state when to use this tool versus alternatives. It implies a global listing of tags, but does not mention that for tags on a specific workflow one should use n8n_get_workflow_tags, or that n8n_create_tag is for creating new tags. The lack of exclusions or alternative suggestions leaves the decision to the agent with no guidance.
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 adds that the tool makes a 'test request to the service', which goes beyond the annotations. However, it does not disclose details like potential side effects, authentication requirements, or what occurs on success/failure beyond the basic notion of testing validity.
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 and front-loaded. The first sentence clearly states the purpose, and the subsequent parameter list is directly relevant. No unnecessary words or repetition.
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 simple one-parameter tool with no output schema, the description provides adequate but minimal context. It explains what the tool does but does not specify the return value or behavior on success/failure, which could be ambiguous. Additional details about expected outputs would improve 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 already provides a full description for the 'id' parameter, and the description's mention of 'Credential ID to test' adds no new information beyond the schema. With 100% schema coverage, the baseline score applies.
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 a specific verb ('test') and resource ('credential'), and specifies the action ('making a test request to the service'). It distinguishes itself from sibling tools like get_credential by focusing on validity rather than retrieval.
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 the tool should be used when you need to check credential validity, but it does not explicitly state when to use it versus alternatives, nor does it provide exclusion criteria. The intended use case is inferable but not clearly articulated.
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=false, destructiveHint=false, and idempotentHint=false, so the description doesn't need to repeat those. It adds the useful context that the variable is global and accessible via $vars.key, but it does not disclose behavior such as what happens if the key already exists or any permission requirements. Since annotations cover the safety profile, the description adds moderate value, warranting a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The opening sentence is concise and clear, but the Args section largely duplicates the input schema descriptions. It adds bulk without new information. The structure is organized but not fully efficient, as every sentence should earn its place. A score of 3 reflects this 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 simplicity (3 params, no output schema, no nested objects), the description adequately covers the purpose and usage context. It explains the global scope and referencing syntax, which is helpful. However, it does not address duplicate key behavior or error conditions, which would be relevant for a create operation. This minor gap prevents a 5, but it remains fairly complete for the complexity level.
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 schema already provides descriptions for all parameters. The description's Args section repeats the same information (e.g., 'key: Variable key/name') with the addition of the default for 'type.' This adds no new meaning beyond the schema, so the baseline of 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 the tool's function: 'Create a new global workflow variable accessible in all workflows via $vars.key.' This uses a specific verb (create) and resource (global workflow variable), and it distinguishes itself from sibling tools like n8n_update_variable and n8n_list_variables by explicitly focusing on 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 gives clear context about where the variable will be accessible (all workflows via $vars.key), which implies the use case. However, it does not explicitly mention when not to use it or point to alternatives like n8n_update_variable for existing variables. This is a minor gap, so it earns a 4 rather than a 5.
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 destructiveHint: true and readOnlyHint: false, so the description's 'Permanently delete' reinforces but does not significantly extend this. It adds the detail 'and its data' to clarify the scope of deletion, which is useful context beyond the annotation. However, it does not mention irreversibility, permissions, or error behavior, so the extra disclosure is limited.
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 exceptionally concise: one sentence stating the action and an Args list that repeats the schema field. Every element earns its place, and the key information is front-loaded in the first sentence.
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 single-parameter delete tool with strong annotations (destructiveHint: true) and no output schema, the description provides the essential purpose and scope. It could mention that deletion is irreversible, but the word 'permanently' already covers that. No major gaps for the tool's simplicity.
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 already provides complete coverage: the 'id' parameter has a description ('Execution ID to delete') that matches the description's Args section exactly. Since schema coverage is 100%, the description adds no new semantic meaning, resulting in a baseline score of 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 the tool's function: 'Permanently delete a specific execution and its data.' It uses a specific verb ('delete') and resource ('execution'), and the qualifier 'permanently' distinguishes it from non-destructive execution tools like retry or stop. The name and title align, making the purpose unmistakable.
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 through the verb 'delete' and the explicit mention of a specific execution, but it does not provide explicit guidance on when to use this tool versus alternatives (e.g., stop_execution for non-destructive actions). No exclusions or alternative recommendations are given, making it a minimal viable guideline.
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?
Annotations already indicate this is not read-only (readOnlyHint=false) and not idempotent. The description adds no extra behavioral context such as side effects, network requirements, or permissions. It simply restates the install action without discussing reversibility or impact on the n8n instance.
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: a clear one-line purpose and a compact args list. Every word earns its place, with no filler or 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?
For a simple install tool with two well-documented parameters and no output schema, the description is largely sufficient. It could mention that the installed package becomes visible via list_community_packages, but this is not essential for invoking the tool correctly.
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 the baseline is 3. The description adds value by providing a concrete example ('n8n-nodes-evolution-api') and clarifying the version default ('latest'), which helps the agent format arguments correctly.
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 'Install' and identifies the resource as 'a community node package from npm', clearly distinguishing from sibling tools like list_community_packages and uninstall_community_package. The title reinforces the action, but the description adds the npm source.
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 when you need to install a community node package, but it does not explicitly state when to use this tool over alternatives or mention prerequisites (e.g., n8n instance access). The context is clear but lacks explicit exclusions or alternative references.
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 disclose that the tool is non-read-only, non-idempotent, open-world, and non-destructive. The description adds the constraint that the execution must be 'running,' but it does not explain what happens after stopping (e.g., status change, reversibility, or side effects). With annotations covering the safety profile, the description provides moderate additional context but lacks behavioral nuance.
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 short and front-loaded: a single purpose sentence followed by a one-item Args list. Each word earns its place, and the structure is clear and efficient for such a simple tool. The Args section is redundant with the schema but not excessively verbose, maintaining high conciseness.
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?
Despite lacking an output schema and not describing return values, the tool's simplicity (one parameter and clear intent) makes the context adequate. Annotations cover the mutation and non-destructive nature, and the description specifies the applicable execution state. The only minor gap is the lack of detail on post-stop behavior, but this is not critical for a straightforward stop action.
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% for the single parameter 'id,' and the description's 'Args - id (string): Running execution ID to stop' completely mirrors the schema description. The description adds no new meaning or detail beyond what the schema already provides, so the baseline score of 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 the action: 'Stop a currently running execution.' The verb 'Stop' with resource 'execution' is specific and unambiguous. It distinguishes itself from sibling tools like n8n_delete_execution and n8n_retry_execution by targeting a running execution rather than deleting or retrying it.
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 implicit context by specifying 'currently running execution,' suggesting it should be used only for active executions. However, it does not explicitly mention when not to use it or compare with alternative operations like deletion or retry. There is no clear exclusion or alternative phrasing that would guide an agent in choosing this over similar tools.
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 explicitly warns that 'Workflows using its nodes will break,' which adds specific behavioral context beyond the destructiveHint annotation. This helps agents understand the impact. However, it doesn't disclose other aspects like reversibility or confirmation, but annotations already cover the destructive nature.
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 brief and front-loaded with the purpose, then a warning, then parameter list. Every sentence adds value and there is no fluff.
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 one-parameter destructive tool, the description covers the purpose, the critical warning, and the parameter. It could be enhanced with a note about verifying the package name via listing, but overall it's complete enough given the schema and annotations.
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 description repeats the schema's parameter description almost verbatim ('npm package name to uninstall'), so it adds no new semantic information. Since schema coverage is 100%, a score of 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 the tool uninstalls a community node package, using the specific verb 'Uninstall' and resource 'community node package.' This distinguishes it from sibling tools like install and list.
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, nor any exclusions or recommendations. It only states the action and its immediate consequence, but does not mention that users should verify workflows or use listing tools first.
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 adds a critical behavioral consequence: 'Workflows referencing it will get undefined.' This goes beyond the annotations (which already flag destructiveHint) and provides useful context about the impact of deletion. It could mention permissions or irreversibility, but the added side-effect note is valuable.
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 very short and front-loaded with the primary action and effect. The 'Args' section duplicates schema information but is not verbose; the overall structure is efficient and easy to parse.
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 one-parameter delete tool with annotations indicating destructiveness, the description is sufficiently complete. It explains the key side effect and does not need to elaborate on return values given the simplicity and the presence of annotations. However, it does not explicitly state what the response will be, which is a minor gap.
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 repeats the same information as the schema ('id (string): Variable ID to delete') without adding additional meaning. The schema already fully documents the parameter, so the description contributes no extra semantic 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 uses a specific verb 'Delete' with a clear resource 'workflow variable', and the resource type distinguishes it from sibling delete tools like n8n_delete_workflow or n8n_delete_credential. The purpose is immediately clear 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to remove a workflow variable, but it does not explicitly state when to prefer it over alternatives like update or create, nor does it mention any exclusions or prerequisites. Usage context is implied rather than clearly contrasted with sibling tools.
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 the annotations by explicitly stating that secret data is NOT returned, which is a key behavioral restriction not evident from readOnlyHint or idempotentHint. It also specifies 'metadata', clarifying the return type as non-sensitive information. The annotations already cover safety, so this added context earns a 4.
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 short and front-loaded with the main action and the critical secret-data warning. The Args block is redundant with the schema, adding minor noise, but overall it remains efficient and skimmable.
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 get-by-ID tool, the description plus annotations provide sufficient context: read-only, idempotent, non-destructive, and returns metadata rather than secrets. It lacks detail on the exact metadata fields or possible errors, but given the schema and minimal complexity, this is acceptable.
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 only parameter 'id' is fully described in the schema with the same explanation ('Credential ID'). The description's Args section repeats the schema without adding new meaning (e.g., format, source, or validation). With 100% schema coverage, the description adds no extra parameter semantics.
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 a specific action ('Retrieve credential metadata by ID') and the resource. The 'Secret data is NOT returned' caveat further distinguishes it from other credential-related tools like n8n_get_credential_schema or n8n_create_credential.
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 when you need credential metadata by ID and notes that secret data is not available. However, it does not explicitly name alternatives (e.g., n8n_list_credentials for listing, n8n_get_credential_schema for schema) or provide exclusion criteria beyond the secret warning.
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=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, non-destructive read. The description adds minor behavioral context (e.g., 'including output data' and response format options) but does not disclose additional traits like error behavior or data volume. With annotations covering safety, this is adequate.
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 compact, with a clear first sentence stating the purpose. The Args list is somewhat redundant with the schema but not excessively verbose. It is well-structured and front-loaded, though it could be tightened by omitting the parameter list.
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 get-by-ID tool with safe annotations and no output schema, the description covers the essential information: it retrieves details including output data, and supports markdown/json formatting. It does not detail return fields, but given the tool's simplicity and the presence of response_format, the description is sufficiently 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 description coverage is 67%, and the description's Args list largely duplicates the schema's property descriptions. For response_format, the description mentions the enum values, which the schema already provides. No additional semantic meaning is added beyond the schema, so the baseline of 3 applies.
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 full details of a specific execution by ID, which is a specific verb+resource+scope. It distinguishes itself from sibling tools like n8n_list_executions (list vs. get), n8n_delete_execution, and n8n_retry_execution.
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: use when you need full details of a specific execution by ID. It does not explicitly mention alternatives or when-not-to-use, but the purpose is clear enough for an agent to infer when to invoke it. No misleading guidance is present.
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, openWorldHint, idempotentHint, and destructiveHint=false, covering safety. The description adds pagination behavior via cursor, but does not elaborate on return format or potential edge cases, which is acceptable given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a one-sentence purpose followed by a clear parameter list. Every part is necessary and no words are wasted.
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 list operation with no output schema, the description adequately covers purpose and parameters. The pagination mechanism is explained via the cursor parameter, and the annotations cover safety. It lacks details about returns but this is not critical given the absence of an output schema.
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 description adds semantic meaning to both parameters: limit is explained as 'Max results (1-250, default 20)' and cursor as 'Pagination cursor', providing conceptual context beyond the raw schema. This helps the agent understand the pagination model.
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 ('List all projects') and the resource ('n8n instance'), making it specific and unambiguous. It distinguishes itself from sibling tools like n8n_list_workflows and n8n_list_executions by naming the resource explicitly.
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 tool's purpose strongly implies when to use it: whenever a list of projects is needed. However, it does not explicitly provide alternatives or exclusions, leaving the agent to infer usage from the name and 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 a non-read-only, idempotent operation. The description complements this by disclosing that existing tags are replaced and that an empty array removes all tags, which is useful behavioral context. 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 extremely compact: one clear action sentence, one edge-case sentence, and a simple Args list. Every sentence earns its place, and there is no filler or redundant phrase beyond the schema copy in Args.
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 two-parameter mutation tool with no output schema and clear annotations, the description provides the essential behavioral details and parameter definitions. It does not mention return values or error conditions, but these are not critical for this operation's adequacy.
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%, with both parameters already described clearly in the input schema. The Args section in the description essentially repeats that information without adding new semantic detail, so the schema carries the load and the description adds no extra 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?
Description opens with 'Replace all tags on a workflow' — a specific verb and resource, immediately distinguishing it from read-only siblings like n8n_get_workflow_tags. The action is clear and unambiguous, with an explicit edge case (empty array removes all tags).
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: use when you want to replace or remove all tags on a workflow. However, it does not explicitly compare with alternatives or state when not to use this tool, leaving the guidance at the level of implication rather than explicit direction.
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=false, idempotentHint=true, and destructiveHint=false, providing a clear safety profile. The description adds only the basic behavior of restoring, without detailing edge cases or prerequisites, so it meets the baseline but does not add substantial context.
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 sentence plus an args list, with no wasted words. It is appropriately sized for a one-parameter tool and does not repeat schema information unnecessarily.
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 tool with one clearly defined parameter and annotations covering idempotency and destructiveness, the description is mostly complete. It lacks any note on error behavior or prerequisites, but these are not critical for the typical use case.
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 the id parameter description matching the tool description exactly. The description adds no additional meaning beyond what the schema already provides, so a baseline score of 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 uses the specific verb 'Restore' and clearly identifies the resource as 'an archived workflow', stating the outcome ('back to normal state'). This distinguishes it from siblings like n8n_archive_workflow, which performs the opposite action.
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 when to use the tool: when an archived workflow needs to be restored. It does not explicitly mention exclusions or alternatives, but the sibling set includes n8n_archive_workflow, making the purpose and appropriate usage obvious.
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 indicate readOnly=false and idempotentHint=true; the description adds the behavioral consequence 'runs automatically on triggers/schedules.' However, it doesn't disclose potential side effects like validation errors or scheduling behavior beyond the basics, so it provides moderate added 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 front-loaded with a clear, concise first sentence and a minimal args list. Every word adds value; no wasted text.
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 single-parameter, no-output-schema tool with adequate annotations, this description is fully sufficient. It states the action, the effect, and the required argument, leaving no significant 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 description coverage is 100% and the description merely repeats the parameter description ('Workflow ID to activate') without adding new semantics. Since the schema already fully documents the only parameter, the baseline of 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 uses a specific verb ('Activate') and resource ('workflow') and clarifies the effect: 'runs automatically on triggers/schedules.' This clearly distinguishes it from siblings like n8n_deactivate_workflow or n8n_update_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 gives clear context: activation is for publishing a workflow so it runs automatically. It does not explicitly name alternatives or exclusion criteria, but the use case is unambiguous and implicitly contrasts with deactivating.
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 readOnlyHint=false and destructiveHint=false, so the 'soft-delete' wording adds clarity but is not entirely new. The description adds valuable behavioral context by mentioning restore capability, which goes beyond the structured annotations.
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 front-loaded with the core statement and includes a useful restoration note. The Args block duplicates the schema, which is slightly redundant but not bloated; overall it is concise and well-structured.
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 one-parameter mutation tool with no output schema, the description covers essential aspects: what it does, that it is non-destructive, and that it is reversible. It is complete enough for the agent to select and invoke correctly, though it omits details like success response, which are not required for this simple 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?
Schema description coverage is 100%, and the description's Args section simply repeats the schema field (id: 'Workflow ID to archive') without adding any new semantic details. Baseline 3 is appropriate when the schema fully documents parameters.
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 function with a specific verb and resource: "Soft-delete a workflow by archiving it." It distinguishes from siblings by explicitly mentioning n8n_unarchive_workflow and labeling itself as a 'soft-delete,' contrasting with the likely hard-delete n8n_delete_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 gives clear usage context by noting the workflow can be restored with n8n_unarchive_workflow, implying it should be used when reversible deletion is desired. However, it does not explicitly state when not to use it or contrast it with n8n_delete_workflow for permanent deletion.
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 signal a non-read-only, non-idempotent mutation. The description adds useful behavioral context by noting that the data object is 'specific to the credential type' and that projectId is optional. It also points to a necessary precursor step (getting the schema), which goes beyond the structured annotations.
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 compact: a two-sentence intro followed by a concise parameter list. While the parameter list partially duplicates schema descriptions, it is still structured and scannable. It doesn't waste words, and the prerequisite instruction 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?
For a credential-creation tool with 4 parameters and nested data, the description covers the key aspects: purpose, prerequisite (get schema), parameter semantics, and optional project assignment. No output schema exists, but the return value is not critical here. It could mention permissions or error cases, but the guidance is sufficient for an agent to invoke it correctly.
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 parameter descriptions for all four fields. The description's Args section mirrors the schema but adds minimal extra meaning: the note that data is 'specific to the credential type' and the '(string?)' marker for optionality. These are modest additions, so the baseline of 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 begins with 'Create a new credential' — a specific verb and resource — and clearly distinguishes this from sibling tools like n8n_update_credential and n8n_delete_credential. It also references n8n_get_credential_schema as a prerequisite, which reinforces the tool's 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?
The description explicitly instructs the agent to use n8n_get_credential_schema first to determine required fields, which is strong contextual guidance. It doesn't explicitly state when not to use this tool, but the prerequisite and the clear 'create' action imply when to use it relative to update/delete/test siblings.
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=true and destructiveHint=false, establishing the safety profile. The description adds the purpose of determining required fields for credential creation, which is useful context but does not disclose additional behavioral traits or edge cases. 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 two sentences plus an argument list. The main action is front-loaded, and the argument listing is minimal and clear. No unnecessary details.
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 simple read-only tool with one parameter and no output schema, the description fully covers what the tool does, when to use it, and what it returns (schema/field definitions). The annotations cover safety, making the description 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% and the description repeats the parameter and adds another example ('telegramApi'). It doesn't add meaning beyond the schema's own description. Baseline of 3 is appropriate given that the schema fully documents the parameter.
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 function: 'Get the schema/field definitions for a credential type.' This is a specific verb ('Get') and resource ('schema/field definitions for a credential type'), distinguishing it from sibling tools like n8n_get_credential which operate on specific credential instances.
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 direct usage context: 'Use this to know which fields are required when creating credentials.' This tells the agent when to invoke this tool. It doesn't explicitly mention alternatives, but for a schema lookup tool the context 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?
Beyond the readOnlyHint and destructiveHint annotations, the description adds crucial behavioral details: secrets are not returned, only metadata, and pagination is supported. It also mentions the role requirement. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct and well-structured with a title sentence, role/behavior note, and an Args list. The Args section is slightly redundant with the schema but remains readable and compact.
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?
Despite lacking an output schema, the description covers the essential context: credential listing is metadata-only, requires admin, supports filtering and pagination. It does not describe the return structure but that is not critical for this simple list 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?
Schema coverage is 67% (name and cursor have descriptions, limit has constraints). The description repeats the parameter list without adding new meaning beyond the schema, except for clarifying limit range and defaults which are already in the schema. Baseline 3 is appropriate because 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 'List all credentials' with the specific scope of metadata-only results, distinguishing it from sibling tools like n8n_get_credential (single credential) and n8n_create_credential (write operation). The title and name reinforce the resource and action.
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 clear context for usage by requiring owner/admin role and explicitly warning that secrets are not returned. This indirectly guides the agent away from using this tool when secrets are needed. It does not explicitly name alternatives but gives sufficient contextual guidance.
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 readOnlyHint=false and destructiveHint=false. The description adds valuable context that 'data' is 'merged with existing', clarifying that the update is not a full replacement. This exceeds what annotations alone convey, though it does not cover auth or side effects.
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 and front-loaded with the main action. However, the 'Args' section largely duplicates the input schema's parameter descriptions, adding redundancy. Still, the layout is clear and appropriate length.
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 simplicity (3 parameters, no output schema), the description covers the essential behavior and the merge semantics. It is sufficiently complete for an AI to understand what the tool does and when to use it, though it omits return value details.
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 description coverage is 100%, so baseline is 3. The description adds the key nuance that the 'data' parameter is 'merged with existing', which is not fully captured by the schema's 'Updated credential data/secrets'. This provides semantic value 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 action: 'Update an existing credential's name or data.' This uses a specific verb ('Update') and resource ('credential'), and distinguishes it from sibling tools like n8n_create_credential and n8n_delete_credential.
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 context (updating an existing credential) but provides no explicit alternatives or exclusions. It does not reference sibling tools like create or delete, leaving the when/why partly inferred from the tool name and description.
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?
Description adds meaningful behavioral context beyond annotations: full definition replacement and automatic republication for active workflows. No contradiction with annotations such as idempotentHint=true or destructiveHint=false.
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 key behavioral points are front-loaded and concise, but the Args list duplicates schema information. Still lean and readable, not bloated.
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 mutation tool with good annotations and full schema coverage, the description covers the essential behavior (full replacement, auto-republish). It does not mention return values or error cases, but those are not required given the schema and no output 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?
Schema description coverage is 100%, and the description largely repeats the parameter names and descriptions already in the schema. It adds minimal new semantic value, so the baseline of 3 applies.
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 updates an existing workflow and replaces the full workflow definition. This is distinct from sibling tools like n8n_create_workflow, n8n_delete_workflow, and n8n_activate_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?
Provides clear context for updating an existing workflow and notes automatic republication if active. Does not explicitly mention alternative tools or exclude them, but the update/creation distinction is implicit and 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 classify the tool as a non-read-only, non-idempotent mutation. The description adds context by documenting the 'active' parameter's default behavior and stating the return value (created workflow with ID). It does not contradict annotations and provides additional useful behavioral details.
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 compact, well-organized with a labeled arg list, and includes a returns line. Every sentence is useful, 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?
For a 5-parameter tool with nested objects and no output schema, the description covers the essentials—inputs and return value. It doesn't detail the required format for n8n node definitions or connection maps, but given the schema and annotations, the description is sufficiently complete for correct 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?
Schema coverage is 100%, so the baseline is 3. The description repeats parameter names and basic types but adds little beyond the schema (e.g., marking settings as optional and restating the default for active). It does not explain the structure of nodes or connections, which would be more valuable.
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 states 'Create a new workflow in n8n' with a clear verb and resource. It distinguishes from sibling tools like update/delete/activate workflows by specifying the creation intent. The arg list further clarifies the operation.
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 makes it clear this is for creating workflows, and the context is unambiguous. It does not explicitly list when not to use it or point to alternatives, but the purpose is self-evident, giving clear context without exclusions.
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 non-destructive, idempotent behavior. The description adds meaningful context beyond those hints: deactivation stops automatic runs but keeps manual executions possible. This is valuable behavioral disclosure that helps the agent predict side effects.
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 minimal Args block. The purpose is front-loaded, and every sentence adds behavioral information without unnecessary 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?
For a single-parameter lifecycle tool, this description is nearly complete: it states the effect, the persistence of manual executions, and the mutation is covered by annotations. It does not mention how to obtain the workflow ID or what happens to currently running executions, but those are minor gaps for a simple 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?
Schema coverage is 100%: the only parameter 'id' is described in the schema as 'Workflow ID to deactivate.' The description merely repeats that information, adding no additional syntax, lookup guidance, or edge-case semantics, so it stays at the baseline 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 uses a specific verb ('Deactivate') targeting a clear resource ('a workflow') and defines the effect: 'stops running automatically.' It also adds a distinguishing nuance ('Manual executions are still possible') that separates it from destructive/archive operations.
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 makes the use case clear: use when you want to stop automatic execution while preserving the ability to run manually. It does not explicitly name alternatives like n8n_activate_workflow or n8n_delete_workflow, but the context is sufficient and no misleading guidance is present.
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 destructiveHint=true, but the description adds the concrete consequence that workflows will break, which is valuable beyond the annotation. The word 'Permanently' conveys irreversibility, supplementing the idempotentHint=false annotation with user-facing impact.
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 only two sentences plus a small Args block that mirrors the schema. It is front-loaded with the essential purpose and consequence, with no filler or redundant safety caveats.
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 single-parameter delete tool, the description adequately covers what the tool does, its permanence, and its main side effect (breaking workflows). Given the rich annotations (destructiveHint, idempotentHint) and lack of output schema, no additional return values or prerequisites are necessary for the agent to use it correctly.
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 covers the sole parameter 'id' with a description already ('Credential ID to delete'), and the description repeats this same information. Since schema coverage is 100%, the description adds no new parameter semantics, giving the baseline score of 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 the tool's function: 'Permanently delete a credential.' This is a specific verb-resource pair and distinguishes it from sibling delete tools (e.g., delete_workflow) by explicitly naming the target resource. The additional warning about workflows breaking adds context without ambiguity.
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 intentionally removing credentials and warns that 'Workflows using it will break,' which provides clear context for when to invoke it. However, it does not explicitly mention alternatives or exclusions (e.g., use update_credential to modify), so it lacks the explicit when-not guidance required for a 5.
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 the safety profile is covered. The description adds behavioral context about the return content (nodes, connections) and the response_format behavior ('default json for full detail'), which goes 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences plus a clear argument list. It is front-loaded with the main action and contains no filler, earning 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?
For a simple get-by-ID tool with rich annotations and full schema coverage, the description adequately explains the purpose and return content (nodes, connections). The lack of an output schema is compensated with 'full details', though error behavior is not mentioned.
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 baseline is 3. The description repeats the parameter information and adds a slight nuance about 'full detail' for JSON, but does not significantly enrich the schema's already-present 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 states 'Retrieve full details of a specific workflow by ID' with a clear verb and resource, and mentions 'including its nodes and connections', which distinguishes it from listing tools and other get 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?
The description implies use when you have a specific workflow ID and need full details, which is clear context. However, it does not explicitly mention alternatives such as n8n_list_workflows for finding IDs or other tools, so no exclusions are stated.
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=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the specific scope of 'installed community node packages' but does not disclose additional behavioral details like return format or pagination. This is adequate but not rich.
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 sentence that is direct and front-loaded with the verb 'List'. Every word contributes to the meaning, with no redundant or unnecessary information, making it an ideal concise description.
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 tool with no parameters, no output schema, and strong annotations, the description fully covers the necessary context. It clearly states the operation and scope, and nothing essential is missing for an agent to correctly select and invoke the 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?
The input schema has zero parameters, so there is no parameter semantics to explain. The baseline for zero-parameter tools is 4, and the description's phrase 'List all' is consistent with the lack of filters, requiring no additional parameter guidance.
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 'List' and clearly identifies the resource as 'all installed community node packages' in the n8n instance. This distinguishes it from sibling tools like n8n_install_community_package and other list tools, and matches the title exactly.
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: it lists installed community node packages, making it obvious when to use this tool. While it doesn't explicitly mention alternatives or exclusions, the clarity of the scope makes the usage unambiguous for a simple read-only operation.
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?
Beyond the annotations (readOnly, idempotent, non-destructive), the description adds behavioral context about pagination via the cursor parameter and limit default, as well as clarifying that variables are global across workflows. This is useful context not present in the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the purpose, followed by a compact parameter list. Every sentence earns its place with no redundancy or fluff.
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 list tool with two optional parameters and no output schema, the description covers purpose, parameter semantics, and pagination behavior. It does not describe the return structure, but that is somewhat self-evident for a list operation. Overall, it is nearly complete.
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?
The schema has no descriptions, but the description compensates fully by documenting limit (range and default) and cursor as a pagination cursor. This adds meaning beyond the raw type and constraints 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 lists all workflow variables, defining them as global key-value pairs available in all workflows. This uses a specific verb and resource, and distinguishes it from sibling tools like n8n_list_workflows and n8n_create_variable.
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 usage context is implied: you use this to list variables. However, it does not explicitly mention alternatives or when not to use it (e.g., 'use n8n_create_variable to add variables'). The readOnlyHint annotation partially covers this, but the description itself provides no direct guidance.
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, idempotentHint=true, and destructiveHint=false. The description adds behavioral details beyond this: pagination via cursor, limit range (1-250), configurable output format (markdown/json), and the specific return fields (id, name, active status, node count, dates). This context helps the agent understand what to expect.
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 and well-structured: a single-sentence summary, a formatted Args list, and a Returns line. There is no redundant fluff, and each line provides necessary information. The front-loaded summary makes the tool's purpose immediately clear.
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?
Despite lacking an output schema, the description explicitly lists the returned fields (id, name, active status, node count, dates). All 7 optional parameters are documented with types and constraints, and annotations cover safety. The description is complete for a read-only list tool, covering pagination, output format, and filtering options.
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%, meaning every parameter already has a description in the input schema. The description's Args section essentially replicates the schema's parameter descriptions verbatim (e.g., 'active' as 'Filter by active/inactive status', 'limit' as 'Max results per page (1-250, default 20)'). It adds no new meaning beyond the schema, so the baseline score of 3 applies.
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 begins with 'List workflows from the n8n instance with optional filtering', clearly specifying the action (list) and resource (workflows). This distinguishes it from sibling tools like n8n_get_workflow (single retrieval) and mutation tools (create/update/delete). The verb and resource are 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 implies usage: it is for listing workflows and supports optional filters (active, name, tags, projectId, pagination). It clearly indicates a list operation, which differentiates it from single-workflow retrieval (n8n_get_workflow). However, it does not explicitly name alternatives or state when not to use it, so it lacks explicit exclusion guidance.
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, idempotentHint=true, and destructiveHint=false, so the safety profile is well-covered. The description adds useful behavioral details: includeData increases response size, default output format is markdown, and pagination via cursor. It does not discuss rate limits or data retention, but the annotations plus these details provide solid 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 appropriately sized: a concise opening line followed by a well-organized Args list. Every element earns its place, with no redundancy. The front-loaded purpose statement and clean parameter formatting make it easy to scan.
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 has no output schema, the description does not detail return values, but this is acceptable for a list operation. It explains filtering, pagination, and output format. However, it could mention that response includes metadata like total count or nextCursor, but this is a minor gap. Overall, the description is complete for a listing tool with good 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 description coverage is 67%, so the schema already documents most parameters. The description adds meaning beyond the schema by explaining that includeData 'increases response size', specifying default limit of 20 and max 250, and noting response_format defaults to markdown. This adds practical value, though cursor and workflowId are already well-defined 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 'List workflow executions with optional filtering' using a specific verb and resource. It distinguishes itself from sibling tools like n8n_get_execution (single execution) and n8n_list_workflows (workflows, not executions).
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 filtering options and pagination, but does not explicitly state when to use this tool versus alternatives like n8n_get_execution. Sibling tool names and the 'list' verb imply typical usage, but no explicit exclusions or alternative recommendations are given.
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 mark this as non-read-only, but the description adds useful behavior details: it creates a new execution and clarifies that the default 'loadWorkflowData=false' uses original execution data. 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 two concise sentences plus a compact arg list. Every sentence adds value, and the most important information (retry, from point of failure) 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 2-parameter tool with no output schema, the description covers purpose, parameter behavior, and default semantics. It does not explain return values or errors, but those are less critical given the simple scope and existing 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 covers both parameters at 100%, but the description adds meaning for 'loadWorkflowData' by explaining the default's effect ('uses original execution data'), which goes beyond the schema's terser phrasing. This lifts it above the baseline.
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 'Retry' with the resource 'execution' and adds specificity with 'Creates a new execution from the point of failure'. This distinguishes it from sibling tools like list, get, stop, and delete executions.
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 context: use it for a failed execution. It does not explicitly mention alternatives or exclusions, but the 'failed execution' qualifier provides a clear trigger. Since it lacks any when-not guidance, it falls short of a 5.
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, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds context beyond these by noting it uses the current API key and shows accessible endpoints/scopes, which is helpful for understanding its scope and permission implications. It 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?
The description is two concise sentences, front-loaded with the primary action and followed by a practical use case. Every word earns its place, with no redundancy or fluff.
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 simple zero-parameter discovery tool with comprehensive annotations, the description is complete: it states what is returned (capability map), how it is scoped (current API key), and when it is useful (debugging permissions). No output schema exists, but the description adequately conveys the expected result.
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 zero parameters, and schema coverage is 100%, so the baseline is 4. The description correctly implies no input is needed by focusing solely on the output capability map, and no parameter documentation is required.
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 a specific verb ('Get') and resource ('capability map for the current API key'), clearly distinguishing it from the sibling operational tools like n8n_list_workflows or n8n_delete_execution. It unambiguously states what the tool does.
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 states a use case: 'Useful for debugging permission issues.' This provides clear context for when to apply it, though it does not mention alternatives or exclusions. Since no sibling tool provides similar discovery functionality, explicit alternatives are not necessary.
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, idempotentHint, and destructiveHint, so the safety profile is known. The description goes beyond this by adding the owner role requirement, which is critical for authorization. It does not describe return format or pagination details, but with annotations covering side effects, this is adequate.
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 a clear one-sentence purpose and a structured argument list. Every line provides useful information 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 simplicity (2 optional params), good annotations, and complete parameter semantics, the description is nearly complete. It lacks an explicit mention of the return value structure, but for a list operation with a cursor this is reasonably inferable. The owner role prerequisite adds important context.
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?
The schema has no property descriptions (0% coverage), so the description fully compensates by explaining 'limit' as 'Max results (1-250, default 20)' and 'cursor' as 'Pagination cursor'. This adds clear meaning to both parameters beyond the raw schema constraints.
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 'List all users in the n8n instance' with a specific verb and resource, and the scope is well-defined. This distinguishes it from sibling tools like n8n_list_workflows by naming the unique resource (users).
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 prerequisite ('Requires owner role'), which is important context for when the tool can be used. It does not mention alternatives or exclusions, but the context is strong enough for an agent to know when to invoke this tool versus others.
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 destructiveHint=true, but the description adds critical context by stating 'This action is irreversible' and 'permanently delete', reinforcing the destructive aftermath. It also mentions the soft-delete alternative, which is valuable behavioral guidance beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences and a minimal Args list. Every sentence adds value: the first defines the action and irreversibility, the second provides a safer alternative. No fluff or redundancy.
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 delete tool with a single required parameter, the description is complete. It covers the action, permanence, alternative, and the required argument. The lack of an output schema is acceptable for a delete operation, so no additional return-value explanation 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 input schema already provides full coverage for the single parameter (id) with a description 'Workflow ID to permanently delete'. The description's Args section merely repeats this information without adding new semantics, so the baseline of 3 applies due to 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 uses a specific verb 'permanently delete' and clearly identifies the resource ('a workflow by ID'). It also distinguishes itself from the sibling n8n_archive_workflow by noting the irreversible nature, which directly addresses the soft-delete alternative.
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 by recommending n8n_archive_workflow for soft-delete instead, making the decision boundary between permanent deletion and archiving clear. This is a direct alternative and usage hint.
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:

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

Score Badge

Copy to your README.md:

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

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

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