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

No annotations are present, so the description bears full responsibility. It only states the action (activate/deactivate) without disclosing side effects (e.g., stopping executions on deactivation), authentication needs, or rate limits. The behavior beyond the verb is opaque.

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 a single, front-loaded sentence that efficiently conveys the core purpose. Every word is meaningful, but it could be slightly expanded without losing conciseness.

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 (3 params, no output schema), the description lacks context about the effect on workflow state (e.g., active runs triggers; deactivated pauses) and dependencies (workflow must exist). An agent might not know to validate the workflow ID or handle server_name defaults.

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 already documented (e.g., 'true to activate, false to deactivate'). The description adds no extra meaning beyond what the schema provides, earning a baseline score of 3.

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 'Activate or deactivate an n8n workflow,' specifying the verb (activate/deactivate) and the resource (n8n workflow). This distinguishes the tool from siblings like n8n_create_workflow, n8n_delete_workflow, and n8n_set_safety_mode, which handle other 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 (e.g., n8n_update_workflow, n8n_restore_workflow). There is no mention of prerequisites such as requiring the workflow to exist or being already active/deactive, nor any 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?

With no annotations provided, the description carries the transparency burden. It does disclose that the tool mutates state by adding or updating a server connection and mentions an auth prerequisite. However, it does not explain update semantics, idempotency, or what happens to existing server flags or connections.

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 compact and front-loaded: the core purpose appears in the first sentence, and the supporting API-key note is short. It is slightly redundant with the api_key schema description, but it remains efficient and readable.

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?

The definition is minimally viable for basic invocation: the purpose is clear and required parameters are fully described in the schema. However, it lacks detail on update behavior, expected return/confirmation, and comparison with server-management siblings, and there is no output schema to 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?

Schema description coverage is 100%, so the schema already documents all four parameters. The description only duplicates the api_key creation note and adds no meaningful semantic value beyond what the input schema already 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 gives a specific verb-resource pair: 'Add or update an n8n server connection.' This clearly distinguishes the tool from siblings like n8n_list_servers, n8n_remove_server, and n8n_ping_server because the action and resource are 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 given about when to use this tool instead of alternatives such as n8n_list_servers or n8n_remove_server. The description implies its use case through the verb 'add or update,' but never states exclusions, alternatives, or prerequisites beyond API-key creation.

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?

There are no annotations, so the description carries the burden of disclosing side effects. It only says 'Create' and does not mention duplicate handling, activation behavior, server selection, or reversibility. The schema's activate default is not reflected in the prose, and no return behavior is described.

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 a single short sentence with no filler, and it front-loads the core action. The second phrase about 'full workflow JSON' is somewhat redundant given the schema, but the overall structure is clean and scannable.

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 no annotations and no output schema, the description is thin: it omits expected return value, duplicate-name behavior, and relationship to import/update siblings. The detailed schema mitigates parameter confusion but cannot fully compensate for missing behavioral and usage 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%, so the schema already documents all five parameters. The prose adds only a general hint that nodes and connections are needed for a complete workflow, which is mildly helpful but does not substantially extend what the schema already 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 states a clear action and resource: 'Create a new n8n workflow.' It is specific and unambiguous about the core operation. However, it does not distinguish itself from sibling n8n_import_workflow, which also creates workflows via import, so it stops short of 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?

No guidance is given about when to use this tool versus alternatives such as n8n_import_workflow or n8n_update_workflow. The description only states what the tool does, leaving the agent to infer which workflow-creation path is appropriate.

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?

With no annotations, the description carries the burden of disclosing destructive behavior. It clearly says 'Delete' and adds the important context that a JSON backup is saved by default. However, it does not mention permanence, required permissions, or what happens after deletion.

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?

Two short sentences with no filler. The primary action is stated first, and the backup behavior is added succinctly.

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 two-parameter delete operation, the description gives essential information: what is deleted and the default safety backup. It does not describe the response or possible errors, but those are not critical for invoking the 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?

