Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover key traits (readOnlyHint=false, destructiveHint=false, idempotentHint=true), so the description doesn't need to repeat these. It adds value by explaining the purpose ('run automatically based on its triggers'), but lacks details on side effects (e.g., enabling triggers), error conditions, or rate limits. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose in the first sentence, followed by structured Args and Returns sections. It's efficient with minimal waste, though the Args/Returns formatting could be more integrated into natural language for better flow.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (activation operation), rich annotations, and no output schema, the description is adequate but incomplete. It explains what activation does but omits details like return format (beyond 'The activated workflow'), error handling, or dependencies on workflow state, leaving gaps for an agent to infer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with the parameter 'id' documented as 'The unique identifier of the resource'. The description adds no extra meaning beyond this, such as format examples or where to find the ID. Baseline 3 is appropriate since the schema already provides adequate parameter information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Activate a workflow') and the outcome ('so it can run automatically based on its triggers'), which is specific and meaningful. However, it doesn't explicitly differentiate from its sibling 'n8n_deactivate_workflow' beyond the obvious opposite action, missing an opportunity to clarify the distinction in behavior or context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, such as 'n8n_run_workflow' for manual execution or 'n8n_deactivate_workflow' for stopping automation. It lacks context on prerequisites (e.g., workflow must exist and be deactivated) or typical scenarios for activation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare this as read-only, non-destructive, and idempotent. The description adds valuable context: it specifies what is being verified (API key validity and instance reachability) and describes the return structure (connected status and error message). This goes beyond the annotations by explaining the actual verification behavior and output format.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is perfectly front-loaded with the core purpose in the first sentence. The second sentence elaborates on what is verified, and the third clearly outlines the return values. Every sentence adds essential information with zero waste or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (0 parameters, no output schema), the description is nearly complete. It explains the purpose, verification details, and return structure. The only minor gap is the lack of usage guidelines, but for a straightforward connection test, the description provides sufficient context for an agent to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are 0 parameters, and schema description coverage is 100% (empty schema). The description correctly indicates no parameters are needed ('Test the connection' implies no inputs). A baseline of 4 is appropriate for zero-parameter tools, as no additional parameter semantics are required.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Test the connection', 'Verifies that the API key is valid and the n8n instance is reachable'), identifies the resource ('n8n instance'), and distinguishes it from all sibling tools which perform CRUD operations on workflows, credentials, executions, etc. This is a distinct diagnostic tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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., should this be run before other operations?), typical scenarios (e.g., after configuration changes), or what to do if the check fails. Usage is implied but not explicitly stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate this is not read-only, idempotent, or destructive, which the description aligns with by implying creation (a write operation). The description adds valuable context: it specifies that sensitive data is not returned, mentions dependency on another tool for schema details, and lists common credential types, enhancing transparency beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections for Args, Common credential types, and Returns, making it easy to scan. It is appropriately sized with no redundant sentences, though it could be slightly more front-loaded by moving the 'Args' section after the initial statement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 3 parameters, 100% schema coverage, no output schema, and annotations covering basic hints, the description is mostly complete. It explains parameter dependencies, references another tool for details, and describes the return value. However, it lacks information on error handling or authentication requirements, leaving minor gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the baseline is 3. The description adds significant value by explaining that 'type' requires using n8n_get_credential_schema for exact fields, listing common types with examples (e.g., slackApi: { accessToken }), and noting that 'data' fields depend on type, providing practical guidance beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Create' and resource 'credential', specifying it's a 'new credential'. It distinguishes from siblings like n8n_update_credential (update) and n8n_delete_credential (delete), making the purpose specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly provides when to use this tool: 'Create a new credential.' It also names an alternative tool (n8n_get_credential_schema) for obtaining required fields, and lists common credential types to guide usage. This gives clear context and exclusions (e.g., not for updating or deleting).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, non-openWorld operation, covering basic behavioral traits. The description adds that it creates a project 'for organizing workflows and credentials,' providing some context about the project's purpose, but doesn't elaborate on permissions, rate limits, or creation constraints beyond what annotations imply.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose in the first sentence, followed by structured Args and Returns sections. It's efficient with minimal waste, though the Args section could be omitted since it duplicates schema info without added value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a creation tool with annotations covering safety and no output schema, the description is minimally adequate. It states what is created and the single parameter, but lacks details on return values (only mentions 'The created project' vaguely) and doesn't address potential errors or project limits, leaving gaps in completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, with the 'name' parameter fully documented in the schema. The description repeats 'Project name' in the Args section but adds no additional semantic context (e.g., naming conventions, uniqueness requirements). Baseline 3 is appropriate given high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 project') and the resource ('for organizing workflows and credentials'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'n8n_update_project' or 'n8n_list_projects', 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'n8n_update_project' or 'n8n_list_projects', nor does it mention prerequisites or context for creating a project. It simply states what the tool does without usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate this is a non-readOnly, non-destructive, non-idempotent, non-openWorld operation, which the description aligns with by implying creation (not reading or deleting). The description adds minimal behavioral context beyond annotations—it mentions the tag's purpose ('organizing workflows') but doesn't cover permissions, rate limits, or what happens on duplicate names. No contradiction with annotations exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose in the first sentence, followed by structured 'Args' and 'Returns' sections. It avoids redundancy, but the 'Args' section slightly repeats schema information without adding value, preventing a perfect score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (1 parameter, 100% schema coverage, no output schema), the description is adequate but minimal. It explains what the tool does and the return value ('The created tag'), but lacks details on error cases, idempotency, or integration with other tools (e.g., how tags relate to workflows), leaving some contextual gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description briefly mentions the 'name' parameter and its constraint ('max 24 characters'), but the input schema already provides full coverage (100%) with identical details. No additional semantic context is added, such as naming conventions or uniqueness requirements, keeping it at the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 tag') and purpose ('for organizing workflows'), making the tool's function immediately understandable. It distinguishes from siblings like 'n8n_update_tag' and 'n8n_delete_tag' by specifying creation rather than modification or deletion. However, it doesn't explicitly contrast with 'n8n_get_tag' or 'n8n_list_tags' for read operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing existing workflows to tag), when not to use it (e.g., if a tag already exists), or how it relates to sibling tools like 'n8n_update_workflow_tags' for applying tags to workflows.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds useful context about how variables are used in workflows ($vars.variableName syntax), which isn't covered by annotations. However, it doesn't mention potential side effects, permissions needed, or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is perfectly structured and front-loaded: purpose statement first, then usage context, followed by parameter details. Every sentence earns its place, with zero wasted words. The three-part structure (purpose, usage, parameters) is efficient and logical.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a creation tool with good annotations and full schema coverage, the description provides adequate context. It explains the purpose, usage syntax, and parameters. The main gap is the lack of output schema, but the description does mention 'Returns: The created variable,' which partially compensates. A complete output description would make it a 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both parameters (key and value) fully documented in the schema. The description's 'Args' section repeats the schema information without adding additional semantic meaning. The baseline of 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Create a new environment variable') and the resource ('environment variable'), distinguishing it from sibling tools like n8n_update_variable or n8n_delete_variable. It provides immediate clarity about what this tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context about when to use this tool ('Variables can be used in workflows with $vars.variableName syntax'), giving practical application guidance. However, it doesn't explicitly state when NOT to use it or mention alternatives like n8n_update_variable for modifying existing variables.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate this is a non-readonly, non-destructive, non-idempotent creation operation. The description adds minimal behavioral context beyond this—it mentions the return value ('assigned ID') but doesn't cover error conditions, rate limits, or authentication requirements. It doesn't contradict annotations, but adds limited value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (Args, Returns, Example node types) and avoids unnecessary verbosity. However, the 'Example node types' section is lengthy and could be condensed or moved to a separate reference, as it lists many examples without explaining their use cases.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (6 parameters with nested objects) and lack of output schema, the description is moderately complete. It covers the basic creation process and return value but lacks details on error handling, validation rules (e.g., node type compatibility), or how 'connections' should be structured. The annotations provide safety context, but more behavioral guidance would help.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the schema fully documents all 6 parameters. The description adds some semantic clarification by listing example node types and noting that 'name' is required, but this is largely redundant with the schema. It doesn't explain complex structures like 'connections' mapping or 'settings' options beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Create a new workflow in n8n') and distinguishes it from sibling tools like 'n8n_update_workflow', 'n8n_duplicate_workflow', and 'n8n_import_workflow'. It specifies the exact resource being created (a workflow) with no ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'n8n_import_workflow' (for importing existing workflows) or 'n8n_duplicate_workflow' (for copying). It also doesn't mention prerequisites, such as whether the user needs specific permissions or if certain node types require credentials.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate this is a non-destructive, idempotent mutation (readOnlyHint=false, destructiveHint=false, idempotentHint=true). The description adds that it 'stops automatic execution,' which provides useful behavioral context beyond annotations. However, it doesn't mention potential side effects, permissions needed, or what 'deactivated' means for manual triggers.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured with a clear purpose statement followed by Args and Returns sections. Every sentence earns its place: the first explains what the tool does, and the subsequent lines provide essential parameter and return information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (a single-parameter mutation), rich annotations (covering safety and idempotency), and no output schema, the description is mostly complete. It explains the action and return value, but could improve by clarifying the state change (e.g., whether deactivation affects manual triggers or webhooks).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with the parameter 'id' fully documented in the schema. The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3. The description does not compensate for any gaps because there are none.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('deactivate'), the resource ('workflow'), and the effect ('stop it from running automatically'). It distinguishes from sibling tools like 'n8n_activate_workflow' by specifying the opposite operation, and from 'n8n_delete_workflow' by indicating this stops execution rather than removing the workflow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context ('to stop it from running automatically') but doesn't explicitly state when to use this versus alternatives like 'n8n_stop_execution' (for active runs) or 'n8n_delete_workflow' (for removal). It mentions the purpose but lacks explicit guidance on prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds crucial behavioral context beyond annotations: the warning about breaking workflows provides specific risk information that annotations (destructiveHint=true) only imply generally. However, it doesn't mention idempotent behavior (covered by idempotentHint=true) or other operational details like 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is perfectly structured: warning first, then clear parameter documentation, then return information. Every sentence serves a distinct purpose with zero wasted words. The formatting with emoji and sections enhances readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive operation with good annotations, the description provides excellent risk context and clear parameter/return documentation. The only minor gap is lack of output details (no schema), but the 'Confirmation of deletion' statement provides adequate guidance for this simple operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the input schema already fully documents the single parameter. The description adds minimal value by restating 'Credential ID to delete' but doesn't provide additional context about ID format, sourcing, or validation beyond what's in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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'), distinguishing it from sibling tools like 'n8n_get_credential' or 'n8n_update_credential'. It specifies the exact operation without ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The warning provides explicit guidance on when NOT to use this tool ('This will break any workflows using this credential!'), helping the agent avoid destructive actions when dependencies exist. It distinguishes this from safer alternatives like viewing or updating credentials.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds valuable behavioral context beyond annotations: the explicit warning '⚠️ WARNING: This action cannot be undone!' emphasizes the destructive nature, which annotations already indicate with destructiveHint=true. It also specifies the return value ('Confirmation of deletion'), which isn't covered by annotations. However, it doesn't mention idempotency (covered by idempotentHint=true) or other traits like rate limits or authentication needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose, followed by a critical warning, then structured Arg/Return sections. Every sentence earns its place: the first states the action, the warning highlights risk, and the bullet points clarify input/output without fluff. It's appropriately sized for a single-parameter destructive operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (destructive mutation with one parameter), annotations cover safety and idempotency, and schema fully documents the input. The description adds the irreversibility warning and return value note, compensating for the lack of output schema. However, it misses usage context (e.g., relationship with sibling tools), leaving a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with the parameter 'id' fully documented in the schema as 'The unique identifier of the resource'. The description adds minimal value by restating 'Execution ID to delete', which is redundant with the schema. Baseline 3 is appropriate since the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 target resource ('a specific execution by ID'), distinguishing it from sibling tools like 'n8n_delete_executions' (plural) and 'n8n_stop_execution' (which halts rather than removes). The verb+resource combination is precise and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 the execution ID from 'n8n_get_execution' or 'n8n_list_executions'), nor does it differentiate from similar tools like 'n8n_delete_executions' (bulk deletion) or 'n8n_stop_execution' (halting active executions). The warning about irreversibility is a safety note, not usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate destructiveHint=true, but the description adds critical behavioral context with the explicit warning '⚠️ WARNING: This action cannot be undone! Use with caution.' This goes beyond annotations by emphasizing irreversible consequences and caution needed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with warning, parameter list, and return statement. It's appropriately sized, though the Args section duplicates schema information. Every sentence adds value, particularly the warning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive bulk deletion tool with good annotations and full schema coverage, the description provides adequate context. The warning addresses the critical behavioral risk, though it could mention prerequisites (like permissions) or clarify that parameters are optional filters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with each parameter clearly documented in the schema. The description's Args section repeats schema information without adding meaningful semantic context beyond what's already in structured fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Delete') and resource ('multiple executions'), specifying it's a bulk operation. It distinguishes from sibling 'n8n_delete_execution' (singular) by emphasizing bulk deletion based on filters.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The warning provides cautionary context, but there's no explicit guidance on when to use this vs. alternatives like 'n8n_delete_execution' (singular deletion) or 'n8n_list_executions' (for viewing). Usage is implied through parameter descriptions rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds valuable behavioral context beyond annotations: the warning explicitly states that deletion affects all workflows and credentials in the project, which is crucial information not covered by the destructiveHint annotation alone. It doesn't contradict annotations (destructiveHint=true aligns with 'Delete'), and adds meaningful 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is perfectly structured: a clear purpose statement, prominent warning, and organized Args/Returns sections. Every sentence earns its place, with the warning being particularly valuable for a destructive operation. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive operation with clear annotations and a simple parameter schema, the description provides excellent completeness. The warning about cascading effects addresses the most critical contextual information, and the confirmation of return value is adequate without an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the schema already fully documents the single 'id' parameter. The description adds minimal value beyond the schema by restating 'Project ID to delete' in the Args section, but doesn't provide additional semantic context about format, sourcing, or constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 project'), distinguishing it from sibling tools like n8n_delete_workflow or n8n_delete_credential by specifying it affects the entire project container. The warning about workflows and credentials further clarifies the scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context about when to use this tool (to delete a project) and implicitly distinguishes it from other delete operations through the warning about affected resources. However, it doesn't explicitly state when NOT to use it or name specific alternatives like deleting individual workflows instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds valuable context beyond annotations: it specifies that deletion requires a tag ID and returns a confirmation. Annotations already indicate destructiveHint=true (irreversible change) and idempotentHint=true (safe to retry), but the description clarifies the confirmation response. It doesn't mention permissions, rate limits, or error cases, but provides useful operational details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded: the first sentence 'Delete a tag.' clearly states the purpose. The Args/Returns sections are structured but could be more integrated. There's no wasted text, though the parameter description is slightly redundant with the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with no output schema, the description is minimally adequate. It covers the basic operation and response but lacks details on error handling, permissions, or dependencies. Annotations provide safety hints, but the description doesn't fully compensate for the missing output schema or contextual nuances given the tool's irreversible nature.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with the parameter 'id' fully documented in the schema as 'The unique identifier of the resource'. The description adds minimal value by restating 'Tag ID to delete', which is redundant with the schema. No additional syntax, format, or constraints are provided beyond what the schema already covers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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'), making the purpose immediately understandable. It distinguishes from siblings like 'n8n_update_tag' or 'n8n_get_tag' by specifying deletion rather than modification or retrieval. However, it doesn't explicitly differentiate from other deletion tools like 'n8n_delete_workflow' or 'n8n_delete_project' beyond the resource type.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 the tag ID from 'n8n_get_tag' or 'n8n_list_tags'), consequences of deletion, or when not to use it (e.g., if the tag is in use). With siblings like 'n8n_update_tag' available, there's no comparison or context for choosing deletion over modification.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate destructiveHint=true and idempotentHint=true, but the description adds valuable context with the warning about breaking workflows, which is not covered by annotations. It does not mention other behavioral traits like authentication needs or rate limits, but the added warning compensates well.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action, includes a critical warning, and efficiently lists args and returns in a structured format. Every sentence serves a clear purpose without redundancy, making it highly concise and well-organized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with no output schema, the description provides essential context like the warning and confirmation of deletion, which helps the agent understand the impact. However, it lacks details on error handling or specific return format, leaving some gaps in completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, so the input schema fully documents the 'id' parameter. The description adds minimal semantics by stating 'Variable ID to delete', which slightly reinforces the schema but does not provide additional details like format or examples.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 variable'), distinguishing it from sibling tools like n8n_get_variable, n8n_create_variable, and n8n_update_variable. The title reinforces this with 'Delete n8n Variable', making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes a warning about workflows breaking, which provides clear context for when to use this tool cautiously. However, it does not explicitly mention alternatives like n8n_update_variable or specify when not to use it, such as for read-only operations handled by n8n_get_variable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate destructiveHint=true and idempotentHint=true, but the description adds valuable context with the explicit warning 'This action cannot be undone!' and clarifies the return value ('Confirmation of deletion'). This enhances transparency beyond what annotations provide without contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear purpose statement, warning, and separate Args/Returns sections. It's appropriately sized but could be slightly more concise by integrating the warning into the main sentence without losing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with good annotations and a simple parameter schema, the description is mostly complete. It covers the irreversible nature and return confirmation, though it could benefit from mentioning idempotency or error cases, but annotations help fill some gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with the parameter 'id' already documented as 'The unique identifier of the resource'. The description adds no additional semantic information about the parameter beyond restating it in the Args section, meeting the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('permanently delete') and resource ('workflow'), distinguishing it from siblings like n8n_deactivate_workflow or n8n_delete_execution. It uses specific 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a warning about irreversibility, which implies when to be cautious, but doesn't explicitly state when to use this tool versus alternatives like n8n_deactivate_workflow or n8n_delete_executions. No prerequisites or specific usage contexts are mentioned beyond the warning.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate this is a non-readOnly, non-destructive, non-idempotent mutation tool. The description adds that it 'create[s] a copy' and returns 'the duplicated workflow with its new ID', providing useful context about the creation behavior and return structure. However, it doesn't mention permissions, rate limits, or side effects beyond what annotations cover.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured with a clear purpose statement followed by parameter and return sections. However, the 'Args' and 'Returns' labels are somewhat redundant given the schema, and the optional parameter's default value could be integrated more seamlessly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 2-parameter mutation tool with full schema coverage and annotations, the description adequately covers purpose, parameters, and return expectations. The lack of output schema is compensated by the return statement. Minor gaps include no error handling or permission context, but overall it's sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both parameters clearly documented in the schema. The description's 'Args' section repeats the schema information without adding meaningful context like ID format examples or naming conventions. Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Create a copy') and resource ('existing workflow'), distinguishing it from siblings like 'n8n_create_workflow' (creates new) and 'n8n_update_workflow' (modifies existing). The verb 'duplicate' is precise and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when needing a copy of an existing workflow, but provides no explicit guidance on when to choose this over alternatives like 'n8n_create_workflow' or 'n8n_import_workflow'. No prerequisites, exclusions, or comparative context are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare this as read-only, non-destructive, idempotent, and closed-world, covering core safety traits. The description adds valuable context by specifying the output format ('Complete workflow JSON that can be imported into another n8n instance'), which helps the agent understand the tool's behavior beyond annotations. However, it doesn't mention potential errors (e.g., invalid ID) or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured with a clear purpose statement, a dedicated 'Args' section listing the single parameter, and a 'Returns' section explaining the output. Every sentence adds value without redundancy, and information is front-loaded for quick comprehension.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, full schema coverage, rich annotations), the description is complete. It explains the purpose, parameters, and return value adequately. No output schema exists, but the description specifies the return format, compensating for that gap. The annotations cover safety, making additional behavioral details less critical.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with the parameter 'id' fully documented in the schema. The description repeats the parameter info in the 'Args' section but adds no additional meaning beyond what the schema provides (e.g., format examples or constraints). This meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Export a workflow as JSON') and resource ('workflow'), distinguishing it from siblings like 'n8n_get_workflow' (which likely returns metadata) and 'n8n_import_workflow' (the inverse operation). It explicitly mentions the purpose ('for backup or import elsewhere'), making the intent unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 ('for backup or import elsewhere'), but does not explicitly state when not to use it or name alternatives. For example, it doesn't contrast with 'n8n_get_workflow' (if that returns different data) or mention prerequisites like needing an existing workflow ID.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds valuable context about what the tool generates (audit report with risk levels and issues by category) and mentions the 'daysAbandonedWorkflow' parameter which suggests time-based analysis behavior. This provides useful behavioral insight beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (purpose, args, returns). It's appropriately sized with no redundant information. Every sentence serves a purpose, though the parameter listing in the description slightly duplicates schema information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only tool with comprehensive annotations and full schema coverage, the description provides adequate context. It explains the output format (audit report with risk levels and issues by category) which compensates for the lack of output schema. The tool's purpose and return value are clearly communicated given its complexity level.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both parameters well-documented in the schema. The description adds minimal value beyond the schema: it lists the category options (already in the enum) and mentions 'daysAbandonedWorkflow' but doesn't provide additional semantic context. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Generate a security audit report') and resource ('for the n8n instance'), distinguishing it from sibling tools that focus on workflows, credentials, projects, etc. It provides a precise verb+resource combination that immediately communicates the tool's function.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context (security auditing of an n8n instance) but doesn't explicitly state when to use this tool versus alternatives. It doesn't mention prerequisites, dependencies, or compare with other audit-related tools (none exist in siblings). The guidance is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide strong behavioral hints: readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds value by specifying that it returns 'List of active webhooks with their paths and associated workflows,' which clarifies the output content beyond the annotations. However, it does not disclose additional traits like rate limits, authentication needs, or error conditions, leaving some behavioral aspects uncovered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose in the first sentence, followed by a brief output specification. Both sentences are essential: the first defines the tool's action, and the second clarifies what is returned. There is no wasted verbiage or repetition, 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (0 parameters, no output schema), the description is complete enough for an agent to understand its function. Annotations cover safety and idempotency, and the description adds output details. However, it lacks context on usage scenarios or error handling, which could be beneficial but is not strictly necessary for this low-complexity tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description does not need to compensate for missing parameter details, as there are none to explain. It appropriately focuses on the tool's action and output without redundant parameter information, aligning with the baseline for zero parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get a list of all active webhooks in the n8n instance.' It specifies the verb ('Get'), resource ('active webhooks'), and scope ('in the n8n instance'), which is specific and actionable. However, it does not explicitly differentiate from sibling tools like 'n8n_list_workflows' or 'n8n_get_workflow', which might also involve webhook-related data, though the focus on 'active webhooks' is distinct enough for clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 does not mention any prerequisites, such as needing authentication or specific permissions, nor does it compare it to sibling tools like 'n8n_list_workflows' that might list workflows with webhooks. Without explicit when-to-use or when-not-to-use instructions, the agent must infer usage from the purpose alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare this as read-only, non-destructive, and idempotent. The description adds valuable context beyond annotations by explicitly stating that 'Credential data/secrets are NOT returned for security' and specifying the returned metadata fields (id, name, type, timestamps). This provides important behavioral details about data filtering and 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured with a clear purpose statement, parameter documentation in bullet points, and return value explanation with important security warning. Every sentence serves a distinct purpose with zero wasted words, and the security warning is appropriately emphasized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read operation with comprehensive annotations (readOnlyHint, idempotentHint, etc.), 100% schema coverage, and no output schema, the description provides complete context. It clearly explains what the tool does, what it returns (including specific fields and exclusions), and has appropriate security warnings - everything needed for an agent to use this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage (the 'id' parameter is fully documented in the schema), the baseline is 3. The description doesn't add any parameter-specific information beyond what's in the schema, but it doesn't need to since the schema already provides complete parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Get details of a specific credential') and resource ('credential'), distinguishing it from sibling tools like 'n8n_list_credentials' (which lists multiple) and 'n8n_get_credential_schema' (which gets schema information). It explicitly notes the limitation 'without sensitive data' which further clarifies scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context by specifying 'a specific credential' and mentioning what data is excluded, but doesn't explicitly state when to use this versus alternatives like 'n8n_list_credentials' for browsing or 'n8n_get_credential_schema' for schema details. It provides clear context but lacks explicit comparison guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate this is a read-only, idempotent, non-destructive operation. The description adds valuable context by explaining the return value ('JSON schema showing required and optional fields') and the tool's role in the credential creation workflow. It doesn't contradict annotations and provides useful behavioral details beyond what annotations cover.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with the core purpose. It uses three concise sentences: one for the purpose, one for the return value, and one for usage guidance. Every sentence adds value without redundancy, making it efficient and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, 100% schema coverage, rich annotations), the description is complete. It explains the purpose, return format, and usage context. While there's no output schema, the description adequately covers what the tool does and when to use it, making it sufficient for an agent to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, fully documenting the single parameter. The description adds minimal semantic value beyond the schema, only restating the parameter name and providing an example ('e.g., "slackApi", "httpBasicAuth"'). This meets the baseline score of 3 for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get the schema/fields required for a credential type.' It specifies the verb ('Get') and resource ('schema/fields'), and distinguishes it from sibling tools like 'n8n_create_credential' by focusing on schema retrieval rather than creation. The description is specific and avoids tautology.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidance: 'Use this before creating credentials to know what data fields are needed.' This clearly indicates when to use the tool (as a prerequisite for credential creation) and implicitly distinguishes it from alternatives like 'n8n_create_credential' or 'n8n_list_credentials' by focusing on schema discovery.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide strong behavioral hints (read-only, non-destructive, idempotent, closed-world). The description adds valuable context by specifying it returns details of the 'currently authenticated user' and listing the returned fields (id, email, name, role), which helps the agent understand the output format despite no output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences: one stating the purpose and one detailing the return values. Every word serves a purpose, and it's front-loaded with the core functionality.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with comprehensive annotations, 0 parameters, and no output schema, the description is complete. It explains what the tool does, who it targets, and what data it returns, providing sufficient context for an agent to use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0 parameters and 100% schema description coverage, the baseline is 4. The description correctly indicates no parameters are needed by not mentioning any, aligning with the empty input schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get details of the currently authenticated user' with specific resource details (owner of API key). It distinguishes from sibling 'n8n_get_user' by specifying 'current' user, but doesn't explicitly mention this distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context through 'currently authenticated user' and 'owner of the API key,' suggesting it's for identifying the API caller. However, it doesn't provide explicit guidance on when to use this versus 'n8n_get_user' or 'n8n_list_users' from the sibling list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds valuable context beyond annotations by specifying what information is returned (status, timestamps, workflow data, node results) and the conditional inclusion of node outputs based on includeData. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with the core purpose. Every sentence adds value: the first states the action, the Args section clarifies parameters, and the Returns section details output content. No redundant or verbose language.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only tool with good annotations and no output schema, the description is mostly complete: it covers purpose, parameters, and return details. However, it lacks information on error conditions (e.g., what happens if the ID is invalid) and doesn't mention pagination or rate limits, which could be relevant for execution data.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with clear parameter documentation in the schema. The description adds minimal value beyond the schema: it restates the purpose of includeData ('Include full execution data with node outputs') but doesn't provide additional semantic context like examples or edge cases. Baseline 3 is appropriate given high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Get detailed information about a specific execution') and distinguishes it from sibling tools like 'n8n_list_executions' (which lists multiple executions) and 'n8n_delete_execution' (which deletes rather than retrieves). The verb 'Get' is precise and the resource 'execution' is well-defined.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context by specifying 'a specific execution' (requiring an ID), but doesn't explicitly state when to use this versus alternatives like 'n8n_list_executions' for browsing or 'n8n_get_workflow' for workflow metadata. It provides clear prerequisites (needs an execution ID) but lacks explicit exclusion guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide key behavioral hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: false), covering safety and idempotency. The description adds value by specifying the return format ('List of node types with their descriptions and categories') and the scope ('all available node types'), which aren't covered by annotations. However, it doesn't disclose additional traits like rate limits, authentication needs, or performance characteristics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose in the first sentence, followed by return details and usage context in two additional sentences. Every sentence adds value without redundancy, making it efficient and well-structured for quick understanding by an AI agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (0 parameters, no output schema) and rich annotations, the description is complete enough for an agent to use it correctly. It explains what the tool does, what it returns, and when to use it. The lack of an output schema is mitigated by the description detailing the return format, though more specifics on structure could enhance completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose and output. This meets the baseline for tools with no parameters, as it avoids unnecessary detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose as 'Get a list of all available node types in the n8n instance,' which is a specific verb+resource combination. It distinguishes itself from sibling tools by focusing on node types rather than workflows, credentials, or other resources. However, it doesn't explicitly differentiate from potential similar tools like 'get_credential_schema' or 'get_workflow,' though those are clearly different resources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for usage with 'Useful for understanding what nodes are available when creating workflows,' which implicitly suggests using this tool during workflow design. It doesn't explicitly state when not to use it or name alternatives, but the context is sufficient for an agent to infer its role among siblings like 'n8n_create_workflow' or 'n8n_list_workflows.'

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide strong behavioral hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: false). The description adds minimal context beyond this, mentioning it returns 'Project details with id, name, and type,' which gives some insight into output format. It doesn't contradict annotations, but adds only basic behavioral information.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded with the main purpose in the first sentence. The Args and Returns sections are structured but could be more integrated. It avoids unnecessary verbosity, though the parameter listing adds minimal value given the schema coverage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (1 parameter, no output schema), annotations cover safety and idempotency, and schema fully describes the input, the description is reasonably complete. It specifies the tool's purpose and return fields, though it could benefit from more context on usage relative to siblings or error handling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with the parameter 'id' well-documented in the schema as 'The unique identifier of the resource.' The description adds no additional meaning beyond this, merely restating 'id (string): Project ID.' With high schema coverage, the baseline score of 3 is appropriate as the schema handles parameter documentation adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get details of a specific project.' It uses a specific verb ('Get') and resource ('project'), but doesn't explicitly differentiate from sibling tools like 'n8n_list_projects' or 'n8n_get_workflow' which might be used in similar contexts. The purpose is clear but lacks sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'n8n_list_projects' for listing multiple projects or 'n8n_get_workflow' for workflow details, nor does it specify prerequisites or contexts where this tool is appropriate. Usage is implied but not explicitly stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover key traits (read-only, non-destructive, idempotent, closed-world), so the description adds minimal value. It mentions the return format ('Tag details with id and name'), which provides some context beyond annotations, but doesn't elaborate on error handling or permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief and front-loaded with the core purpose, followed by structured Args and Returns sections. However, the Args section is redundant given the schema, and the Returns section could be more informative without an output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read operation with rich annotations and full schema coverage, the description is adequate but minimal. It lacks output details (beyond basic fields) and usage context, which could help an agent handle edge cases or integrate with sibling tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the input schema fully documents the 'id' parameter. The description adds no additional meaning about the parameter, such as format examples or sourcing guidance, so it meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get details') and resource ('a specific tag'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'n8n_get_workflow' or 'n8n_get_project' beyond the resource type, which keeps it from 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'n8n_list_tags' for browsing tags or 'n8n_update_tag' for modifications. It lacks any context about prerequisites 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, and idempotentHint=true, covering safety and idempotency. The description adds minimal behavioral context by specifying the return fields (id, email, name, role), but doesn't disclose additional traits like error conditions, authentication needs, or rate limits. It doesn't contradict annotations, so a baseline 3 is appropriate given the 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded with the main purpose in the first sentence. The Args and Returns sections are structured but could be more integrated; however, they add value without waste. It's efficient but not perfectly streamlined.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (single parameter, read-only operation) and rich annotations, the description is mostly complete. It specifies return fields, which compensates for the lack of an output schema. However, it could improve by clarifying usage relative to siblings. For a simple getter tool, it's adequate but not exhaustive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with the parameter 'id' fully documented in the schema as 'The unique identifier of the resource.' The description adds no additional meaning beyond stating 'User ID' in the Args section, which is redundant. Baseline 3 is correct when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get details of a specific user.' It uses a specific verb ('Get') and resource ('user'), but doesn't explicitly differentiate from sibling tools like 'n8n_get_current_user' or 'n8n_list_users', which would require a 5. The description is accurate and not tautological.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'n8n_get_current_user' (for the authenticated user) or 'n8n_list_users' (for multiple users), nor does it specify prerequisites or exclusions. Usage is implied but not explicitly stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide strong hints (readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=false), covering safety and idempotency. The description adds value by specifying the return format ('Variable details with id, key, and value'), which isn't covered by annotations. However, it doesn't mention potential errors (e.g., if ID doesn't exist) or rate limits, keeping it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise and well-structured: a clear purpose statement followed by Args and Returns sections. Every sentence earns its place, with no wasted words, making it easy to parse and understand quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (1 parameter, no output schema), annotations provide strong behavioral context, and the description adds return format details. It's mostly complete but could improve by mentioning error cases or linking to sibling tools. The lack of output schema is mitigated by the return description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with the 'id' parameter well-documented in the schema ('The unique identifier of the resource'). The description adds minimal semantics beyond this, only restating 'Variable ID' without extra context like format examples or validation rules. This meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get a specific variable by ID.' It specifies the verb ('Get') and resource ('variable'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'n8n_list_variables' or 'n8n_get_workflow', 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'n8n_list_variables' for listing all variables or 'n8n_get_workflow' for other get operations, nor does it specify prerequisites or exclusions. This leaves the agent without context for tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds valuable context about what 'full details' means (nodes, connections, settings, tags, timestamps) and the complete structure returned, which goes beyond what annotations provide. No contradiction with annotations exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured with a clear opening sentence stating the purpose, followed by organized 'Args' and 'Returns' sections. Every sentence adds value without redundancy, making it easy to parse and understand quickly. The formatting enhances readability without unnecessary verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (retrieving detailed workflow data) and rich annotations, the description provides good completeness by detailing the return structure. However, there's no output schema, so the description must fully explain returns, which it does adequately. Minor gaps include lack of error handling or pagination info, but overall it's sufficient for the tool's purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with the parameter 'id' well-documented as 'The unique identifier of the resource.' The description adds no additional parameter semantics beyond what the schema provides, but since schema coverage is complete, the baseline score of 3 is appropriate. The description does not compensate for any gaps because there are none.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Get full details') and resource ('specific workflow including all nodes and connections'), distinguishing it from sibling tools like n8n_list_workflows (which lists workflows) and n8n_get_execution (which gets execution details). The verb 'Get' combined with the detailed scope makes the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when detailed workflow information is needed, but doesn't explicitly state when to use this tool versus alternatives like n8n_list_workflows (for summaries) or n8n_get_execution (for execution data). There's no guidance on prerequisites or when-not-to-use scenarios, leaving usage context somewhat implied rather than explicitly documented.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate this is a non-readOnly, non-destructive operation, which the description aligns with by implying creation ('imports'). It adds minimal behavioral context beyond annotations, such as mentioning the return includes a 'new ID', but doesn't cover error handling, validation, or side effects like overwriting existing workflows.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the main purpose, followed by structured Args and Returns sections. It's efficient with minimal fluff, though the Args details could be slightly condensed as they overlap with schema information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (importing JSON with nested objects) and lack of output schema, the description is adequate but incomplete. It explains the input and return value but misses details on error cases, validation rules, or how it interacts with existing workflows, which could aid the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents the parameter. The description adds some semantics by detailing the JSON structure (name, nodes, connections, settings), but this is redundant with the schema's 'additionalProperties' and doesn't provide extra syntax or format details, meeting the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Import a workflow from JSON') and specifies the resource ('workflow'), which is distinct from siblings like 'create_workflow' or 'export_workflow'. However, it doesn't explicitly differentiate from 'duplicate_workflow' or 'transfer_workflow', which might involve similar import-like operations, keeping it from 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.

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_workflow' or 'duplicate_workflow'. The description lacks context about prerequisites, such as needing valid JSON or when import is preferred over creation, leaving the agent without usage direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds valuable context beyond annotations: it explicitly states that credential data/secrets are NOT included for security, which is crucial behavioral information not captured in annotations. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (Args, Returns), uses bullet points efficiently, and every sentence adds value. The security warning is appropriately placed and concise. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only list tool with comprehensive annotations (readOnlyHint, idempotentHint, etc.) and 100% schema coverage, the description provides complete context. It explains what's returned, what's excluded (sensitive data), and includes parameter examples. No output schema exists, but the Returns section adequately describes the response.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents all parameters. The description adds minimal value beyond the schema: it provides examples for the 'type' parameter ('slackApi', 'httpBasicAuth') and clarifies the default for 'limit', but these are minor enhancements. Baseline 3 is appropriate when schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 credentials'), specifies what is excluded ('without sensitive data'), and distinguishes from siblings like n8n_get_credential (which retrieves full credential data). It's specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for listing credentials without sensitive data, but doesn't explicitly state when to use this versus alternatives like n8n_get_credential (which includes sensitive data) or n8n_list_workflows. It provides clear context but lacks explicit comparison to sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, non-destructive, and idempotent behavior, which the description does not contradict. The description adds context about pagination (via 'cursor') and default values (e.g., 'limit' default: 100), but lacks details on rate limits, authentication needs, or error handling. With annotations covering safety, this earns a baseline 3.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear purpose statement followed by 'Args:' and 'Returns:' sections. It is front-loaded and avoids unnecessary details, though the parameter listing could be more concise. Overall, it is efficient with little waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the annotations cover safety (read-only, non-destructive) and the schema fully describes parameters, the description is mostly complete. It includes return value details (list of executions with fields) despite no output schema, but lacks context on error cases or performance limits. For a list tool with good annotations, this is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, meaning all parameters are documented in the schema. The description adds minimal value by listing parameters and their purposes (e.g., 'Filter by workflow ID'), but does not provide additional semantics beyond the schema. This meets the baseline of 3 for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose as 'List workflow executions with optional filtering,' which specifies the verb ('List') and resource ('workflow executions'). It distinguishes from siblings like 'n8n_get_execution' (singular) and 'n8n_delete_executions' (deletion), but does not explicitly differentiate from other list tools (e.g., 'n8n_list_workflows'), making it a 4.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 mentions optional filtering but does not specify when to use it over other list tools (e.g., 'n8n_list_workflows') or when filtering is appropriate, resulting in a minimal score of 2.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds value by mentioning pagination via the 'cursor' parameter and the return format ('List of projects with id, name, and type'), but doesn't detail rate limits, auth needs, or error handling. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a purpose statement, context, and separate 'Args' and 'Returns' sections. It's front-loaded with the core action. However, the context sentence about projects could be slightly more integrated, and the repetition of schema info in 'Args' adds minor redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (list operation with 2 parameters), rich annotations (covering safety and idempotency), and 100% schema coverage, the description is mostly complete. It includes return value details despite no output schema. Minor gaps include lack of explicit sibling differentiation and deeper behavioral context like error cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with clear descriptions for 'limit' and 'cursor' in the input schema. The description repeats this information in the 'Args' section, adding minimal value beyond the schema. The default for 'limit' is mentioned in both, but the description doesn't explain pagination behavior further. Baseline 3 is appropriate given high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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'), and the title reinforces this. It distinguishes from sibling tools like 'n8n_get_project' (singular) and 'n8n_create_project' (creation). However, it doesn't explicitly differentiate from other list tools (e.g., 'n8n_list_workflows'), though 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context about what projects are ('organize workflows and credentials into separate workspaces'), which implies usage for workspace management. It doesn't explicitly state when to use this tool versus alternatives like 'n8n_get_project' or other list tools, nor does it mention prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate this is a read-only, non-destructive, idempotent operation with a closed world, so the description doesn't need to repeat safety aspects. It adds value by specifying the return format ('List of tags with id and name') and mentioning pagination via the 'cursor' parameter, which provides useful behavioral context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with the core purpose in the first sentence. The 'Args' and 'Returns' sections are concise and directly relevant, with no redundant information. Every sentence serves a clear purpose, making it efficient and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (2 parameters, 100% schema coverage, no output schema), the description is mostly complete. It covers the purpose, parameters, and return format. However, it lacks details on error handling or rate limits, which could be useful for an agent. With annotations providing safety context, this is a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with clear documentation for both parameters ('limit' and 'cursor'), so the description doesn't need to add parameter details. The description mentions pagination and default limit, but these are already covered in the schema. Baseline 3 is appropriate as the schema handles parameter semantics effectively.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('List all tags') and resource ('available for organizing workflows'), making the purpose immediately evident. It distinguishes this tool from siblings like 'n8n_get_tag' (which retrieves a single tag) and 'n8n_create_tag'/'n8n_delete_tag'/'n8n_update_tag' (which modify tags), establishing its role as a bulk retrieval operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when needing to see all available tags, but provides no explicit guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as whether tags must exist or if authentication is required, nor does it compare to other listing tools (e.g., 'n8n_list_workflows') for context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide strong behavioral hints (readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=false), so the bar is lower. The description adds some context by mentioning pagination via the cursor parameter and listing the return fields (id, email, name, role), which helps the agent understand the output format since there's no output schema. However, it doesn't disclose rate limits, authentication needs, or error conditions beyond what annotations imply.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and appropriately sized. It starts with the core purpose, then lists parameters and returns in clear sections. Every sentence adds value, though the parameter descriptions slightly overlap with the schema. It could be more front-loaded by moving the return details closer to the top for faster scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (simple list operation), rich annotations (covering safety and idempotency), and 100% schema coverage, the description is reasonably complete. It explains the return format, which is crucial since there's no output schema. However, it lacks context about authentication, error handling, or performance considerations that could help the agent use it more effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already fully documents all three parameters. The description adds minimal value beyond the schema: it restates the cursor's purpose ('Pagination cursor') and mentions the default for includeRole, but doesn't explain parameter interactions or provide usage examples. This meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'List all users in the n8n instance.' This is a specific verb+resource combination that tells the agent exactly what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'n8n_get_user' (which presumably fetches a single user), so it misses 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.

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 'n8n_get_user' (for individual users) and 'n8n_get_current_user' (for the authenticated user), the agent receives no help in choosing between them. There's no mention of prerequisites, access requirements, 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide comprehensive behavioral hints (readOnlyHint, openWorldHint, idempotentHint, destructiveHint), so the description doesn't need to repeat safety information. It adds useful context about variable accessibility syntax and pagination behavior, but doesn't disclose additional traits like rate limits or authentication requirements beyond what annotations cover.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (purpose, syntax context, Args, Returns) and appropriately sized. Every sentence serves a purpose, though the parameter restatement in 'Args' is somewhat redundant given the comprehensive schema documentation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only listing tool with comprehensive annotations and full parameter documentation, the description provides adequate context. It explains the resource being listed, includes syntax context, and describes the return format. The main gap is the lack of an output schema, but the description compensates by specifying what fields are returned.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the input schema already fully documents both parameters (limit and cursor). The description adds minimal value by restating parameter purposes in the 'Args' section without providing additional syntax, format, or usage details beyond what the schema already specifies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 environment variables', making the purpose specific. It distinguishes from siblings like 'n8n_get_variable' (singular retrieval) and 'n8n_create_variable' (creation), establishing its role as a bulk listing operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context by mentioning that variables are accessible in workflows using $vars.variableName syntax, which helps users understand when this tool is relevant. However, it doesn't explicitly state when to use this tool versus alternatives like 'n8n_get_variable' or 'n8n_create_variable', missing explicit comparison guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare this as read-only, non-destructive, and idempotent, which the description doesn't contradict. The description adds valuable behavioral context beyond annotations by specifying the return format (list with id, name, active status, timestamps, tags) and pagination behavior (nextCursor for continuation), which helps the agent understand what to expect from the operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (purpose statement, Args, Returns) and uses bullet points for readability. While efficient, the 'Args' section could be more concise since it largely duplicates schema information, and the initial purpose statement could be slightly more specific about differentiation from siblings.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the annotations cover safety aspects (read-only, non-destructive) and the description details return values and pagination, this provides adequate context for a listing tool. The lack of an output schema is compensated by the Returns section. However, it could better address sibling tool relationships and edge cases (e.g., what happens when no filters match).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the input schema already documents all 6 parameters thoroughly. The description's 'Args' section essentially repeats what's in the schema without adding significant semantic context (e.g., explaining relationships between filters or typical use cases for each). This meets the baseline expectation when schema coverage is complete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('List all workflows') and resource ('in the n8n instance'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'n8n_get_workflow' (singular) or 'n8n_list_executions', which might cause some ambiguity about when to use this specific listing tool versus others.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage through the mention of 'optional filtering' and pagination, suggesting this is for retrieving multiple workflows with filtering capabilities. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'n8n_get_workflow' (for single workflow) or 'n8n_list_executions' (for workflow runs), leaving some ambiguity about the optimal context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate this is a non-readOnly, non-destructive, non-idempotent operation, which the description aligns with by implying mutation ('Retry') without contradiction. The description adds that it creates a new execution, providing useful context beyond annotations, but lacks details on side effects (e.g., if the original execution is modified), permissions, 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose in the first sentence, followed by structured Args and Returns sections. It's efficient with minimal waste, though the Args/Returns formatting could be slightly more integrated into natural language for better flow.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (mutating operation with one parameter) and lack of output schema, the description is minimally adequate. It states the action and return value but omits details like error handling, execution state requirements, or how the new execution relates to the original, leaving gaps for an agent to infer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the input schema fully documents the 'id' parameter. The description adds no additional semantic context about the parameter (e.g., where to find the ID, format expectations, or validation rules), so it meets the baseline of 3 without adding value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Retry a failed execution') and specifies the resource ('execution'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this from sibling tools like 'n8n_stop_execution' or 'n8n_get_execution' beyond the obvious retry vs. stop/get distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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., that the execution must be in a failed state), nor does it clarify relationships with tools like 'n8n_list_executions' (to find failed executions) or 'n8n_run_workflow' (for initial runs).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide readOnlyHint=false (indicating mutation), openWorldHint=true (flexible inputs), idempotentHint=false (non-repeatable), and destructiveHint=false (safe). The description adds that this is a 'manual' execution and describes the return structure, which is useful since there's no output schema. However, it doesn't disclose behavioral aspects like execution timeouts, rate limits, authentication requirements, or what happens if the workflow fails.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose in the first sentence, followed by structured 'Args' and 'Returns' sections. It avoids redundancy, though the 'Args' section partially repeats schema information. The structure is clear but could be more streamlined by integrating parameter details more naturally.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (execution with input/output), annotations cover safety and idempotency, but there's no output schema. The description compensates by detailing return values, which is helpful. However, it lacks context on error handling, execution states beyond 'status,' and how this interacts with sibling tools like workflow activation or execution management.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both parameters ('id' and 'data') well-documented in the schema itself. The description adds that 'data' is 'optional' and passes to 'the workflow's first node,' providing slight additional context about how input flows. This meets the baseline for high schema coverage without significant value addition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Execute a workflow manually with optional input data' which specifies the verb (execute/run) and resource (workflow). It distinguishes from siblings like 'activate_workflow' or 'get_workflow' by focusing on immediate execution rather than state changes or retrieval. However, it doesn't explicitly contrast with 'retry_execution' or 'stop_execution' which are also execution-related.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage through 'manually' and 'optional input data,' suggesting this is for ad-hoc execution rather than automated triggers. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'retry_execution' (for failed runs) or 'activate_workflow' (for enabling automated execution), nor does it mention prerequisites like workflow activation status.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds significant behavioral context beyond annotations: it explicitly warns that this 'will remove the Git integration' (reinforcing destructiveHint=true) and specifies what the tool returns ('Confirmation of disconnection'). This provides crucial operational details that annotations alone don't convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is perfectly structured: a clear action statement, a prominent warning, and a return value specification—all in three concise lines with zero wasted words. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive operation with no parameters and no output schema, the description provides complete context: what it does, the critical warning about consequences, and what to expect in response. This fully compensates for the lack of output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0 parameters and 100% schema coverage, the baseline would be 4. The description appropriately doesn't discuss parameters since none exist, maintaining focus on the tool's purpose and behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Disconnect from the remote Git repository') and distinguishes it from siblings like 'n8n_source_control_pull', 'n8n_source_control_push', and 'n8n_source_control_status' by focusing on removing integration rather than syncing or checking status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 it (to remove Git integration) and includes a warning about consequences, but doesn't explicitly mention 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide hints (readOnlyHint=false, destructiveHint=false, etc.), but the description adds valuable context: it mentions that pulling can affect files and includes a 'force' option for handling local changes, which clarifies operational behavior beyond the annotations. There's no contradiction with annotations, as 'pull' aligns with non-read-only and non-destructive hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with the core action, followed by brief parameter and return summaries. It avoids unnecessary details, but the parameter section slightly repeats schema info, making it less than perfectly concise. Overall, it's efficient and easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (Git operations with optional parameters), annotations cover safety aspects, and the description adds key behavioral context (e.g., force option, affected files). Without an output schema, the return statement is helpful but minimal. It's mostly complete but could benefit from more detail on error cases or integration with other source control tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already fully documents the parameters. The description repeats some parameter info (e.g., 'force' and 'variables') but doesn't add significant meaning beyond what's in the schema, such as explaining how variables interact with the pull operation. This meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Pull changes') and resource ('from the remote Git repository'), making the purpose immediately understandable. It distinguishes itself from siblings like 'n8n_source_control_push' and 'n8n_source_control_status' by focusing on the pull operation, which is a distinct Git workflow step.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context through the mention of 'remote Git repository' and parameters like 'force', suggesting it's for syncing with source control. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., when to prefer 'n8n_source_control_status' first) or prerequisites like having a connected repository, leaving usage somewhat inferred rather than clearly defined.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate this is a non-readOnly, non-destructive, non-idempotent operation with openWorldHint. The description adds minimal behavioral context beyond this - it mentions 'affected files' in returns but doesn't explain what happens during a push, potential side effects, or error conditions. No contradiction with annotations exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured with clear sections (description, Args, Returns). However, the 'Args' and 'Returns' sections could be more integrated with the main description rather than appearing as separate bullet points. The core description is a single clear sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a Git push operation with 2 parameters and no output schema, the description provides basic functionality but lacks important context. It doesn't explain what 'changes' means in this context, what happens if there are no changes to push, authentication requirements, or error scenarios. The annotations help but don't fully compensate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the schema already fully documents both parameters. The description's 'Args' section merely repeats what's in the schema without adding meaningful context about when to use force push or what constitutes a good commit message. Baseline 3 is appropriate when schema does all the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Push changes') and target resource ('remote Git repository'), distinguishing it from sibling tools like n8n_source_control_pull and n8n_source_control_status. It uses precise Git terminology that indicates its unique function within the source control toolset.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus alternatives. While the description implies it's for pushing changes, it doesn't specify prerequisites (e.g., whether changes need to be staged/committed first), when force push is appropriate, or how it relates to the pull/status/disconnect siblings in the workflow.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds value by specifying the return structure (branchName, connected, ahead, behind, conflicts), which is useful context beyond annotations, though it doesn't mention rate limits or authentication needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose in the first sentence, followed by a bulleted list of return values. Every sentence earns its place, with no wasted words, 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (0 parameters, no output schema) and rich annotations, the description is mostly complete. It explains what the tool does and what it returns, though it could benefit from more explicit usage guidelines or prerequisites. The lack of an output schema is compensated by the detailed return description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0 parameters and 100% schema description coverage, the baseline is 4. The description doesn't need to explain parameters, and it appropriately focuses on the tool's purpose and output without redundant parameter information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Get the current source control (Git) status') and resource ('source control'), distinguishing it from siblings like n8n_source_control_pull or n8n_source_control_disconnect. It precisely communicates what the tool does without being vague or tautological.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for checking Git status, but doesn't explicitly state when to use this tool versus alternatives (e.g., n8n_source_control_pull for updates or n8n_check_connection for general connectivity). It provides basic context but lacks explicit guidance on exclusions or comparisons with sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide key behavioral hints (readOnlyHint=false, destructiveHint=false, idempotentHint=true), so the description doesn't need to repeat safety or idempotency. However, it adds minimal context beyond annotations—only stating it returns 'stopped execution details.' It could elaborate on effects (e.g., halts processing, may leave partial results) or constraints (e.g., permissions needed), but doesn't contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose ('Stop a running execution'), followed by brief parameter and return notes. It's efficient with no wasted sentences, though the Args/Returns formatting is slightly verbose for a single parameter. Overall, it's well-structured and to the point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (a mutation to stop executions), annotations cover safety and idempotency, but there's no output schema. The description mentions return details but lacks specifics (e.g., status fields, error handling). It's adequate for basic use but leaves gaps in understanding outcomes, especially without output schema support.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with the parameter 'id' fully documented in the schema. The description adds no additional meaning beyond the schema's 'unique identifier of the resource,' merely restating it as 'Execution ID to stop.' This meets the baseline for high schema coverage but doesn't enhance understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Stop a running execution') and identifies the resource ('execution'), distinguishing it from sibling tools like n8n_delete_execution (which removes) or n8n_retry_execution (which restarts). The verb 'Stop' is precise and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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. It doesn't mention prerequisites (e.g., the execution must be running), exclusions (e.g., cannot stop completed executions), or comparisons to siblings like n8n_delete_execution. The agent must infer usage from context alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate this is a mutable (readOnlyHint=false), non-destructive (destructiveHint=false), idempotent (idempotentHint=true) operation. The description adds minimal behavioral context beyond this, mentioning only a confirmation return without detailing side effects like permission requirements or credential state changes. It doesn't contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with the core purpose, followed by parameter and return details. It avoids unnecessary fluff, though the 'Args' and 'Returns' sections could be integrated more seamlessly into a single narrative flow.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 parameters, no output schema), the description covers the basic operation but lacks details on error conditions, authentication needs, or what 'confirmation' entails. Annotations provide safety hints, but more behavioral context would enhance completeness for a mutation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both parameters clearly documented in the schema. The description's 'Args' section repeats this information without adding extra meaning, such as format examples or constraints. Baseline 3 is appropriate since the schema fully covers parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Transfer a credential') and resource ('to a different project'), distinguishing it from sibling tools like 'n8n_transfer_workflow' which transfers workflows instead of credentials. The verb 'transfer' is precise and the scope is well-defined.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like 'n8n_update_credential' or 'n8n_create_credential', nor are prerequisites or exclusions mentioned. The description only states what the tool does, not when it should be selected.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already indicate this is a non-destructive, idempotent mutation (readOnlyHint=false, destructiveHint=false, idempotentHint=true). The description adds minimal behavioral context beyond this - it mentions 'confirmation of transfer' as the return, but doesn't specify what happens to the original workflow, permission requirements, or system constraints. The description doesn't contradict annotations, but adds limited value beyond them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately concise with a clear purpose statement followed by parameter and return documentation. The structure is logical and front-loaded. However, the Args/Returns sections essentially duplicate schema information without adding value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with good annotation coverage but no output schema, the description is minimally adequate. It states what the tool does and what it returns, but lacks important context about workflow state changes, error conditions, and relationship to sibling tools. The annotations cover safety aspects, but operational details are missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, both parameters are already documented in the schema with identical descriptions to what appears in the tool description. The description adds no additional semantic context about parameter formats, constraints, or relationships beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('transfer') and resource ('workflow to a different project'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'n8n_duplicate_workflow' or 'n8n_import_workflow', which might involve similar workflow movement operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 many sibling tools that manipulate workflows (duplicate, import, export, delete, update), there's no indication of when transferring between projects is appropriate versus other operations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds valuable context beyond annotations: it specifies that sensitive data is excluded from returns ('without sensitive data'), which annotations don't cover. Annotations already indicate this is a non-destructive, idempotent mutation (readOnlyHint=false, destructiveHint=false, idempotentHint=true), so the description appropriately focuses on output behavior rather than repeating safety information.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (Args, Returns) and uses only essential sentences. It's appropriately sized for a simple update operation, though the Args section slightly duplicates schema information without adding new insights.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with good annotations and full parameter documentation, the description is reasonably complete. It covers the core action, parameters, and output behavior. The main gap is lack of usage guidance relative to sibling tools, but annotations handle safety aspects well.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the schema already documents all three parameters thoroughly. The description adds minimal value by restating parameter purposes in the Args section but doesn't provide additional context like format examples, constraints, or relationships between parameters beyond what's in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Update') and resource ('an existing credential'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'n8n_create_credential' or 'n8n_transfer_credential' beyond the obvious verb difference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 credential ID), when not to use it, or how it differs from similar tools like 'n8n_transfer_credential' or 'n8n_create_credential' beyond the basic verb.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide key behavioral hints: readOnlyHint=false (mutation), idempotentHint=true (safe to retry), destructiveHint=false (non-destructive). The description adds that it 'renames' a project, which clarifies the specific type of update beyond the generic title. However, it doesn't disclose additional context like authentication needs, rate limits, or what happens to other project attributes during rename. No contradiction with annotations exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded with the core purpose ('Rename a project.'). The Args and Returns sections are structured but somewhat redundant given the schema. Every sentence serves a purpose, though the parameter descriptions could be omitted without loss since they duplicate the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with 2 parameters, 100% schema coverage, and annotations covering safety (idempotent, non-destructive), the description is minimally adequate. It lacks an output schema, so the 'Returns' statement is helpful but vague ('The updated project'). More detail on the return structure or error conditions would improve completeness, but annotations provide critical behavioral context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both parameters ('id' and 'name') fully documented in the schema. The description repeats the parameter purposes in the 'Args' section but adds no extra meaning beyond what the schema already provides (e.g., no examples, constraints like name uniqueness, or format details). This meets the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 'Rename a project' - a specific verb (rename) and resource (project). It distinguishes from siblings like 'n8n_create_project' (creation) and 'n8n_delete_project' (deletion), though it doesn't explicitly contrast with 'n8n_update_workflow' or other update tools. The title 'Update n8n Project' is slightly broader than the description's focus on renaming.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 project ID), when not to use it, or how it differs from other update tools like 'n8n_update_workflow' or 'n8n_update_variable'. The agent must infer usage from the tool name and sibling list alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide key behavioral hints: readOnlyHint=false (mutation), idempotentHint=true (safe to retry), destructiveHint=false (non-destructive). The description adds minimal context beyond this - it clarifies that it renames rather than creates, but doesn't mention permission requirements, rate limits, or what happens if the name already exists. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (purpose, Args, Returns) and uses only essential sentences. However, the Args section largely duplicates schema information, and the Returns section could be more informative given there's no output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with good annotations but no output schema, the description is minimally adequate. It covers the basic operation and parameters but lacks important context about error conditions, what 'updated tag' means structurally, and how this tool fits within the broader tag management ecosystem alongside its siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the schema already fully documents both parameters (id and name with their constraints). The description repeats this information in the Args section but adds no additional semantic context about parameter relationships, validation rules beyond max length, or format expectations for the ID.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Rename') and resource ('an existing tag'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from its sibling 'n8n_update_workflow_tags' which also deals with tag updates, nor does it mention that this is specifically for renaming versus other tag modifications.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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), when not to use it, or how it differs from sibling tools like 'n8n_update_workflow_tags' or 'n8n_create_tag' for tag management scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover key behavioral traits: readOnlyHint=false (mutation), idempotentHint=true (safe to retry), destructiveHint=false (non-destructive). The description adds minimal context by specifying 'existing variable', implying it modifies rather than creates. However, it doesn't disclose additional behaviors like authentication needs, rate limits, or what happens if the ID doesn't exist. With annotations providing safety profile, a 3 is appropriate—some value added but limited behavioral detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded with the core action ('Update an existing variable'). The Args and Returns sections are structured but somewhat redundant with the schema. Every sentence serves a purpose, though the parameter listings could be trimmed since they're covered in the schema. Overall, it's efficient with minimal waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (mutation with 3 parameters), annotations provide safety context, but there's no output schema. The description covers the basic operation and return statement ('The updated variable'), but lacks details on error conditions, permissions, or system limits. It's minimally adequate but leaves gaps for a mutation tool, especially without output schema to clarify return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with each parameter clearly documented in the schema (e.g., 'Variable ID to update', 'New variable key'). The description repeats the parameter names and types but adds no extra semantic meaning beyond the schema. According to guidelines, baseline is 3 when schema coverage is high (>80%), which fits here as the description doesn't enhance parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Update') and resource ('existing variable'), making the purpose immediately understandable. It distinguishes from sibling tools like 'n8n_create_variable' by specifying 'existing' and from 'n8n_delete_variable' by the update action. However, it doesn't explicitly contrast with 'n8n_get_variable' or other update tools (e.g., 'n8n_update_workflow'), leaving some sibling differentiation implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 variable ID), when not to use it (e.g., for creating new variables), or direct alternatives like 'n8n_create_variable' or 'n8n_delete_variable'. The agent must infer usage from the tool name and context alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds valuable behavioral context beyond annotations: the critical warning about complete array replacement for nodes/connections (partial updates not supported), which isn't covered by annotations. Annotations already indicate it's not read-only, not destructive, and idempotent, but the description provides specific implementation behavior that helps the agent understand how to use the tool correctly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured: purpose statement first, critical warning prominently displayed, then parameter summary and return value. Every sentence earns its place - the warning is essential, the parameter list helps scanning, and the return statement clarifies output. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with rich schema (7 params, nested objects) and annotations covering safety aspects, the description provides good context: purpose, critical behavioral constraint, parameter overview, and return value. The main gap is lack of output schema, but the description states what's returned. It could benefit from more context about error conditions or prerequisites.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the baseline is 3. The description adds value by explaining that nodes/connections require 'COMPLETE arrays' and that 'provided values will replace existing ones,' which clarifies the semantics beyond the schema's structural definitions. However, it doesn't provide additional context about parameter interactions or usage examples.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 ('existing workflow'), and specifies what can be updated ('name, nodes, connections, settings, or tags'). It distinguishes from siblings like n8n_create_workflow (create vs update) and n8n_update_workflow_tags (partial vs complete update).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance about when to use this tool vs alternatives through the warning about complete arrays for nodes/connections, implying this is for full replacements rather than partial updates. However, it doesn't explicitly mention when NOT to use it (e.g., vs n8n_update_workflow_tags for tag-only updates) or other specific alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate this is a non-destructive, idempotent mutation (readOnlyHint=false, destructiveHint=false, idempotentHint=true). The description adds minimal behavioral context beyond this—it clarifies that tags are 'associated with a workflow' and that the operation returns the updated workflow, but doesn't explain permissions, side effects, or how tag arrays are processed (e.g., whether they replace or merge with existing tags).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and concise, with a clear purpose statement followed by brief 'Args' and 'Returns' sections. Every sentence serves a purpose, though the 'Args' section slightly repeats schema information without adding value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with rich annotations (covering safety and idempotency) and full schema coverage, the description is minimally adequate. However, it lacks output details (no schema provided), doesn't explain tag array behavior (e.g., replacement vs. merge), and offers no error-handling context, leaving gaps in usability.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both parameters ('id' and 'tags') fully documented in the schema. The description briefly mentions these in the 'Args' section but adds no meaningful semantic context beyond what the schema already provides, such as tag ID format or array constraints.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Update') and resource ('tags associated with a workflow'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'n8n_update_workflow' or 'n8n_update_tag', which could handle similar tag-related operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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. With siblings like 'n8n_update_workflow' (which might update tags as part of broader workflow changes) and 'n8n_update_tag' (which might modify tag properties), the description offers no context for choosing this specific tag-update operation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.