MCP- N8N

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose targeting specific resources and actions (e.g., create-workflow vs. activate-workflow, get-user vs. list-users). The descriptions reinforce these distinctions, making it easy for an agent to select the correct tool without confusion. No overlapping or ambiguous tools exist in the set.
Naming Consistency5/5
Tool names follow a consistent verb-noun pattern with hyphens throughout (e.g., create-workflow, list-users, update-tag). All tools adhere to this convention without deviations, making the naming predictable and readable. The pattern is uniformly applied across all 33 tools.
Tool Count3/5
With 33 tools, the count is borderline high for the n8n automation domain, which involves workflows, credentials, users, tags, variables, projects, and executions. While the tools cover many aspects comprehensively, the number may feel heavy and could overwhelm agents, though it's not extreme. A more streamlined set might improve usability.
Completeness5/5
The tool set provides complete CRUD/lifecycle coverage for all key n8n resources: workflows (create, get, list, update, activate/deactivate, delete), credentials (create, get-schema, delete), users (create, get, list, delete), tags (create, get, list, update, delete), variables (create, list, delete), projects (create, list, update, delete), and executions (get, list, delete). No obvious gaps exist, and tools like init-n8n and generate-audit add essential setup and security functions.
Average 3.2/5 across 33 of 33 tools scored. Lowest: 2.5/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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Delete a user' implies a destructive, irreversible mutation, but the description doesn't mention permission requirements, whether deletion is permanent, what happens to associated resources, or any confirmation steps. For a destructive operation with zero annotation coverage, this is critically inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that gets straight to the point with no wasted words. It's appropriately sized for a simple tool name and efficiently communicates the core action without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a destructive mutation tool with no annotations, no output schema, and undocumented parameters. The description fails to address critical context: what permissions are needed, whether deletion is reversible, what validation occurs, what the response looks like, or how it differs from other user-related tools. For a tool that permanently removes users, this level of incompleteness is dangerous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 required parameters (clientId, idOrEmail) with 0% description coverage, meaning neither parameter is documented in the schema. The description provides no information about what these parameters represent, their format, or how they're used. This leaves the agent guessing about parameter meaning and usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and target resource ('a user from your instance'), making the purpose immediately understandable. However, it doesn't differentiate this tool from other deletion tools like delete-credential or delete-project, which would require specifying what distinguishes user deletion from other resource deletions.
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. With sibling tools like get-user (for viewing), create-users (for adding), and list-users (for listing), there's no indication of prerequisites, when deletion is appropriate, or what happens to user data after deletion. The description simply states what it does without contextual 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 are provided, so the description carries full burden. It states the tool deactivates a workflow, implying a mutation, but lacks details on permissions, reversibility, side effects, or response format. The JSON formatting note is procedural but not behavioral.
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?
Two sentences: first states purpose and effect, second provides a technical note. It's front-loaded with core information and avoids redundancy, though the JSON formatting note could be more integrated.
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, 0% schema coverage, and no output schema, the description is incomplete. It lacks details on behavior, parameters, and outcomes, making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'ID' but not 'clientId', leaving one parameter unexplained. No details on parameter formats, sources, or constraints are provided, failing to add meaningful semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('deactivate') and resource ('workflow by ID'), with the effect 'prevent the workflow from running'. It distinguishes from siblings like 'activate-workflow' by specifying deactivation, though not explicitly contrasting them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'delete-workflow' or 'update-workflow', nor prerequisites such as workflow state. It only mentions a technical requirement for JSON formatting, not contextual usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool enables a workflow to run, implying a mutation, but doesn't disclose behavioral traits such as permissions required, whether activation is reversible, side effects, or rate limits. The JSON formatting note is helpful but insufficient for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose stated first and a critical formatting note added concisely. Both sentences earn their place by providing essential information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with 2 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover parameter meanings, behavioral context, or return values, making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'ID' but doesn't explain what 'clientId' or 'id' represent (e.g., workflow identifier vs. client context). No details on parameter formats, sources, or constraints are provided, leaving both parameters largely undocumented beyond their names in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Activate') and resource ('workflow by ID'), specifying what the tool does. It distinguishes from sibling 'deactivate-workflow' by indicating enabling vs. disabling. However, it doesn't fully differentiate from other workflow-related tools like 'update-workflow' or 'get-workflow' beyond the activation action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., workflow must exist and be deactivated), exclusions, or compare with siblings like 'deactivate-workflow' or 'update-workflow'. The only usage hint is about JSON formatting, which is technical rather than contextual.
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 'Create' implies a write/mutation operation, the description doesn't address permissions needed, whether the operation is idempotent, what happens on duplicate names, or what the response contains. For a mutation tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 6 words, with zero wasted language. It's front-loaded with the core action and resource, making it immediately understandable despite its 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 mutation tool with no annotations, no output schema, and two undocumented parameters, the description is insufficiently complete. It doesn't explain what a 'tag' represents in this system, what the parameters do, what happens after creation, or how this operation fits within the broader context of tag management (alongside get-tag, update-tag, delete-tag).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and two required parameters (clientId and name), the description provides no information about what these parameters mean, their format, or their purpose. The description doesn't compensate for the complete lack of parameter documentation in the schema, leaving both parameters completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new tag'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'update-tag' or explain what distinguishes tag creation from other creation operations like 'create-project' or 'create-workflow'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like needing a specific instance context), when not to use it, or how it differs from similar tools like 'update-tag' or other creation operations in the sibling list.
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. While 'create' implies a write operation, it doesn't mention required permissions, whether this is idempotent, what happens on duplicate emails, or what the response contains. For a user creation tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a basic tool description and front-loads the essential 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?
For a user creation tool with no annotations, no output schema, and 0% schema description coverage, the description is inadequate. It doesn't explain what happens after creation, what validation occurs, or what errors might be returned. The agent would struggle to use this tool effectively without trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but provides no parameter information. It doesn't explain what 'clientId' represents, what the 'users' array structure should contain, or the meaning of email/role fields. The description adds no value beyond what's already in the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('create') and resource ('users'), specifying it can handle 'one or more users' which adds useful scope information. It doesn't explicitly distinguish from sibling tools like 'create-project' or 'create-tag', but the resource specificity is clear.
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 'update-project' or 'delete-user'. It mentions 'in your instance' which gives some context but doesn't specify prerequisites, permissions needed, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the destructive action ('Delete') but lacks critical details: whether deletion is permanent or reversible, what permissions are required, if there are side effects (e.g., cascading deletions), or what happens on success/failure. For a destructive tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple deletion operation and front-loads the core action and target, making it easy to parse quickly.
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 tool with no annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't address critical aspects like what 'execution' means in this context, the consequences of deletion, error conditions, or return values. For a tool that permanently removes data, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but fails to do so. It mentions 'ID' but doesn't clarify which parameter (id vs clientId) represents the execution ID, what format these IDs take, or their purpose. With 2 undocumented parameters, the description adds minimal value beyond the schema's structural information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and target resource ('a specific execution by ID'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling deletion tools like delete-credential or delete-workflow, which would require mentioning what makes an 'execution' distinct from those other 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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing an existing execution ID), exclusions, or relationships with sibling tools like get-execution or list-executions. This leaves the agent without context for proper tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool generates an audit but doesn't describe what the output looks like (e.g., report format, data included), whether it's a read-only operation, if it requires specific permissions, or any side effects (e.g., logging, notifications). This leaves significant gaps for an agent to understand how to use it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly. Every part of the sentence contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a security audit tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't address key aspects like what the audit checks, how results are returned, or the meaning of parameters. For a tool that likely produces detailed security insights, this minimal description leaves too much undefined for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the three parameters (categories, clientId, daysAbandonedWorkflow) are documented in the schema. The description adds no information about these parameters—it doesn't explain what 'categories' includes, what 'clientId' refers to, or how 'daysAbandonedWorkflow' affects the audit. With low coverage, the description fails to compensate, leaving parameters largely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('generate') and the resource ('security audit for your n8n instance'), providing a specific purpose. It distinguishes itself from sibling tools which focus on CRUD operations for workflows, credentials, users, etc., rather than security auditing. However, it doesn't explicitly mention what the audit entails or its scope beyond 'security'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, frequency, or typical use cases (e.g., compliance checks, security reviews). With many sibling tools for managing n8n resources, there's no indication of how this tool fits into broader workflows or when it should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'retrieve' which implies a read operation, but doesn't cover permissions, rate limits, error handling, or response format. For a tool with 3 parameters and no output schema, this is insufficient 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place in conveying the basic purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the execution resource, what data is retrieved, or how parameters interact. For a retrieval tool in a workflow/execution system, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'clientId', 'id', or 'includeData' mean, their formats, or how they affect the retrieval. This leaves all 3 parameters undocumented beyond their schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieve' and the resource 'execution by ID', making the purpose understandable. However, it doesn't differentiate from sibling tools like 'list-executions' or 'get-workflow', which also retrieve execution-related data, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'list-executions' or 'get-workflow'. It lacks context on prerequisites, exclusions, or specific use cases, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a retrieval operation, implying read-only behavior, but doesn't mention authentication requirements, rate limits, error conditions, or response format. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a simple retrieval tool and front-loads the core purpose effectively.
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 (a read operation with 2 required parameters), lack of annotations, and no output schema, the description is insufficient. It doesn't explain parameter meanings, return values, error handling, or how it differs from similar tools, leaving the agent with inadequate context for proper use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for its two parameters (clientId and id), and the description doesn't explain what these parameters mean or how they're used. It mentions 'ID' generically but doesn't clarify if this refers to the 'id' parameter or something else, failing to compensate for the schema's lack of 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?
The description clearly states the action ('Retrieve') and resource ('a specific tag by ID'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'list-tags' or 'get-workflow-tags', which would require explicit comparison to achieve a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list-tags' or 'get-workflow-tags'. It lacks context about prerequisites (e.g., needing a tag ID) or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'Get[s] user' but doesn't clarify if this is a read-only operation, what permissions are required, whether it returns partial or full user data, or error handling (e.g., for invalid IDs). The description lacks critical behavioral traits like safety, response format, or rate limits, leaving significant gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence ('Get user by ID or email address.') that front-loads the core purpose. Every word earns its place, avoiding redundancy or fluff, making it efficient for quick comprehension by an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 required parameters), no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like read/write nature, error cases, or return values, and parameter guidance is insufficient. For a user retrieval tool in a system with multiple user-related operations, more context is needed to ensure correct agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds minimal value. It mentions 'ID or email address', which loosely relates to 'idOrEmail', but doesn't explain the 'clientId' parameter at all or provide format details (e.g., email syntax, ID constraints). With 2 undocumented parameters, the description fails to adequately clarify their semantics beyond a vague hint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('user'), specifying it can be retrieved by 'ID or email address'. It distinguishes from siblings like 'list-users' (which retrieves multiple users) by focusing on single-user lookup. However, it doesn't explicitly contrast with 'delete-user' or 'create-users', leaving some sibling differentiation incomplete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer 'get-user' over 'list-users' for single-user queries, nor does it address prerequisites like authentication or context for using 'idOrEmail' versus 'clientId'. There's no explicit when/when-not or alternative tool references.
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 only states it 'retrieves' executions without disclosing behavioral traits like pagination, rate limits, permissions needed, or what 'includeData' entails. It lacks details on response format or any side effects, leaving significant gaps for a tool with 5 parameters.
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 with no wasted words, front-loading the core action and key feature (filtering). Every part earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no output schema, no annotations), the description is inadequate. It doesn't explain return values, error handling, or parameter interactions, leaving too much undefined for effective agent use despite the concise structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but only vaguely mentions 'optional filtering' without explaining parameters like 'clientId', 'includeData', 'limit', 'status', or 'workflowId'. It adds minimal meaning beyond the schema, failing to clarify parameter purposes or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieve' and resource 'executions' with scope 'from your instance', making the purpose understandable. It distinguishes from siblings like 'get-execution' by specifying 'all executions' with filtering, though it doesn't explicitly contrast with other list tools like 'list-projects'.
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 mentions 'optional filtering' but provides no guidance on when to use this tool versus alternatives like 'get-execution' for single executions or other list tools. There are no explicit when/when-not instructions or prerequisites stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a retrieval operation, implying it's likely read-only, but doesn't specify authentication requirements, rate limits, pagination behavior (despite a 'limit' parameter), or what 'all tags' entails (e.g., if it includes archived tags). This leaves significant gaps for a tool with parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core purpose, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 parameters, no annotations, no output schema), the description is inadequate. It doesn't explain parameter usage, behavioral traits, or output format, leaving the agent with insufficient information to use the tool effectively beyond basic intent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'all tags' but doesn't explain the 'clientId' (required) or 'limit' parameters, their purposes, formats, or constraints. The description adds no meaningful parameter information beyond what's inferred from the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve') and resource ('all tags'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get-tag' (which presumably retrieves a specific tag) or 'list-workflow-tags' (which might list tags associated with workflows), so it doesn't achieve full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get-tag' or 'list-workflow-tags'. It also doesn't mention prerequisites (e.g., authentication needs) or contextual constraints, leaving the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool updates a tag's name, implying a mutation, but doesn't address permissions, side effects, error conditions, or response format. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with 3 required parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain parameter roles, behavioral traits, or expected outcomes, making it insufficient for safe and effective use by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only mentions 'name' as the field to update, ignoring 'clientId' and 'id' parameters entirely. This leaves two required parameters semantically unexplained, failing to add meaningful value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('a tag's name'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'update-project' or 'update-workflow' beyond the resource type, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing tag ID), exclusions, or comparisons to sibling tools like 'create-tag' or 'delete-tag', leaving the agent without contextual usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('update') but doesn't describe what 'update' entails—whether it replaces all tags, merges with existing ones, or requires specific permissions. It also omits details on error handling, rate limits, or response format, leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word contributes directly to stating the tool's purpose, achieving optimal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with three required parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It fails to address key aspects like parameter meanings, behavioral traits, or return values, leaving the agent under-informed for proper invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate but adds no parameter information. It doesn't explain what 'clientId', 'workflowId', or 'tagIds' represent, their formats, or how they interact. For a tool with three required parameters, this lack of semantic detail is a major shortfall.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('update') and resource ('tags associated with a workflow'), making the purpose understandable. It distinguishes from siblings like 'create-tag' or 'delete-workflow' by focusing on modification rather than creation or deletion. However, it doesn't specify whether this replaces or merges tags, which would make it more specific.
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 'create-tag' or 'delete-workflow'. The description doesn't mention prerequisites (e.g., needing existing tags or workflows) or exclusions. It leaves the agent to infer usage from the name alone, which is insufficient for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('Delete') which implies a destructive mutation, but doesn't specify consequences (e.g., irreversible, cascading effects), permissions required, error conditions, or response format. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place, achieving optimal conciseness for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a destructive mutation tool with no annotations, 0% schema description coverage, and no output schema, the description is insufficient. It lacks critical details like behavioral traits, parameter explanations beyond 'id', and expected outcomes. For a tool that permanently removes data, more context is needed to ensure safe and correct usage.
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 0%, so the description must compensate. It mentions 'by ID', which clarifies the 'id' parameter's purpose, but doesn't explain 'clientId' or provide format details. Since parameters are minimal (2) and the description adds some meaning for one parameter, it meets the baseline but doesn't fully address the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a tag by ID'), making the purpose unambiguous. It distinguishes from sibling tools like 'get-tag' or 'update-tag' by specifying deletion. However, it doesn't explicitly differentiate from other delete operations like 'delete-project' or 'delete-workflow', though the resource type is implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., tag must exist), exclusions (e.g., cannot delete if in use), or compare to siblings like 'update-tag' or 'get-tag'. The agent must infer usage solely from the tool name and 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 states a read operation ('Get'), implying it's likely safe and non-destructive, but doesn't confirm this or detail other traits like authentication needs, rate limits, or return format. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly. Every word earns its place, contributing to clarity without redundancy.
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 (a read operation with 2 required parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain return values, error conditions, or behavioral nuances, leaving users with insufficient information to use the tool effectively. More detail is needed to compensate for the missing structured data.
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 0%, so the description must compensate for undocumented parameters. It mentions 'workflow' but not 'clientId', failing to explain both parameters fully. The description adds minimal value beyond the schema, as it doesn't clarify what 'clientId' and 'workflowId' represent or their expected formats, leaving parameters largely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('tags associated with a workflow'), making the purpose understandable. It doesn't explicitly differentiate from siblings like 'get-tag' or 'list-tags', but the focus on workflow-specific tags is implied. This is clear but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, such as when to choose 'get-workflow-tags' over 'list-tags' or 'get-tag'. Without such guidance, users may struggle to select the correct tool among similar options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the mutation action ('Update') and a critical format requirement ('compact, single-line JSON'), but fails to cover permissions, error handling, rate limits, or what happens to unspecified properties. For a mutation tool with zero annotation coverage, this leaves significant gaps.
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 appropriately sized with two sentences: the first states the purpose and usage, and the second provides a critical formatting requirement. It is front-loaded with essential information and avoids unnecessary details, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (mutation tool with nested objects, 3 parameters, 0% schema coverage, no output schema, and no annotations), the description is incomplete. It lacks details on parameter meanings, behavioral traits like permissions or side effects, and expected outcomes, making it inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'Arguments must be provided as compact, single-line JSON', which adds formatting context beyond the schema, but does not explain the purpose or semantics of the three required parameters (clientId, id, workflow). This partial compensation is insufficient for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('an existing workflow in n8n'), and specifies what can be modified ('workflow's properties, nodes, or connections'). It distinguishes from siblings like 'create-workflow' by focusing on existing workflows, though it doesn't explicitly contrast with all siblings like 'update-project'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some guidance by mentioning 'Use after get-workflow', which implies a prerequisite and sequence. However, it lacks explicit alternatives (e.g., when to use 'create-workflow' instead) or exclusions (e.g., when not to use it), leaving usage context partially implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the ownership requirement, which is useful, but doesn't disclose other behavioral traits such as whether the deletion is permanent, reversible, requires confirmation, has side effects, or what happens on success/failure. For a destructive operation with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste, front-loading the core action and following with a key constraint. Every sentence earns its place by providing essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive operation), lack of annotations, 0% schema coverage, and no output schema, the description is incomplete. It misses critical details like parameter meanings, behavioral outcomes, and error handling, making it insufficient for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'ID' but doesn't explain what 'clientId' or 'id' represent, their formats, or relationships. The description adds minimal meaning beyond the schema, failing to address the undocumented parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('credential by ID'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'delete-execution', 'delete-project', etc., which follow the same pattern, so it's not fully distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite ('You must be the owner of the credentials'), which implies when to use it based on ownership. However, it doesn't explicitly state when to choose this tool over alternatives like 'delete-user' or provide exclusions, leaving usage context partially implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions licensing requirements and input format constraints ('Arguments must be provided as compact, single-line JSON'), which adds some context. However, it lacks details on permissions, side effects, error handling, or response format, leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with two sentences that directly address purpose, requirements, and input format. Every sentence adds value, though it could be slightly more structured by separating the NOTE and IMPORTANT points into distinct lines for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with 3 parameters), no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It covers licensing and input format but misses critical details like parameter meanings, behavioral traits, and expected outcomes, making it inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning none of the three parameters (clientId, name, projectId) are documented in the schema. The description only mentions 'name' as the field being updated and doesn't explain what clientId or projectId represent or how they are used, failing to compensate for the schema's lack of 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?
The description clearly states the tool's purpose: 'Update a project's name.' It specifies the verb ('Update') and resource ('project's name'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'update-workflow' or 'update-tag', which is why it doesn't reach a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'Requires n8n Enterprise license with project management features enabled.' This indicates prerequisites, but it doesn't specify when to use this tool over alternatives like 'create-project' or 'delete-project', or when not to use it, which prevents a score of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that 'active' is read-only and shouldn't be included, which is useful behavioral context. However, it lacks details on permissions needed, whether creation is idempotent, error handling, or what happens if invalid data is provided, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose. The two sentences earn their place by covering creation and critical formatting requirements, though the second sentence is a bit dense with multiple points (JSON format, structure, and 'active' property) that could be slightly better structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It adds value with formatting rules and the 'active' property note, but fails to explain parameter meanings, expected outputs, or error conditions, making it inadequate for safe and effective use without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions that arguments must be 'compact, single-line JSON' and require 'full workflow structure including nodes and connections arrays', adding context beyond the schema. However, it doesn't explain what 'clientId' or 'name' represent, or the structure of 'nodes' and 'connections', leaving key parameters semantically unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new workflow') and resource ('in n8n'), specifying it's for setting up workflows with optional nodes and connections. It distinguishes from siblings like 'update-workflow' or 'delete-workflow' by focusing on creation, though it doesn't explicitly contrast with 'init-n8n' which might handle initial setup differently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., after 'init-n8n'), contrast with 'update-workflow' for modifications, or specify use cases beyond 'set up a new workflow', leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions an access restriction ('Only available for the instance owner'), which is useful, but lacks details on return format, pagination, rate limits, or error handling. This is insufficient for a tool with potential complexity in user data retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by a critical restriction. Every word adds value without redundancy, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 1 undocumented parameter, the description is incomplete. It covers the purpose and access restriction but misses details on behavior, parameters, and return values, which are essential for effective tool use in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, and the tool description provides no information about the 'clientId' parameter. This leaves the parameter's meaning, format, or purpose completely undocumented, failing to compensate for the low 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 states the verb ('Retrieve') and resource ('all users from your instance'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-user' (singular) or 'create-users', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context by stating 'Only available for the instance owner', which indicates when to use it based on permissions. However, it doesn't explicitly mention when not to use it or name alternatives like 'get-user' for single-user retrieval, preventing a score of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the requirement for 'compact, single-line JSON' arguments, which is useful behavioral context. However, it lacks details on permissions, rate limits, pagination, or what the output looks like (e.g., list format, fields included). For a read operation with no annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, followed by important usage and formatting notes. Every sentence adds value: the first states what it does and when to use it, the second provides critical input formatting guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, and no output schema, the description is moderately complete. It covers purpose, prerequisites, and input formatting but misses parameter details, output behavior, and operational constraints. For a simple list tool, it's adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'Arguments must be provided as compact, single-line JSON' but doesn't explain the 'clientId' parameter's purpose, format, or where to obtain it. With one undocumented parameter, the description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'all workflows from n8n', making the purpose specific and understandable. It distinguishes from siblings like 'get-workflow' (singular) by indicating it retrieves multiple workflows. However, it doesn't explicitly differentiate from other list tools like 'list-executions' or 'list-projects' 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context with 'Use after init-n8n to see available workflows', giving a prerequisite and timing guidance. It doesn't explicitly state when not to use it or name alternatives, but the sibling tools include 'get-workflow' for single workflows, which is implied by the plural vs. singular naming.
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. It mentions the creation action but doesn't disclose behavioral traits like authentication requirements, rate limits, whether credentials are stored securely, or what happens on failure. It only provides procedural guidance about using get-credential-schema first.
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?
Two sentences that are well-structured and front-loaded with the main purpose. The second sentence provides important procedural guidance. No wasted words, though it could be slightly more concise by integrating the examples more smoothly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter creation tool with no annotations and no output schema, the description provides adequate purpose and usage guidance but lacks details about authentication requirements, error handling, and complete parameter documentation. It's minimally viable but has clear gaps in behavioral transparency and parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions the 'type' parameter with examples and implies 'data' contains credential fields, but doesn't explain 'clientId' or 'name' parameters. The description adds some meaning for 'type' and 'data' but leaves 'clientId' and 'name' completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a credential for nodes of a specified type, with specific examples of credential types. It distinguishes from siblings like delete-credential and get-credential-schema by focusing on creation. However, it doesn't explicitly contrast with other creation tools like create-project or create-workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: after using get-credential-schema to see required fields. It also specifies the context (credential type names from n8n UI) and implies not to use it without first checking schema 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the IMPORTANT formatting requirement for arguments, which is valuable behavioral context. However, it doesn't describe what 'detailed information' includes, whether authentication is needed, rate limits, error conditions, or response format. For a read operation with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two sentences, both of which earn their place. The first sentence states the core purpose, the second provides usage guidance and a critical formatting requirement. No wasted words or redundant 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 no annotations, 0% schema description coverage, and no output schema, the description is incomplete. While it provides good purpose and usage guidance, it lacks information about what 'detailed information' the tool returns, authentication requirements, error handling, and the semantics of the two required parameters. For a tool that presumably returns structured workflow data, this leaves too many gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description mentions 'workflow by ID' which implies the 'id' parameter, but doesn't explain what 'clientId' represents or how these parameters relate. It adds minimal semantic value beyond what's obvious from the parameter names themselves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieve' and resource 'workflow by ID', making the purpose unambiguous. It distinguishes from sibling tools like 'list-workflows' by focusing on a single workflow rather than listing multiple. However, it doesn't explicitly differentiate from other get-* tools like 'get-execution' or 'get-user' 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use after list-workflows to get detailed information about a specific workflow.' This clearly indicates when to use this tool versus the sibling 'list-workflows' tool, establishing a logical sequence of operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses behavioral traits such as the license requirement and input format constraint ('Arguments must be provided as compact, single-line JSON'). However, it doesn't cover other aspects like error handling, response format, or mutation effects beyond creation. This adds some value but is incomplete for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by important notes in two concise sentences. Every sentence adds value: the first states the action, the second specifies prerequisites, and the third details input requirements. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides some context like license needs and input format, but lacks details on return values, error cases, or full parameter meanings. For a creation tool with 2 parameters, this is minimally adequate but has clear gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'Arguments must be provided as compact, single-line JSON' which adds context about parameter format, but doesn't explain the semantics of 'clientId' and 'name' parameters. This partial compensation is insufficient given the low 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 states the verb 'Create' and the resource 'new project in n8n', making the purpose evident. However, it doesn't explicitly differentiate this from sibling tools like 'update-project' or 'delete-project', though the action is distinct by name. The description is specific but lacks sibling comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context for when to use this tool by stating 'Requires n8n Enterprise license with project management features enabled', which acts as a prerequisite. It doesn't mention alternatives like 'update-project' or exclusions, but the license requirement gives clear usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds important context about licensing requirements and input formatting ('Arguments must be provided as compact, single-line JSON'), which are not inferable from the schema. However, it lacks details on pagination, rate limits, error handling, or what the output looks like, leaving gaps for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by essential notes in two concise sentences. Every sentence adds value: the first states the action, the second covers prerequisites, and the third specifies input formatting. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and low schema coverage, the description is incomplete. It covers licensing and formatting but misses parameter explanations, output details, and behavioral traits like pagination. For a list tool with one required parameter, this leaves significant gaps, though the prerequisites are adequately addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, and the tool description does not explain what 'clientId' means, its format, or how it affects the listing. The description only mentions argument formatting without clarifying parameter semantics, failing to compensate for the low 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 states the verb ('List') and resource ('all projects from n8n'), making the purpose explicit. It distinguishes itself from siblings like 'get-workflow' or 'list-users' by specifying projects, though it doesn't explicitly contrast with similar list operations like 'list-workflows' or 'list-tags'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool by stating the prerequisite: 'Requires n8n Enterprise license with project management features enabled.' This helps the agent avoid invoking it inappropriately. However, it does not specify when to use alternatives like 'get-workflow' or 'list-workflows' for non-project resources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It covers licensing requirements and input format constraints ('Arguments must be provided as compact, single-line JSON'), which are valuable behavioral traits. However, it doesn't describe what happens on success/failure, whether the operation is idempotent, or any rate limits - leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with three sentences that each serve distinct purposes: tool purpose, prerequisites/context, and technical requirements. It's front-loaded with the core functionality and avoids unnecessary verbiage, though the technical note about JSON formatting could be slightly more integrated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 parameters, 0% schema coverage, and no output schema, the description does reasonably well by covering prerequisites and format requirements. However, it lacks details about return values, error conditions, and parameter meanings - leaving the agent with incomplete operational understanding despite the clear purpose.
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 0% schema description coverage, the description doesn't explain any of the 3 parameters (clientId, key, value). The baseline would be lower, but the description compensates somewhat by specifying the JSON format requirement for all arguments. However, it doesn't clarify what each parameter represents or their relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new variable') and resource ('in n8n'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list-variables' or 'delete-variable' beyond the obvious action difference, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('Variables can be used across workflows to store and share data') and includes important prerequisites ('Requires n8n Enterprise license with variable management features enabled'). It doesn't explicitly state when NOT to use it or name alternatives like 'update-variable' (which doesn't exist in siblings), but the context is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It reveals important behavioral traits: the destructive nature (implied by 'Delete'), licensing requirements, and input format constraints. However, it doesn't disclose whether deletion is permanent/reversible, what happens to associated resources, or error conditions.
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 appropriately sized with three sentences that each serve distinct purposes: stating the core function, specifying prerequisites, and providing technical constraints. It's front-loaded with the main purpose, though the technical formatting note could potentially be moved to a separate section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description provides adequate but incomplete context. It covers licensing requirements and input format, but lacks crucial information about the deletion's permanence, what gets deleted along with the project, and what the response contains. The absence of output schema increases the need for return value explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 2 required parameters, the description fails to add meaningful parameter semantics. It mentions 'Arguments must be provided as compact, single-line JSON' but doesn't explain what 'clientId' and 'projectId' represent, their format, or how to obtain them. The description doesn't compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Delete') and resource ('project by ID'), distinguishing it from sibling tools like 'delete-workflow', 'delete-user', or 'delete-tag' which target different resources. It provides unambiguous purpose without being tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Delete a project by ID') and includes important prerequisites ('Requires n8n Enterprise license with project management features enabled'), providing clear context. However, it doesn't specify when NOT to use it or mention alternatives like 'update-project' for modification instead of deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool establishes a connection, which implies a stateful setup operation, but doesn't mention behavioral traits like authentication requirements (though implied by API key), error handling, or persistence of the connection. The IMPORTANT note about JSON formatting adds useful operational context, but overall disclosure is basic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by usage guidance and a critical formatting note. Every sentence earns its place: the first defines the tool, the second specifies when to use it, and the third provides essential input instructions. It's appropriately sized with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a setup operation with 2 parameters), no annotations, and no output schema, the description is minimally adequate. It covers the purpose, usage trigger, and input format, but lacks details on what the connection enables, error scenarios, or output expectations. For a foundational tool, more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters with 0% description coverage, so the description must compensate. It implicitly explains the parameters by stating 'n8n URL and API key are shared,' which maps to 'url' and 'apiKey.' This adds meaning beyond the bare schema types. However, it doesn't detail format expectations (e.g., URL structure, API key format), keeping it from a perfect 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?
The description clearly states the tool's purpose: 'Initialize connection to n8n instance.' It specifies the verb ('Initialize') and resource ('connection to n8n instance'), making it distinct from sibling tools that perform CRUD operations on workflows, users, tags, etc. However, it doesn't explicitly differentiate from potential alternative connection methods, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'whenever an n8n URL and API key are shared to establish the connection.' This gives a specific trigger (URL and API key availability) and implies it's a prerequisite for other operations. It doesn't explicitly state when not to use it or name alternatives, but the context is sufficiently clear for a setup tool.
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. While it states what the tool does, it doesn't describe important behavioral aspects like whether this is a read-only operation, what the output format looks like, potential error conditions, or authentication requirements. The description is functional but lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first states the core purpose, the second provides practical guidance with examples. Every sentence adds value, and the information is front-loaded with the main functionality stated immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters, no annotations, and no output schema, the description provides adequate functional context but lacks operational details. It explains what the tool does and provides parameter guidance, but doesn't cover output format, error handling, or authentication requirements that would be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining the meaning of 'credentialTypeName' with examples and context about where to find these names. However, it doesn't explain the 'clientId' parameter at all, leaving one of the two required parameters undocumented in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('show credential data schema') and resource ('for a specific credential type'). It distinguishes from siblings like 'create-credential' by focusing on schema inspection rather than credential creation, and provides concrete examples of credential types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when you need to see what fields are required for creating credentials of a specific type. It mentions where to find credential type names (n8n UI), but doesn't explicitly state when NOT to use it or name specific alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates critical behavioral traits: the destructive nature ('cannot be undone') and a specific technical requirement (compact JSON formatting). This goes beyond what the input schema provides, though it doesn't cover aspects like error conditions or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: the first sentence states the core purpose, the second adds critical behavioral warning, and the third provides essential technical guidance. Every sentence earns its place with zero wasted words, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description does well on behavioral transparency but leaves gaps. It doesn't explain what happens after deletion (e.g., confirmation message, error responses), doesn't clarify parameter roles, and doesn't mention dependencies or permissions. It's minimally adequate but incomplete given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'ID' but doesn't specify which parameter corresponds to the workflow ID versus clientId. With 0% schema description coverage and two required parameters, the description fails to add meaningful semantic context beyond implying one parameter is an ID. It doesn't explain what 'clientId' represents or how parameters relate to the deletion operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Delete') and resource ('a workflow by ID'), distinguishing it from sibling tools like 'deactivate-workflow' or 'delete-project'. It uses precise language that leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to delete a workflow by ID) and implicitly distinguishes it from alternatives like 'deactivate-workflow' by emphasizing permanence ('cannot be undone'). However, it lacks explicit guidance on when NOT to use it or detailed prerequisites beyond the ID requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions license requirements and input formatting, which are useful behavioral traits. However, it doesn't describe the return format (e.g., list structure, pagination), error handling, or performance characteristics, leaving gaps for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by critical notes in a logical order (prerequisites, usage sequence, technical details). Each sentence adds essential value without redundancy, making it highly efficient and well-structured for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple list operation), no annotations, and no output schema, the description is reasonably complete. It covers purpose, prerequisites, usage context, and input formatting. However, it lacks details on output structure and error cases, which would be beneficial for full contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description does not explain the 'clientId' parameter at all, leaving its purpose and format unspecified. However, since there is only one parameter, the baseline is 4, but the lack of any semantic information reduces it to 3, as the description fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'all variables from n8n', making the purpose specific and unambiguous. It distinguishes itself from sibling tools like 'create-variable' and 'delete-variable' by focusing on retrieval rather than modification, and from 'get-variable' (which doesn't exist in the list) by implying a bulk operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it states prerequisites ('Requires n8n Enterprise license with variable management features enabled'), a recommended sequence ('Use after init-n8n to see available variables'), and technical constraints ('Arguments must be provided as compact, single-line JSON without whitespace or newlines'). This covers when to use it, dependencies, and how to format inputs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates critical traits: the action is irreversible ('This action cannot be undone'), and there are specific input formatting requirements ('Arguments must be provided as compact, single-line JSON without whitespace or newlines'). However, it does not mention potential side effects, error conditions, or response format, leaving some behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by important notes and requirements. Each sentence serves a distinct purpose: stating the action, noting prerequisites, guiding usage, warning about irreversibility, and specifying input format. There is no redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a destructive operation with no annotations and no output schema, the description does well by covering key aspects like prerequisites, usage context, and irreversibility. However, it lacks details on error handling, response structure, or what happens to dependent resources, which would be valuable for a deletion 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?
The input schema has 0% description coverage, so the description must compensate. It mentions 'ID' as a parameter, which aligns with the 'id' property in the schema, but does not explain the 'clientId' parameter or provide any additional semantic context for either parameter. The baseline is 3 because the description adds minimal value beyond the schema's structural information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a variable by ID'), making the purpose specific and unambiguous. It distinguishes from sibling tools like 'list-variables' and 'create-variable' by focusing on deletion rather than listing or creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'Use after list-variables to get the ID of the variable to delete.' It also mentions prerequisites ('Requires n8n Enterprise license with variable management features enabled'), which helps the agent understand necessary conditions before invocation.
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/fellipesaraiva88/n8n-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/fellipesaraiva88/n8n-mcp-server)

Score Badge

Copy to your README.md:

[![n8n-mcp-server MCP server](https://glama.ai/mcp/servers/fellipesaraiva88/n8n-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/fellipesaraiva88/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/fellipesaraiva88/n8n-mcp-server'

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