The input schema already describes both parameters fully (100% coverage). The description adds no extra meaning about workflow_id or server_name, so it meets the baseline but provides no additional value.

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 states a specific verb ('Delete') and resource ('workflow from an n8n server'), which is unambiguous. The added backup detail also helps distinguish this destructive operation from related siblings like n8n_restore_workflow and n8n_list_backups.

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?

There is no guidance about when to use this tool versus alternatives such as deactivating a workflow or exporting it. The backup note implies a safety benefit, but it does not explicitly state when deletion is appropriate or when another sibling should be used 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?

Without annotations, the description must disclose behavioral traits. It does not mention that the tool is read-only, safe, or any other behavioral aspects, leaving the agent to infer safety from the verb 'describe'.

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 concise, with two sentences that are both informative and free of unnecessary text. It front-loads the main action and purpose effectively.

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 lookup tool with one optional parameter and no output schema, the description sufficiently explains the tool's function and usefulness. It could be slightly more specific about the output, but is adequate overall.

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 fully documents the single parameter with a description. The tool description does not add any further meaning beyond what the schema already provides, so it meets 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 that the tool gets information about common n8n node types, using a specific verb and resource. It implicitly distinguishes from sibling tools that focus on workflows, servers, etc., but the term 'common' is somewhat vague.

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 ('useful for understanding which nodes to use') but does not give explicit guidance on when to use it versus alternatives, nor does it specify when not to use it.

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

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

No annotations provided, so description carries full burden. It mentions returning a complete workflow definition but does not disclose whether the operation is read-only, requires specific permissions, or any side effects.

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

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

The description is two sentences, front-loaded with the action and output. No redundant 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 simple tool with 2 parameters and no output schema, the description is mostly complete. It covers the return value and purpose. Missing details like error conditions or prerequisites, but adequate for the complexity.

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 coverage is 100% with descriptions. The description adds value by noting that 'server_name' uses default if omitted, which is not in the schema. However, it doesn't elaborate on format or constraints 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 ('Export'), the resource ('workflow'), and the output format ('JSON'). It distinguishes from siblings like n8n_get_workflow by emphasizing the complete definition for import.

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?

Implied usage: exporting for backup or migration. No explicit guidance on when to use vs. alternatives like n8n_get_workflow or conditions for use.

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?

No annotations are provided, so the description carries the full burden. It clearly indicates a read-only operation ('Get detailed information') and adds context about what is returned, but does not discuss side effects, auth requirements, 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?

One sentence, efficient, front-loaded verb+resource. 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 simple get tool, the description covers the main points and return content. It lacks some detail (e.g., error handling) but is sufficient for selection among 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?

Schema coverage is 100%, and the description does not add extra meaning beyond the schema. It references the resource generally but does not elaborate on the 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 verb 'Get detailed information' and the resource 'a specific n8n workflow', specifying the included content (nodes, connections, settings). This distinguishes it from siblings like n8n_list_workflows and n8n_update_workflow.

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

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

The description implies use when detailed information on a specific workflow is needed, but does not explicitly state when not to use or mention alternative tools for listing or modifying 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?

With no annotations , the description must disclose behavioral traits. It only states the tool 'creates' a workflow but does not specify idempotency, overwrite behavior, required permissions, or side effects. This is insufficient for a mutation tool.

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

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

The description is concise at two sentences, front-loading the action and resource. No superfluous 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?

The description covers the basic action but lacks context like relationship to sibling tools (e.g., import vs. create vs. restore) and requirements (e.g., server must exist). Minimal completeness given tool complexity.

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 coverage is 100%, so the schema already documents all three parameters. The description adds no extra meaning beyond 'full n8n workflow JSON,' which is already clear from the schema. Baseline score of 3 is appropriate.

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 imports a workflow JSON onto an n8n server and creates it, implying uploading an exported file. This distinguishes it from other creation tools like n8n_create_workflow, but it does not explicitly name siblings or contrast them.

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 (e.g., n8n_create_workflow for step-by-step creation, n8n_restore_workflow for recovery). No prerequisites or exclusions 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?

No annotations are provided, so the description carries the disclosure burden. 'List' clearly signals a read-only operation, and 'backups created before n8n mutations' provides useful context about what is being read. However, it does not disclose return format, whether local means filesystem vs database, or any operational caveats.

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 a single front-loaded sentence with no filler. It states the verb and resource immediately and includes a meaningful qualifier without wasting 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?

