n8n MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose targeting specific resources and actions, with no ambiguity. The naming convention makes it easy to distinguish between operations on workflows, users, projects, tags, credentials, variables, and executions.
Naming Consistency5/5
All tools follow a perfect 'n8n_verb_noun' pattern with consistent snake_case throughout. The structure is highly predictable, making it easy to understand what each tool does at a glance.
Tool Count2/5
With 42 tools, this is an extremely large set that feels heavy and overwhelming for an MCP server. While n8n is a complex platform, this many tools will likely cause cognitive load and selection challenges for agents.
Completeness5/5
The tool surface provides comprehensive CRUD/lifecycle coverage for all major n8n entities (workflows, users, projects, tags, credentials, variables, executions). It includes advanced operations like audit generation, health checks, source control integration, and transfer operations, leaving no obvious gaps.
Average 2.6/5 across 42 of 42 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Delete' implies destruction, the description lacks critical safety context: whether the operation is reversible, what happens to the user's workflows/credentials/executions, and required permissions. This is inadequate for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At two words, this is under-specification rather than effective conciseness. The single sentence provides no structural organization of information (e.g., leading with the destructive warning, following with scope).
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?
For a destructive operation with severe consequences (permanent user deletion), the description is dangerously incomplete. No output schema exists, yet the description doesn't compensate by explaining the success/failure behavior or side effects on related resources.
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 fully described as 'User ID to delete'. The description adds no semantic value beyond the schema (it doesn't clarify the ID format, where to obtain it, or validation rules), warranting the baseline score for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a user' is a tautology that restates the tool name (n8n_delete_user) without adding specificity. It fails to distinguish from the sibling tool n8n_remove_user_from_project, leaving ambiguity about whether this removes a user's platform account or just their project association.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this versus alternatives like n8n_remove_user_from_project or n8n_update_user_role. No prerequisites are mentioned (e.g., whether the user must be deactivated first, or if owned workflows transfer or delete).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'delete' implies destruction, the description fails to clarify if deletion is permanent, whether it affects associated workflow data or logs, or if there are rate limits/permissions required for this destructive operation.
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 description is extremely brief (3 words), which prevents verbosity, but it fails to earn its place by providing actionable intelligence. The front-loading is technically present but content-deficient for a destructive operation requiring safety context.
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?
For a destructive operation with no annotations and no output schema, the description is inadequate. It lacks critical safety warnings about permanence, lacks clarification on whether deleted executions can be retrieved, and omits any mention of side effects or required execution states (e.g., finished vs running).
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 'id' parameter already documented as 'Execution ID to delete' in the schema. The description adds no additional semantic value regarding parameter format, validation rules, or constraints beyond what the schema already provides, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete an execution' is essentially a tautology that restates the tool name (n8n_delete_execution) without adding specificity. While it indicates a deletion operation, it fails to distinguish from sibling execution tools like n8n_retry_execution or clarify what type of execution (workflow execution) is being targeted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives like n8n_retry_execution or n8n_get_execution. No warnings about prerequisites (e.g., execution state requirements) or irreversible consequences are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers almost nothing. It does not specify side effects (e.g., default permissions set), idempotency behavior on name conflicts, or what fields are initialized beyond the name parameter.
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 description is extremely brief at four words, avoiding verbosity, but it is under-specified rather than efficiently concise. The single sentence does not earn its place effectively given the lack of substance, though it is grammatically complete.
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?
For a creation tool with no output schema and no annotations, the description is insufficient. It fails to explain what constitutes a project in n8n, the relationship between projects and users (given the sibling 'n8n_add_user_to_project'), or the implications of the optional 'type' parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('Project name' and 'Project type'), the schema adequately documents both parameters. The description adds no additional semantic context (e.g., valid values for 'type', naming constraints), meeting the baseline expectation when structured documentation is already complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new project' is tautological, restating the action and resource already present in the tool name 'n8n_create_project' with only the addition of 'new'. It fails to distinguish what an n8n project specifically is or how it differs from workflows, credentials, or other sibling resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'n8n_update_project' for modifications or prerequisites such as user permissions. There are no exclusions or contextual conditions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but discloses minimal behavioral details. It states 'Create' implying mutation, but lacks information about what gets returned (workflow ID? full object?), validation rules for unique names, or potential side effects like automatic tagging or default settings assignment.
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?
At three words, the description is technically concise, but it represents under-specification rather than efficient communication. For a tool with 5 parameters including complex nested objects (nodes, connections), the length is inappropriately brief—every word earns its place only because there are so few of them.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested objects for nodes/connections, boolean activation state) and lack of output schema, the description fails to provide sufficient context. It doesn't hint at the n8n-specific domain (automation workflows), expected node structures, or what distinguishes a successful creation from a validation error.
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%, establishing a baseline of 3. However, the description adds no semantic value beyond the schema—it doesn't explain that 'nodes' refers to n8n automation steps, what structure 'connections' expects (likely a mapping of node IDs), or what valid 'settings' properties are available.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new workflow' is tautological—it simply restates the tool name 'n8n_create_workflow' without adding specificity. While it identifies the resource (workflow) and action (create), it fails to distinguish from siblings like 'n8n_update_workflow' or clarify scope within the n8n automation platform.
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 provided on when to use this versus 'n8n_update_workflow' (for existing workflows) or prerequisites like requiring a project to exist first. No mention of whether the workflow can be created as active immediately or if 'n8n_activate_workflow' must be called separately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers almost nothing. It does not explain what deactivation means (prevents triggers? pauses queue? preserves data?), whether the operation is reversible, or what success/failure looks like for a mutation operation.
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?
At three words, the description is brief, but this borders on under-specification rather than purposeful conciseness. No structural issues, but every sentence (singular) fails to earn its place by providing insufficient information for tool selection.
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?
For a mutation tool with no output schema and no annotations, the description is inadequate. It omits critical context: reversibility, impact on active executions, return value format, and differentiation from n8n_delete_workflow. Agents need this context to use the tool safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for its single parameter 'id'. The description adds no semantic value beyond the schema's 'Workflow ID to deactivate' text. With complete schema coverage, the baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Deactivate a workflow' is a near-tautology that restates the tool name with minimal elaboration. While it identifies the resource (workflow) and action (deactivate), it fails to distinguish from siblings like n8n_activate_workflow or clarify scope (does it stop running executions or just prevent new ones?).
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 usage guidance provided. The description does not indicate when to use this versus n8n_activate_workflow (the inverse operation), nor does it mention prerequisites (e.g., workflow must be active) or side effects that would guide an agent's selection logic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Delete' implies destruction, the description omits critical safety details: whether deletion is permanent, impact on workflows using this credential, or required permissions. For a destructive operation, this is a significant gap.
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 description is appropriately brief at three words, but suffers from under-specification rather than elegant conciseness. It front-loads the action but wastes the opportunity to add safety warnings or usage constraints that would justify its existence beyond the tool name.
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?
As a destructive operation with no output schema and no annotations, the description should disclose return values (success/failure indicators) and side effects. The minimal description fails to provide sufficient safety context for an irreversible deletion operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage (the 'id' parameter is fully documented as 'Credential ID to delete'), the baseline score is 3. The description text itself adds no parameter-specific semantics beyond what the schema already provides, but does not need to compensate given complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a credential' is essentially a tautology that restates the tool name (n8n_delete_credential converted to sentence case). While the verb and resource are clear, it fails to distinguish from sibling deletion tools (delete_workflow, delete_user, etc.) or explain what constitutes a credential in the n8n context.
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 provided on when to use this tool versus alternatives like transfer_credential, nor are prerequisites mentioned (e.g., verifying the credential is not in use by workflows). The description lacks any when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to state whether deletion is permanent or reversible, whether it cascades to contained resources (workflows, credentials), or what permissions are required. Only the basic action type is implied by the verb.
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 description is extremely brief (3 words) with no structural organization possible at this length. While there is no wasted text, the extreme under-specification means it fails to earn a higher score - conciseness requires informative density, not just brevity.
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?
For a destructive single-parameter tool with no output schema and no annotations, the description should explain irreversibility, success/failure behavior, and side effects. It provides none of these, making it dangerously incomplete for an agent deciding whether to invoke a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('Project ID to delete'), the baseline score applies. The description adds no semantic context about the ID format, how to obtain it, or validation rules, but the schema adequately documents the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a project' is tautological - it simply restates the tool name (n8n_delete_project). While it identifies the verb and resource, it fails to distinguish from sibling delete operations (n8n_delete_workflow, n8n_delete_user, etc.) or specify what constitutes a 'project' in this context.
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 provided on when to use this tool versus alternatives, prerequisites (such as emptying the project first), or permission requirements. For a destructive operation, the absence of usage constraints or warnings is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to clarify whether deletion is permanent or reversible, what happens to associated executions/tags, or required permissions. The word 'Delete' implies destruction but lacks critical safety context for a destructive operation.
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 description is extremely brief (3 words) and front-loaded, but for a destructive operation lacks necessary detail. It suffers from under-specification rather than efficient conciseness—too minimal to safely guide agent invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a destructive operation with no annotations and no output schema, the description should disclose behavioral risks, cascades, or return status. The current description is insufficiently complete for safe agent operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage ('Workflow ID to delete'), the schema adequately documents the single parameter. The description adds no additional semantic value regarding the parameter format or constraints, but baseline 3 is appropriate given the complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a workflow' is tautological, simply restating the tool name without the 'n8n_' prefix. While it identifies the verb and resource, it fails to distinguish this from sibling deletion tools (n8n_delete_credential, n8n_delete_execution, etc.) or specify scope.
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 provided on when to use this tool versus alternatives, prerequisites (e.g., workflow must exist), or warnings about dependencies. The description lacks any usage constraints or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to indicate whether this is read-only, what the return format looks like, or any permission requirements for accessing workflow tags.
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 description is appropriately brief (4 words) and front-loaded, earning points for efficiency. However, it is under-specified rather than elegantly concise—it lacks the informational density expected of a high-scoring description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of numerous sibling tag and workflow tools (n8n_get_tag, n8n_list_tags, n8n_update_workflow_tags), the description is incomplete. It fails to clarify the relationship between this tool and others in the suite, which is critical for correct agent 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% (the 'id' parameter is well-described as 'Workflow ID'), establishing a baseline of 3. The description adds no additional context about the parameter (e.g., whether it's the workflow's UUID, internal ID, or name).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get tags for a workflow' is a tautology that restates the tool name (n8n_get_workflow_tags) in natural language. It does not specify what gets returned (array of tags? tag IDs?) or distinguish from siblings like n8n_get_tag, n8n_list_tags, or n8n_get_workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus alternatives such as n8n_get_tag (which likely retrieves a single tag by its ID) or n8n_update_workflow_tags. Does not indicate if this is used before/after other 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?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers nothing beyond the action verb. It omits pagination behavior (despite cursor parameter), filtering logic, or whether executions include full run data versus metadata.
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?
While the three-word description contains no fluff, it is under-informative rather than appropriately concise. It fails the 'every sentence earns its place' test by providing minimal value beyond the tool name itself.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four filterable parameters, zero annotations, no output schema, and a complex domain (workflow execution history), the description is inadequate. It should explain execution lifecycle context, filtering capabilities, or result set expectations.
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%, documenting all four parameters (limit, cursor, workflowId, status) including valid status values. The description adds no semantic context beyond the schema, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List workflow executions' is tautological—it merely converts the snake_case name to prose without adding specificity. It fails to distinguish from sibling n8n_get_execution (which retrieves a single execution) or clarify the listing scope.
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 like n8n_get_execution (for specific records) or n8n_retry_execution (for failed runs). No prerequisites or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so description carries full disclosure burden. It states 'Update' implying mutation but doesn't specify whether tags are renamed atomically, if changes cascade to existing workflow associations, or potential failure modes.
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?
Extremely terse at 3 words, but not bloated. Every word earns its place, though the extreme brevity fails to meet the informational needs for tool selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of n8n_update_workflow_tags and other tag siblings, the description lacks domain context needed to select the correct tool. No output schema exists, but even for a simple CRUD tool, the failure to differentiate tag entity updates from tag associations is a critical 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 has 100% description coverage ('Tag ID' and 'New tag name'), so the structured fields already carry the semantic load. Description adds no parameter guidance beyond what's in the schema, warranting baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description 'Update a tag' is a tautology that restates the tool name without adding specificity. It fails to distinguish from sibling n8n_update_workflow_tags (which updates tag associations on workflows, not the tag entity itself) or clarify what resource domain 'tag' refers to.
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?
Provides no guidance on when to use this versus n8n_create_tag, n8n_delete_tag, or n8n_update_workflow_tags. Does not mention prerequisites like tag existence or permission requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure burden. It fails to explain what activation entails (enabling execution triggers?), whether the operation is idempotent, what permissions are required, or side effects. Only the basic action is implied by the verb 'Activate'.
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?
Extremely brief at three words with no redundant phrases. However, the brevity borders on under-specification. The structure is efficient but lacks front-loaded value beyond the tool name itself.
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?
Despite being a single-parameter tool with complete schema coverage, the description is inadequate. It omits critical context: the prerequisite that a workflow must exist (created via n8n_create_workflow), what 'active' state means functionally, and how this relates to the sibling deactivate 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 has 100% description coverage ('Workflow ID to activate'), so the baseline is 3. The description adds no additional semantic information about parameters, acceptable formats, or where to obtain the ID, but the schema carries this adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Activate a workflow' is a tautology that restates the tool name (n8n_activate_workflow → 'Activate a workflow'). While the verb and resource are clear, it fails to distinguish from sibling tools like n8n_deactivate_workflow or explain what activation means in the n8n context.
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?
Description provides no guidance on when to use this tool versus alternatives. Specifically, it does not clarify the relationship with n8n_deactivate_workflow (the inverse operation) or when activation is appropriate versus other workflow 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?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails to mention side effects, idempotency behavior, required permissions, or error scenarios (e.g., duplicate email handling).
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?
Extremely concise at four words with no wasted text. However, the single sentence fails to earn its place by providing minimal value beyond the tool name itself.
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?
For a creation tool with no annotations and no output schema, the description is inadequate. It omits critical context such as the relationship between user creation and project assignment (n8n_add_user_to_project), hierarchical user management in n8n, or confirmation of what gets returned upon success.
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 score applies. The description adds no parameter-specific context (e.g., valid email formats, available roles, default values), but the schema adequately documents the four fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new user' is tautological, simply converting the snake_case name 'n8n_create_user' into a sentence. While it identifies the verb and resource, it does not clarify what type of user (instance-level vs project-member) or distinguish from siblings like n8n_add_user_to_project.
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 provided on when to use this versus alternatives like n8n_add_user_to_project (adding existing users vs creating new ones), prerequisites for creation, or what happens if the email already exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden, yet it provides no information about permanence, side effects on workflows using this tag, or error handling. The agent cannot determine if this is a hard delete or soft delete, or what happens to associated workflow relationships.
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 extremely brief at three words. While it wastes no words and is front-loaded by default, the brevity contributes to under-specification rather than clarity. However, given the constraint that every sentence must earn its place, the single statement is appropriately efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description is inadequate. It fails to disclose critical context such as deletion permanence, cascading effects on workflows (given sibling n8n_update_workflow_tags exists), or success/failure indicators that an agent would need to safely invoke this 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?
With 100% schema description coverage (the 'id' parameter is fully described in the schema), the baseline score is 3. The description adds no additional parameter semantics (e.g., format details, where to obtain the ID), but none are required given the complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a tag' is tautological, restating the function name (n8n_delete_tag) without adding specificity. It does not distinguish this from sibling operations like n8n_update_tag or n8n_create_tag, nor does it clarify what 'tag' refers to in the n8n context.
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 usage guidance is provided. The description does not indicate when to use delete versus update_tag, whether deletion is permanent, or if workflows must be untagged first (prerequisites). There are no alternatives or exclusions mentioned despite numerous sibling tag management 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to specify whether this performs a partial update (only modifying provided fields) or full replacement, whether the operation is idempotent, or what error occurs if the project ID doesn't exist. For a mutation operation, this lack of safety/behavioral context is a significant gap.
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 extremely brief (3 words) with zero redundancy or wasted text. While arguably underspecified, every word earns its place and the structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 parameters and no output schema or annotations, the description is incomplete. It omits critical context such as what 'type' values are valid, whether partial updates are supported, and what distinguishes project updates from other resource updates in the sibling list.
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% (all three parameters have descriptions in the schema). The description does not add parameter-specific semantics beyond the schema, but since the schema already documents 'Project ID', 'New project name', and 'Project type', 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a project' is tautological—it restates the tool name (n8n_update_project) without adding specificity. While it technically identifies the verb and resource, it fails to distinguish this from sibling update tools like n8n_update_workflow or n8n_add_user_to_project, and doesn't clarify what aspects of the project are updatable.
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 provided on when to use this tool versus alternatives (e.g., when to update a project name vs. transferring workflows/credentials between projects). No mention of prerequisites, side effects, or error conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to specify whether unspecified fields are preserved (PATCH) or replaced (PUT), whether the update is atomic, or what happens to active executions when nodes/connections are modified. No authentication or rate limit context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the single sentence is not verbose, it is inappropriately brief for a complex mutation tool handling nested objects (nodes, connections). The description is front-loaded but undersized for the operation's complexity, failing to earn its place by not conveying critical safety information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of complex nested objects (nodes and connections) and mutation semantics, the description is incomplete. It lacks explanation of return values (no output schema exists), partial update behavior, or the relationship between the 'active' parameter and the dedicated activation sibling tools.
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?
Input schema has 100% description coverage (all 5 parameters documented). The description adds no semantic detail beyond the schema (e.g., it doesn't explain the structure of 'nodes' or 'connections'), meeting the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a basic verb ('Update') and resource ('workflow'), and the word 'existing' correctly implies the 'id' parameter is required. However, it fails to distinguish from siblings like 'n8n_activate_workflow' or 'n8n_update_workflow_tags', leaving ambiguity about whether this tool handles activation or updates the workflow definition itself.
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 like 'n8n_activate_workflow' for activation changes or 'n8n_update_workflow_tags' for tag management. There is no mention of prerequisites (e.g., workflow must exist) or warnings about partial vs full updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but discloses almost nothing: no mention of idempotency (what if user already exists?), error conditions, permission requirements, or whether this overwrites existing roles. 'Add' implies mutation but lacks critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at 5 words, but underspecified rather than efficiently informative. It front-loads the action but wastes no space because it provides essentially no information beyond the function name itself.
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?
Incomplete for a mutation tool with 3 parameters and no output schema. Lacks clarification on relationship to update/remove siblings, success return values, or error handling patterns that would help the agent use the tool 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?
Input schema has 100% description coverage (projectId, userId, role all documented), establishing a baseline of 3. The description adds no additional semantic value such as valid role values, ID formats, or examples, but does not need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the basic action (add) and resource (user to project) clearly, but fails to distinguish from sibling tools like n8n_update_user_in_project or n8n_remove_user_from_project. It does not clarify whether this creates a new membership or modifies existing ones.
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 provided on when to use this versus n8n_update_user_in_project, prerequisites (whether user/project must exist first), or expected outcomes. The agent receives no hints about appropriate calling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden but fails to mention permissions required, idempotency behavior, naming constraints, or what the operation returns.
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 description is brief (4 words) and not verbose, but it is under-loaded; the single sentence fails to earn its place by providing actionable guidance beyond the tool name itself.
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?
For a sensitive credential creation operation with nested object parameters and no output schema or annotations, the description is insufficiently complete; it omits critical context like credential type discovery and data structure requirements.
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% (all three parameters have descriptions), establishing a baseline of 3. The description adds no additional semantic context beyond the schema, particularly for the opaque 'data' object parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the basic action (Create) and resource (credential) but lacks specificity about the n8n domain context or what distinguishes this from sibling operations like transfer_credential.
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 provided on when to use this tool versus alternatives, or prerequisites such as needing to know credential types/schemas beforehand (relevant given sibling n8n_get_credential_schema exists).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing behavioral traits. It fails to mention what role values are valid, whether the change is immediate, if it affects active sessions, or what permissions are required to execute this mutation.
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?
While extremely brief (4 words), the conciseness is not a virtue here because critical behavioral and contextual information is missing. The description is front-loaded with the verb but lacks the supporting detail needed for a safe mutation operation.
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?
As a mutation tool with no annotations and no output schema, the description should disclose safety characteristics and side effects. It lacks information about valid role enumerations, irreversible actions, or the relationship to project-level role updates, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with 'User ID' and 'New role' already defined. The description adds minimal semantic value beyond the schema, merely confirming the operation type implied by the parameter names. Baseline 3 applies since schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the basic action (update) and target resource (user's role) clearly, but lands at 'vague' rather than specific. It fails to distinguish from sibling tool 'n8n_update_user_in_project', leaving ambiguity about whether this updates global roles or project-specific roles.
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 provided on when to use this tool versus alternatives like n8n_update_user_in_project or n8n_create_user. No prerequisites, permission requirements, or workflow context is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It fails to specify idempotency behavior, what the operation returns (no output schema exists), or side effects beyond the basic creation act.
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 single sentence is appropriately sized and front-loaded with the action. While underspecified for completeness, the structure itself is efficient with no wasted words.
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?
For a mutation tool with no output schema and no annotations, the description is insufficient. It omits the tag's purpose (workflows vs. projects), return structure, and error handling, leaving critical gaps despite the low parameter complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage for the single 'name' parameter, the baseline is 3. The description adds no additional semantic context about naming constraints, permitted characters, or maximum length beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the basic verb and resource ('Create a new tag'), which is clear but minimal. It fails to specify the domain (n8n workflow tags) or distinguish from siblings like n8n_update_tag beyond the verb choice, leaving scope ambiguous.
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?
Provides no guidance on when to use this versus n8n_update_tag or n8n_update_workflow_tags, nor does it mention prerequisites (e.g., whether tag names must be unique) or error conditions for duplicates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Get' implies read-only, it does not confirm safety, disclose error handling (e.g., invalid ID), or describe what execution details are returned.
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?
Extremely concise at six words with no redundancy. However, given the absence of annotations and output schema, it may be overly terse rather than efficiently informative.
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?
Incomplete for a retrieval tool with no output schema: it fails to describe the structure or content of the returned execution details (status, timestamps, workflow ID, etc.) which agents need to handle the response.
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 'Execution ID' already describing the parameter. The description mentions 'specific execution' which loosely maps to the ID requirement but adds no format constraints, validation rules, or syntax details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the basic action (get details) and target (specific execution) clearly, but lacks specificity about what an 'execution' is in the n8n context and does not explicitly differentiate from sibling n8n_list_executions or 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this versus n8n_list_executions (search/list) or n8n_retry_execution, nor does it mention prerequisites like having a valid execution ID from a prior workflow run.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but fails to mention read-only nature, pagination behavior, whether results are sorted, or what data fields are returned (full objects vs. summaries).
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?
Extremely brief at 5 words, but not wasteful. However, given the lack of annotations and pagination complexity, the description is under-loaded rather than appropriately concise.
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?
Missing output description (no output schema present), pagination behavior explanation, and differentiation from similar tools. For a potentially high-volume list operation, the lack of completeness regarding result sets is a significant 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 has 100% description coverage for both parameters (limit and cursor), establishing baseline 3. The description adds no additional parameter context (e.g., recommended limit values, cursor format), but none is strictly required given complete schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the basic action (List) and resource (workflows) but uses the word 'all' which contradicts the pagination parameters (limit/cursor) present in the schema. It fails to distinguish from sibling tool n8n_get_workflow (singular retrieval vs. 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 provided on when to use this versus n8n_get_workflow or other retrieval siblings. No mention of pagination strategy or when to use cursor vs. initial fetch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure but only states the action verb 'Remove'. It fails to mention whether this is reversible, what happens to the user's workflows/credentials within the project, or required permissions (admin vs self-removal).
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 single sentence is efficient and front-loaded with no wasted words. However, extreme brevity contributes to under-specification for a mutation operation.
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?
For a user management mutation with no output schema and no annotations, the description is insufficient. It lacks critical safety context: side effects on project resources, reversibility, or whether the operation cascades to owned workflows.
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?
Input schema has 100% description coverage ('Project ID', 'User ID'), establishing a baseline of 3. The tool description adds no additional semantic context about parameter formats, constraints, or relationships beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action (remove) and scope (user from project) but is essentially a sentence-case expansion of the tool name 'n8n_remove_user_from_project'. While it implicitly distinguishes from 'n8n_delete_user' (removal vs deletion), it lacks specificity about what 'project' means in the n8n context or any behavioral details.
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 provided on when to use this versus siblings like 'n8n_update_user_in_project' (role change) or 'n8n_delete_user' (global deletion). No mention of prerequisites such as the user needing existing project membership.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, yet reveals nothing about whether this is a read-only operation, what user attributes are exposed, if results are paginated, or potential rate limits for bulk user queries.
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?
While the three-word description avoids verbosity, it borders on under-specification. It fails to front-load critical context about the scope of 'all users' (instance-wide vs. project-specific) or the expected return structure that would help an agent invoke the tool confidently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of complex user management siblings (n8n_update_user_role, n8n_add_user_to_project) and the absence of an output schema, the description is inadequate. It lacks explanation of user entity relationships, filtering capabilities, or output format that an agent would need to effectively utilize the returned user list.
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 contains zero parameters. Per calibration guidelines, this establishes a baseline score of 4, as there are no parameter semantics requiring description beyond the empty schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the basic verb (List) and resource scope (all users), but fails to distinguish this tool from sibling 'n8n_get_user'. Given that both tools involve user retrieval, the description should clarify that this returns a collection of all users versus retrieving a specific individual.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (like n8n_get_user), nor does it mention prerequisites such as administrative privileges typically required for listing users in n8n systems.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. 'Retry' implies mutation but lacks disclosure: whether it creates a new execution ID or reuses existing, if it waits for completion, valid terminal states for retry, or side effects on execution history. No mention of idempotency or rate limits.
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?
Extremely brief (4 words) and front-loaded, but sacrifices necessary behavioral detail for brevity. Under-specified rather than appropriately concise given the operational complexity of execution retry logic.
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?
For an execution retry operation, lacks critical context: whether it returns the new execution details, how it relates to the original execution record, and operational constraints. Simple schema with 1 parameter does not excuse missing behavioral context for workflow engine operations.
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 clear parameter description ('Execution ID to retry'). Description does not add parameter syntax, format constraints, or examples beyond schema, but baseline 3 is appropriate given complete schema documentation.
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?
States a specific verb (Retry) and resource (execution), with scope limitation (failed). Distinct from siblings like get_execution, delete_execution, and list_executions by specifying the retry action and failed-state precondition.
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 vs alternatives, prerequisites (e.g., execution must be in terminal failed state), or when not to use (e.g., cannot retry running executions). Missing error handling guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It states the mutation type (create) but omits critical safety details: idempotency, error conditions (e.g., duplicate key handling), return values, or whether the variable is instance-scoped or project-scoped.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence front-loads the core action. No wasted words, though brevity crosses into under-specification given the mutation complexity and lack of annotations.
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?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks error handling details, conflict resolution behavior (crucial for 'create' operations), and relationship to other variable lifecycle tools.
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%, documenting all three parameters (key, value, type) adequately. The description adds no additional semantic clarity (e.g., format constraints, examples) but baseline 3 is appropriate given complete schema coverage.
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?
Clear verb ('Create') and resource ('environment variable') with specific scope indicated by 'envrionment.' However, it fails to explicitly distinguish from sibling n8n_update_variable or clarify behavior if the variable already exists.
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 versus n8n_update_variable, nor prerequisites (e.g., whether the variable key must be unique, required permissions, or project scoping).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. While 'Delete' implies destruction, it fails to disclose whether deletion is permanent, if it affects running workflows, or whether authorization checks occur. No mention of error conditions (e.g., if ID not found).
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?
Extremely concise (4 words) with no redundancy. However, brevity crosses into under-specification given the lack of annotations and destructive nature of the operation.
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?
Adequate for a single-parameter CRUD operation with complete schema coverage, but gaps remain: no output schema explanation (though not required), no safety confirmation patterns, and no linkage to sibling variable tools for full workflow context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with 'id' fully described as 'Variable ID to delete'. Description adds no additional semantics, examples, or format constraints beyond the schema, warranting baseline score.
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?
Clear verb 'Delete' and resource 'environment variable' identify the operation. However, it does not distinguish from sibling variable operations (create, update, list) or clarify when deletion is preferable to updating versus creating.
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?
Provides no guidance on when to use this tool versus alternatives (e.g., when to delete vs update a variable) or prerequisites (e.g., checking if variable is in use). No safety warnings or exclusion criteria mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden but omits critical behavioral details: output format (JSON, PDF, report?), delivery method (returned value, file download, email?), execution time, or whether this triggers a background job versus immediate response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of six words is appropriately compact with no filler, though arguably under-loaded given the tool's complexity and lack of supporting annotations or output schema.
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?
Insufficient for a complex diagnostic operation. No output schema exists, yet the description doesn't explain return values, report contents, or side effects. The vague 'options' parameter combined with missing behavioral details leaves significant gaps for an AI attempting to invoke this 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 has 100% coverage with one parameter described as 'Audit options', so baseline is 3. The description adds no clarifying details about what specific options are available (scope, depth, format) or their valid values, leaving the parameter effectively undocumented 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?
States a clear verb ('Generate') and specific resource ('security audit'), making the basic purpose understandable. However, it fails to distinguish from sibling diagnostic tools like 'n8n_health_check' or clarify what constitutes a security audit in this context.
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?
Provides no guidance on when to invoke this tool versus alternatives like health_check, or prerequisites such as admin permissions typically required for security audits. No 'when-not-to-use' warnings included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. 'Get' implies read-only, but lacks disclosure of return format, authentication requirements, or whether schema is static/dynamic. No mention of what happens if credential type doesn't exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no waste. However, extreme brevity leaves gaps for a tool lacking annotations and output schema. Information density is high but insufficient for complete understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks explanation of return value structure despite no output schema being defined. No mention of available credential types or relationship to n8n_create_credential. Given zero annotations, description should compensate with richer behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage (parameter described as 'Credential type name'), meeting baseline. Description adds no additional semantic value about valid credential type values or format constraints beyond 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?
Clear verb 'Get' with specific resource 'schema for a credential type'. Distinguishes from credential instance operations (like create_credential) by specifying 'schema', though could better differentiate from credential management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 versus sibling tools. Missing context such as 'use before create_credential to validate required fields' or indication of how credentialTypeName values are discovered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden of behavioral disclosure. 'Get' implies read-only but doesn't confirm safety, disclose error conditions (e.g., 404 behavior), payload size, or return structure. Minimal behavioral context provided.
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?
Extremely concise at 7 words. Front-loaded with verb first. No redundancy or fluff. However, brevity comes at cost of completeness given lack of annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero annotations and no output schema, description is insufficient. Fails to describe what workflow data is returned, authentication requirements, or how this relates to other workflow operations in the extensive sibling set.
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 'id' parameter described as 'Workflow ID'. Description doesn't add parameter syntax/semantics, but with full schema coverage, baseline 3 is appropriate—no compensation needed.
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?
Clear verb (Get) + resource (workflow) + scope (specific by ID). Distinguishes from sibling list_workflows by emphasizing 'specific' and 'by ID', though could clarify this retrieves the workflow definition/configuration object specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use versus n8n_list_workflows (when ID known vs. discovery) or error handling if ID doesn't exist. Assumes user knows when to fetch by ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'List all projects' implies an unfiltered read operation but fails to disclose pagination behavior, rate limits, authentication requirements, or the structure/format of returned project data. The scope of 'all' is undefined (e.g., across all workspaces or scoped to credentials).
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 three-word description is extremely efficient with zero redundancy. However, given the absence of annotations, output schema, and behavioral details, the description verges on under-specification rather than optimal conciseness—it could afford additional sentences explaining return values or usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and a simple read-only intent, the description provides minimally viable information to invoke the tool. However, with no output schema available, the description should have described the return structure (fields, format) or filtering limitations to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema contains zero parameters. Per rubric guidelines, 0 parameters establishes a baseline score of 4. The description does not need to compensate for missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (List) and resource (projects), providing clear minimal purpose. However, it lacks scope context (what defines a project in n8n vs workflows/executions) and does not differentiate from the numerous sibling 'list' operations (list_workflows, list_users, etc.) beyond the resource name.
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 provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., admin permissions) or when to prefer this over project-specific getters like n8n_get_workflow (if projects contain workflows). The agent receives no decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'List all tags' implies a read-only operation but fails to disclose performance characteristics (e.g., pagination for large tag lists), authentication requirements, or what the 'tags' represent in the n8n context.
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?
Extremely concise at three words with no wasted language. However, the single-sentence fragment structure, while efficient, is too minimal to provide necessary context without sacrificing completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description is minimally viable for a simple listing operation. However, it lacks necessary context about the return value structure and fails to clarify relationship with workflow-specific tag operations, leaving clear gaps for a tool with multiple related siblings.
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 contains zero parameters. Per the baseline rule, this earns a 4. There are no parameter semantics to document beyond what the empty schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('tags'), but fails to distinguish from sibling tool 'n8n_get_workflow_tags', which could confuse users about whether this returns system-wide tags or workflow-specific tags. It identifies the basic operation but lacks scope clarification.
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?
Provides no guidance on when to use this tool versus alternatives like 'n8n_get_workflow_tags' or 'n8n_get_tag'. No 'when to use' or 'when not to use' context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavior, yet it only states the action without explaining consequences. It does not clarify whether this overwrites local workflow changes, handles merge conflicts, requires specific permissions, or affects the execution state of active workflows.
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 four-word description is appropriately brief but fails to utilize the available space to convey critical behavioral context for a potentially destructive synchronization operation. While not verbose, the brevity results in under-specification rather than efficient information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that source control pull operations typically involve complex state management (conflicts, branch tracking, credential validation), the description is insufficient for safe invocation without additional external knowledge. The absence of an output schema and annotations compounds the need for descriptive completeness that is not met.
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?
With zero parameters in the input schema, the baseline score applies; the description appropriately does not fabricate parameter details. The description remains consistent with the empty schema structure.
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 uses the specific verb 'Pull' and identifies 'source control' as the target resource, clearly indicating it retrieves changes from a version control system. While it conveys the basic operation, it does not explicitly differentiate from any hypothetical sibling source control tools (e.g., push, commit) or clarify that this operates on n8n's configured source control integration.
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 invoke this tool versus alternatives, nor does it mention prerequisites such as configured source control credentials or repository setup. There is no mention of error conditions, conflicts, or when the operation should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States 'transfer' but fails to clarify critical behavioral details: whether this moves (removes from source) or copies the credential, whether the credential ID changes, or if existing references break.
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?
Single sentence with zero waste. Action verb front-loaded. Efficient structure despite brevity; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Transfer operations typically involve destructive side effects and prerequisites. With no annotations, output schema, or behavioral details in the description, critical context is missing for safe 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 has 100% description coverage ('Credential ID', 'Target project ID'), satisfying baseline. Description provides semantic action context ('Transfer') linking the two parameters but adds no format constraints or usage examples 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?
Specific verb 'Transfer' with clear resource 'credential' and scope 'to another project'. Distinguishes from sibling n8n_transfer_workflow by specifying the resource type, though it could clarify the transfer mechanism (move vs copy).
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?
Provides no guidance on when to use this tool versus alternatives like n8n_create_credential, or prerequisites such as whether the destination project must exist or required permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. It fails to clarify whether the source workflow is deleted (move) or duplicated (copy), whether execution history and tags transfer, or required permissions. 'Transfer' implies mutation but lacks critical safety context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with zero waste and front-loaded information. However, extreme brevity leaves dangerous ambiguity for a cross-project data migration operation; appropriately concise but underspecified for the tool's risk level.
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?
Insufficient for a destructive/mutating operation. Missing: side effects on source project, credential reference handling, idempotency behavior, and error conditions. No output schema requires description to explain return values or success confirmation, which is absent.
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 clear descriptions ('Workflow ID', 'Target project ID'). Since the schema fully documents parameters, baseline is 3. Description adds no additional semantics (e.g., ID format, validation rules) but does not need to compensate for coverage gaps.
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?
States a specific verb ('Transfer') and resource ('workflow') with clear scope ('to another project'). Distinguishes from sibling 'n8n_transfer_credential' by specifying the workflow resource, though 'transfer' remains ambiguous regarding whether this is a move (destructive to source) or copy 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?
No guidance provided on when to use versus alternatives (e.g., 'update_workflow' to change projects), prerequisites (ownership requirements), or when the operation might fail (e.g., destination project constraints).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure yet only states the mutation type without clarifying if partial updates are supported (optional parameters suggest yes), what happens to omitted fields, or required permissions. For a destructive-capable operation, this lack of safety context is a significant gap.
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 four-word description is maximally efficient with zero redundancy, presenting the core action immediately. However, given the absence of annotations and output schema, this extreme brevity becomes a liability rather than a virtue, leaving insufficient contextual information.
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?
As a mutation tool with four parameters, no annotations, and no output schema, the minimal description fails to compensate for missing structured metadata. It omits critical context such as success/failure indicators, side effects on running workflows, or whether the update is atomic.
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 achieves 100% description coverage, documenting each parameter's basic purpose (id, key, value, type). The description adds no additional semantic detail regarding valid 'type' values, key naming conventions, or value constraints, but meets the baseline expectation given the comprehensive schema coverage.
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 identifies the action ('Update') and resource ('environment variable'), establishing a distinct purpose from siblings like n8n_create_variable or n8n_delete_variable through the verb choice. However, it lacks scoping details or behavioral constraints that would fully differentiate it from other variable management operations.
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 prefer this tool over n8n_create_variable (for new variables) or when partial updates versus full replacements are appropriate. No prerequisites, error conditions, or ownership requirements are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Critically fails to disclose whether the operation replaces all existing tags (destructive overwrite) or appends to them, nor does it explain behavior when tagIds is empty (clear all tags?). No mention of error conditions or idempotency.
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?
Extremely concise at only 5 words, front-loaded with the operative verb. While efficiently structured, the brevity contributes to under-specification of behavioral traits. One sentence that earns its place for basic identification, though context requires more.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple 2-parameter structure with complete schema coverage, the description minimally identifies the operation. However, for a mutation tool without output schema or annotations, it lacks essential behavioral context (overwrite semantics) and error handling guidance that would be needed for confident agent 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 has 100% description coverage ('Workflow ID' and 'Array of tag IDs'), establishing baseline 3. The description adds no semantic context about ID formats, validation rules, or the significance of the array order. No compensation provided for the behavioral ambiguity in how tagIds should be constructed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb (Update) and resource (tags for a workflow), identifying it as a mutation operation on workflow-tag associations. While it implies the scope correctly, it could explicitly distinguish from sibling 'n8n_update_tag' (which likely updates tag definitions rather than workflow assignments).
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 provided on when to use vs alternatives, prerequisites (e.g., tags must exist first via create_tag), or whether this replaces existing tags versus appending to them. No mention of workflow activation requirements or permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations provided, the description carries the full burden of behavioral disclosure but fails to indicate whether the operation is read-only, whether sensitive values are masked, pagination behavior, or the return structure. 'List all' implies an unfiltered operation, but lacks critical safety and scope details.
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?
Extremely brief at four words with no redundant phrasing or wasted sentences. Appropriately sized for the input complexity, though the extreme brevity limits informational value rather than demonstrating efficient information packing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description inadequately compensates by failing to describe return values, data structure, authentication requirements, or pagination limits. For a read operation with no inputs, minimum viable documentation would include the response format.
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?
Input schema contains zero parameters. Per evaluation guidelines, zero parameters establishes a baseline score of 4. The description does not need to compensate for undocumented parameters.
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 provides a clear verb ('List') and resource ('environment variables'), distinguishing it from sibling tools that operate on workflows, users, projects, etc. However, it does not explicitly differentiate from related variable CRUD operations (create_variable, update_variable) or clarify scope beyond the word 'all'.
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 provided on when to use this tool versus alternatives like create_variable or update_variable, or prerequisites such as required permissions. Single functional statement with no contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. While 'Get' implies read-only, there is no disclosure of error behavior (e.g., ID not found), authentication requirements, or what fields the returned tag contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at six words. Front-loaded with verb and resource. No redundancy or wasted sentences for a single-parameter read operation.
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?
Adequate for low-complexity tool with full schema coverage, but lacks description of return value structure or error states given the absence of an output schema. Does not define what a 'tag' represents in n8n context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage for the single 'id' parameter. The description mentions 'by ID' which aligns with the schema but adds no additional semantic value (format constraints, example IDs, or lookup behavior).
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?
States clear verb+resource (Get + tag) and scope (specific by ID). The 'by ID' phrasing distinguishes from n8n_list_tags, but does not explicitly clarify relationship to n8n_get_workflow_tags or when to prefer listing over retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus n8n_list_tags (e.g., when the ID is already known) or n8n_get_workflow_tags. No mention of prerequisite steps like obtaining the tag ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get' implies a read-only operation, the description does not confirm safety characteristics, disclose what happens if the ID is not found, describe the return format, or mention rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence of six words that is appropriately front-loaded with the verb. There is no redundant or wasteful text for this simple single-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no output schema, basic CRUD operation), the description provides minimal viable information. However, it lacks behavioral context like error handling for missing IDs or expected return structure, which would be necessary for a complete specification without an 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?
The input schema has 100% description coverage (the 'id' parameter is described as 'User ID'). The description references 'by ID', creating a semantic link to the parameter, but does not add syntax details, format constraints, or examples beyond what the schema already provides. Baseline 3 is appropriate for high-coverage schemas.
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 uses a specific verb ('Get') and resource ('user') and qualifies it with 'specific' and 'by ID', implicitly distinguishing it from the sibling tool n8n_list_users. However, it does not explicitly name the sibling alternative or clarify when to prefer listing over getting.
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 (e.g., n8n_list_users), nor does it mention prerequisites such as permissions or authentication requirements. There are no 'when-not' exclusions or conditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the basic mutation action without disclosing idempotency, what happens if the user isn't in the project, valid role values, or permission requirements.
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?
Seven words with no redundancy. The single sentence front-loads the action and scope efficiently—every word earns its place.
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?
Adequate for identifying the operation, but given no output schema and no annotations, the description should specify valid role values and prerequisites (user must exist in project). It meets minimum viability but leaves operational 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% with clear labels ('Project ID', 'User ID', 'New role'), establishing a baseline of 3. The description doesn't add value beyond the schema regarding valid role formats or accepted values, which is critical given the lack of enum constraints.
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 uses a specific verb ('Update') with clear resource ('user's role in a project'), distinguishing it from global user management. However, it doesn't explicitly differentiate from the sibling 'n8n_update_user_role' (likely global) vs this project-scoped 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?
No guidance provided on when to use this versus 'n8n_add_user_to_project' (prerequisite: user must already be in project) or 'n8n_remove_user_from_project'. Also lacks guidance on valid role values since the schema lacks enums.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, yet the description fails to disclose what 'health' entails (simple connectivity vs. dependency checks), whether the operation is read-only/safe, potential rate limits, or what response format to expect. It carries the full burden of behavioral disclosure but provides minimal information.
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 single sentence is appropriately front-loaded with the action verb, contains zero redundancy, and is perfectly sized for a zero-parameter diagnostic tool. No extraneous words or formatting issues.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no annotations), the description covers the basic intent but remains insufficient regarding output expectations. Without an output schema or description of return values (e.g., boolean vs. detailed status object), an agent cannot predict what data structure it will receive upon invocation.
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 contains zero parameters, which per the evaluation rules establishes a baseline score of 4. The description correctly implies no configuration is needed for a basic health check.
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 uses a clear verb ('Check') and identifies the resource ('health status of the n8n instance'). It effectively distinguishes itself from the 40+ sibling tools which are all CRUD operations on specific entities (workflows, users, credentials, etc.), though it could specify what aspects of health are validated (API, database, etc.).
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?
Provides no guidance on when to invoke this tool versus other diagnostic options, nor does it indicate prerequisites (e.g., whether it requires authentication unlike public health endpoints) or when to avoid using it. The agent must infer usage context solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

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

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