With only three optional, fully documented parameters and no nested objects, the tool is simple enough that this description is nearly complete. A small gap is the absence of any mention of the response shape, but 'list' reasonably implies a list of backup entries.

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?

Input schema coverage is 100%, and each parameter has a clear description. The tool description itself adds no additional parameter semantics, which is acceptable because the schema already fully documents what each parameter means.

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 uses a specific verb ('List'), a clear resource ('local workflow backups'), and a defining condition ('created before n8n mutations'). This makes the tool's purpose immediately clear and distinguishes it from sibling tools like n8n_list_workflows or n8n_list_executions.

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 phrase 'created before n8n mutations' implies the tool is relevant in a backup/safety workflow, but there is no explicit guidance about when to prefer this over alternatives like n8n_restore_workflow or n8n_safety_status. Usage context is implied 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?

With no annotations, the description carries the burden of behavioral disclosure. It discloses that the tool returns status, timing, and error information, and the verb 'List' implies a read-only operation. However, it does not mention whether this is purely read-only, whether server_name resolution has side effects, or how it handles missing/invalid filters.

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 one tight, front-loaded sentence that states the core action and the key output dimensions. Every word earns its place with no filler or redundancy.

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

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

For a simple listing tool with four optional parameters fully described in the schema, the description provides enough context about the returned data (status, timing, errors). It could mention that results are ordered by recency or that the limit default applies, but those details are inferable from the description and 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?

Schema description coverage is 100%, so every parameter already has a clear meaning in the schema. The description adds no parameter-specific detail beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description names a specific verb ('List'), resource ('workflow executions'), and scope ('on an n8n server'). It clearly distinguishes this from siblings like n8n_list_workflows, which list workflow definitions rather than execution history.

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 makes the use case clear: retrieving recent execution records, including their status, timing, and errors. It does not explicitly name alternatives or exclusions, but the resource distinction from siblings is evident enough, and no conflicting alternative is obvious.

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?

With no annotations, the description must disclose behavior. It states a read-only listing operation, but does not mention any authentication needs, rate limits, or output format. For a simple list, this is adequate but not rich.

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

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

A single sentence that immediately conveys the action and scope. No unnecessary 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?

The description is complete for a simple list operation, but does not specify the return format (e.g., array of server details). Given no output schema, more detail would improve 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?

There are no parameters, so schema coverage is trivially 100%. The description adds no parameter info, but none is needed. Baseline for 0 parameters is 4.

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 uses a specific verb 'List' and resource 'all configured n8n server connections', clearly distinguishing it from sibling tools like n8n_add_server or n8n_remove_server which modify individual servers.

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 one needs an overview of server connections, but provides no explicit guidance on when not to use it or comparisons to alternatives. Context from sibling names suggests it is complementary to other server-related 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?

No annotations are provided, so the description carries the full burden of disclosing behavior. It does reveal the returned fields, but it claims to list 'all' workflows while the input schema caps results at 1000 with a default of 100, and no pagination behavior is mentioned. This makes the description misleading about the actual tool behavior.

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 two concise sentences with the action front-loaded and the return payload summarized immediately. There is no filler, redundancy, or unnecessary boilerplate.

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 list tool, the essential purpose and return fields are present, and the schema covers both parameters. However, the 'all' claim conflicts with the limit parameter, and the absence of an output schema or pagination details leaves a material gap for agents that need a truly complete workflow set.

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 both `limit` and `server_name` are already documented in the input schema. The description adds no extra semantic detail about these parameters, which matches 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 uses a specific verb ('List') and resource ('workflows') with a clear scope ('on an n8n server'), and lists the key returned fields. This distinguishes it from sibling tools like n8n_get_workflow or n8n_list_executions, though the word 'all' is slightly overstated given the limit parameter.

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 this tool is for enumerating workflows, but it does not explicitly state when to use it over alternatives like n8n_get_workflow, n8n_list_executions, or n8n_export_workflow. No when/when-not guidance or exclusions are provided, so the agent must infer usage from the sibling tool names and 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?

With no annotations provided, the description carries the full burden of behavioral disclosure, and it handles this well by explicitly stating 'Read-only' and explaining the critical failure mode when the environment variable is missing, including the consequence of talking to n8n directly. It could go further by describing response shape or pagination, but the two most operationally important behaviors are disclosed.

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?

Three sentences, all front-loaded with purpose first, then the critical precondition and failure mode, then the safety statement. Every sentence earns its place with distinct information and there is zero wasted text.

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, 2-parameter tool with fully self-documenting parameters, the description covers purpose, safety, and the key operational gotcha (environment variable). The main gap is the absence of an output schema combined with no description of the return structure, though naming the three content sections partially compensates by letting an agent infer the response shape.

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%; both parameters are already well-documented in the schema (limit range of 1-500, workflow_id disambiguation from n8n instance ID, and the omit-to-list behavior). The description adds only marginal context by naming the three history sections ('version history, recorded decisions, and sync history'), which loosely maps to what 'per history section' means, so the baseline 3 is appropriate.

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 states a specific verb ('Read') and a specific resource ('version history, recorded decisions, and sync history') from a 'running n8n-workflow-manager', which clearly distinguishes this tool from all siblings, none of which target manager history. The manager-vs-direct-n8n distinction further disambiguates it from tools like n8n_list_executions and n8n_list_backups.

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 an explicit precondition ('Requires the N8N_MCP_MANAGER_URL environment variable') and a clear when-not-to-use condition ('without it, this MCP talks to n8n directly and no such history exists'). This tells an agent when the tool will fail or return nothing. However, it does not name specific sibling alternatives for obtaining history from a direct n8n connection.

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?

No annotations are present, and the description does not disclose behavioral traits such as what the test does (e.g., ping, latency check), side effects, or return 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 a single sentence, efficient, but could be expanded slightly to add value without being verbose.

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?

No output schema is provided, and the description does not explain what the tool returns (e.g., success/failure, response time). For a simple test tool, some return or behavior detail is expected.

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 coverage is 100% for the single optional parameter; the description adds no further meaning beyond the schema's 'Server name. Uses default if omitted.'

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 'Test' and the resource 'connection to an n8n server', distinguishing it from sibling tools like n8n_list_workflows.

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 this is used to check connectivity, but provides no guidance on when to use vs. alternatives or when not to use.

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

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

No annotations provided. The description implies destructive action but does not disclose side effects, reversibility, or dependencies (e.g., does removal affect workflows?). For a deletion tool, this is a significant gap.

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

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

Single sentence, no wasted words. Appropriately sized for a simple tool.

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 tool with one param and no output schema, the description is technically complete but fails to provide necessary context for a destructive operation, such as confirmation steps or impact on associated resources.

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 coverage is 100% with one parameter. The description adds no extra meaning beyond the schema's 'Name of the server to remove,' so baseline of 3 is appropriate.

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 'Remove an n8n server from the configuration' uses a specific verb (remove) and resource (server), clearly distinguishing it from sibling tools like n8n_add_server or n8n_list_servers.

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 on when to use this tool vs alternatives, no prerequisites or exclusions provided. The description only states the action without 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?

With no annotations, the description carries the behavioral disclosure burden. It does reveal the key mutating behavior: creating by default and overwriting an existing workflow when target_workflow_id is provided. However, it omits the irreversibility of overwrite, any return value, activation side effects, or what happens to the backup file, leaving only partial transparency.

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?

Two sentences with no wasted words: the first states the core operation and the second captures the essential behavioral distinction. The key information is front-loaded 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?

For a mutating tool with no annotations and no output schema, the description covers the central create-vs-overwrite decision and references how to obtain a valid backup_path. However, it does not explain expected outcomes, error conditions, or the consequences of overwriting an existing workflow, so an agent has to infer some critical execution 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?

All four parameters are fully described in the input schema, so the baseline is 3. The description reiterates the role of target_workflow_id but adds no new meaning beyond what the schema already 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 states a specific action ('Restore a workflow from a local backup') with a clear resource and source. It further distinguishes the two operating modes (create new vs overwrite via target_workflow_id), which sets it apart from siblings like create_workflow, import_workflow, or update_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 gives internal branching guidance (default creates, target_workflow_id overwrites) but does not explain when to choose this tool instead of n8n_import_workflow, n8n_create_workflow, or n8n_update_workflow. No alternatives or disqualifying conditions 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?

With no annotations, the description carries the full burden and does well: 'Show' communicates non-mutating behavior, and it further discloses that the tool checks whether the optional n8n-workflow-manager seam is configured and reachable. It also states exactly what data will be returned, so an agent can expect a safe inspection call.

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 a single, front-loaded sentence that names the resource first and then lists the specific scopes covered. There is no repetition, filler, or unnecessary 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 zero-parameter status tool with no output schema, the description is complete: it identifies the operation, the resource, and every category of information the tool reports. An agent has enough to invoke it correctly and understand what it will return.

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 is empty, with zero parameters, so there is no parameter ambiguity to resolve. The 0-parameter baseline applies, and the description adds no parameter details because none are needed.

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 uses the verb 'Show' with a specific resource and enumerates the exact content: safety settings, backup directory, audit log location, and seam status. This clearly differentiates it from mutating siblings like n8n_set_safety_mode and from history/backup-listing tools.

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 gives clear context for a read-only status inspection: use it when you need the current safety settings, backup directory, audit log location, or seam reachability status. It does not explicitly name alternatives or exclusions, but the 'Show' framing contrasts naturally with the mutating n8n_set_safety_mode sibling.

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?

With no annotations, the description carries the full burden of behavioral disclosure, but it only restates the setting names. It does not mention side effects such as read_only blocking operations across tools, backup_before_mutations triggering exports, or audit_log appending to a file. Some of this appears in parameter descriptions, but the main description adds no behavioral context.

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

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

The description is a single well-structured sentence with a colon-led list that front-loads the tool's purpose. Every word earns its place and there is no filler or repetition.

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

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

For a low-complexity tool with three optional booleans and full schema descriptions, the description plus schema is largely sufficient. The only notable gap is that the description does not state whether the settings persist or apply globally to all subsequent tool calls, but the parameter descriptions compensate for most practical ambiguity.

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 coverage is 100% and each boolean parameter already has a meaningful description explaining its effect, so the baseline is 3. The description merely lists the parameter topics without adding default values, interactions, or invocation-level 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 uses a specific verb ('Configure') and a clear resource ('local safety settings'), and enumerates the three settings: read-only mode, backup-before-mutation, and audit logging. The tool name also distinguishes it from the sibling n8n_safety_status, though the description does not explicitly contrast them.

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 n8n_safety_status or other siblings. There are no prerequisites, exclusions, or conditions such as 'use this before running mutations' or 'check n8n_safety_status to view current settings'.

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?

No annotations are provided, so the description must fully disclose behavior. 'Update' indicates mutation, and 'Send the full updated workflow JSON' suggests a full replacement (PUT-like) operation. However, it does not disclose authentication requirements, idempotency, error handling, or side effects like version increments. Lacks depth for a mutation tool.

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

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

Two sentences with no redundancy: first sentence states purpose, second adds a critical usage constraint. Every word earns its place. Neither too short to be vague nor too long.

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?

No output schema, so the description should explain the return value (e.g., updated workflow object, confirmation message). It also omits behavioral details like whether the update merges or replaces fields. Given complexity of an update operation, more context is needed for complete understanding.

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% for all 3 parameters, providing clear descriptions. The description adds the constraint 'full updated workflow JSON', which reinforces the schema's description of workflow_json but does not add new semantic meaning beyond what the schema already 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?

Clearly states 'Update an existing n8n workflow' with specific verb and resource. Distinguishes from create, delete, and activate tools among siblings. The phrase 'Send the full updated workflow JSON' reinforces the nature of the update (full replacement), though it could be more explicit.

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 on when to use this tool vs siblings like n8n_create_workflow or n8n_activate_workflow. No prerequisites mentioned (e.g., workflow must exist, need to retrieve current version first). 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.