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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals only the state toggle itself and omits important behavioral traits: what activation actually enables (scheduled/webhook triggers), what happens to running executions upon deactivation, reversibility, or permission requirements.

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

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

A single, well-formed sentence with every word earning its place; the core toggle behavior is front-loaded and there is zero fluff. It is concise without being padded, though the brevity contributes to the under-specification noted in other dimensions.

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 two-parameter tool with 100% schema coverage, the description covers the basic call shape. However, it lacks the crucial conceptual distinction between activating a workflow (enabling triggers) and executing a workflow (running once), and says nothing about effects on in-flight executions or confirmation behavior, leaving an agent to infer n8n semantics.

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 baseline of 3 applies. The description adds marginal value by clarifying the 'active=false' case through the word 'deactivate,' which the schema only implies by saying 'True to activate,' but it provides no additional detail on ID format or state transition 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 uses a specific verb pair ('activate or deactivate') with a clear resource ('workflow'), and it adds the deactivation direction that the tool name alone doesn't convey. However, it doesn't distinguish itself from siblings like update_workflow, which could also modify workflow state, or execute_workflow, which runs a 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 provides no guidance on when to use this tool versus update_workflow or execute_workflow, no preconditions (e.g., the workflow must exist), and no exclusions. An agent cannot tell from the description whether activation means enabling triggers or something else entirely.

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 behavioral burden. It states that a backup snapshot is created but does not disclose whether the workflow itself is modified, whether repeated calls create multiple snapshots, how long backups are retained, or what response is returned.

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 with the action front-loaded and zero filler. Every word contributes to the core meaning and intended usage.

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 two-parameter tool with 100% schema coverage, this is minimally adequate for making the call. However, with no annotations and no output schema, the missing side-effect and return information leaves an agent unsure how to confirm the backup or reference it later when listing or restoring.

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%, and both workflowId and description have adequate schema-level explanations. The description adds no parameter-specific detail beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

States a specific verb and resource: 'Create a backup snapshot of a workflow'. The qualifier 'before making changes' clearly fixes its role and helps distinguish it from siblings like list_workflow_backups and restore_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?

Explicitly ties usage to a trigger: use this before making changes to a workflow. It does not name alternatives or exclusions, but the intended moment of use is unambiguous, making it easy for an agent to select.

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. It reveals that creation includes automatic schema validation, but it does not mention required permissions, failure behavior, whether credentials can be overwritten, or what the response contains. This is thin for a mutating 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?

A single sentence that starts with the action and resource, with zero filler. It is appropriately sized for a simple creation tool 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?

The tool has no output schema and no annotations, and creating a credential depends on type-specific schemas. The description does not tell the agent to consult get_credential_schema, does not explain validation failure outcomes, and does not describe what a successful response looks like. The schema covers parameters, but the surrounding context is incomplete.

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 input schema already documents all four parameters well. The description adds no parameter-specific meaning; 'automatic validation against schema' only reinforces the relationship between type and data without adding new 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 and resource: 'Create a new credential'. It clearly differentiates from update/delete/list/test credential siblings by indicating a creation operation, though it does not explicitly name an alternative 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?

No guidance is provided on when to use this tool versus get_credential_schema, test_credential, or update_credential. The mention of 'automatic validation against schema' hints at a prerequisite but the description never directs the agent to fetch the schema first or explains when this tool is preferred.

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, yet it only says 'Create a new workflow.' It fails to disclose what happens on success (returned ID or object?), the default active state, whether duplicate names are rejected, whether validation occurs at creation time, or any side effects. The basic create/mutate nature is implied, but nothing beyond that.

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 four words with the action front-loaded and zero wasted words. However, its brevity reflects under-specification rather than efficient richness — for a tool creating a complex workflow object with nested nodes, connections, and settings, it provides no structural information an agent could act on.

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 5 parameters including nested objects, no annotations, no output schema, and a large sibling family covering validation, import, and backup flows, a one-clause description is inadequate. An agent cannot determine the return value, whether name-only is truly sufficient to create a workflow, the default 'active' state, or how this differs from import_template.

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 baseline is 3 even though the description itself adds no parameter-level detail. The schema's own parameter descriptions are thin (e.g., 'Whether active' with no default; 'Array of node objects' without node structure), but the description does not compensate for or expand on any of that.

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 'Create a new workflow' states a verb and resource, and the 'create' verb minimally distinguishes it from siblings like update_workflow and delete_workflow. However, it is nearly a verbatim restatement of the tool name itself, adding almost no new information beyond the name already conveys.

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 on when to use create_workflow versus its many overlapping siblings such as import_template, validate_workflow_structure, or update_workflow. No exclusions, prerequisites, or conditions are mentioned, so the agent receives zero routing information.

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 burden of behavioral disclosure. It explicitly discloses the important safety behavior: deletion is blocked when the credential is in use unless the force flag is set. This is valuable context beyond the schema, though it does not mention irreversibility or permission requirements.

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

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

The description is a single sentence that is direct, front-loaded, and free of filler. It packs the core action and the critical safety behavior into minimal words 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 tool with only two simple parameters and no output schema, the description covers the essential behavior: deletion with a safety check and a force override. It could mention that deletion is irreversible, but the current description is sufficiently complete for an agent to understand the operation's core semantics.

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 id and force parameters well. The description's mention of 'unless forced' aligns with the force parameter but does not add new semantic detail beyond what the schema provides. Baseline 3 applies.

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 the resource ('a credential'), and adds the key distinguishing nuance of safety checks. It is unambiguous and differentiates this tool from sibling tools like delete_workflow or update_credential.

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 use case is implied: use this when a credential needs to be deleted. However, the description does not explicitly say when to use it versus other credential-related tools, nor does it mention prerequisites or caveats beyond the force behavior. The guidance is adequate but not 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?

With no annotations provided, the description carries the full burden of behavioral disclosure, yet it says nothing about irreversible destruction, cascading effects on executions or backups, prerequisites, or failure conditions. The verb 'delete' only implies destructiveness at the most surface level.

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 words with zero waste and the verb front-loaded, so it is maximally terse. However, the brevity comes from omitting needed behavioral and usage context rather than disciplined compression, so it is under-specified rather than appropriately sized.

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 annotations and no output schema, this is incomplete. It never addresses permanence, prerequisites (e.g., must the workflow be deactivated first?), consequences for associated executions or backups, or the existence of restore_workflow as a recovery path — all meaningful given the sibling tool 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% — the single required id parameter is documented as 'Workflow ID' in the schema — so the baseline is 3. The description adds no extra meaning about id format, provenance, or constraints, but the schema already handles this 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?

"Delete a workflow" is a verbatim restatement of the tool name delete_workflow — a tautology that adds no information beyond the name itself. It does state verb and resource, but any differentiation from siblings like update_workflow, activate_workflow, or delete_credential comes entirely from the name, not from the description.

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 on when to use this tool versus alternatives — no mention of deleting vs. deactivating, no indication that deletion might be permanent, and no reference to related tools like backup_workflow or restore_workflow. An agent must infer all usage context from the name alone.

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

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

No annotations are present, so the description carries the behavioral burden. It conveys non-mutating intent ('Compare'/'see what changed') and specifies the kind of change reported. It does not disclose output shape, directionality of the diff, or any limitations beyond node-level changes.

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 front-loads the action and resource, with a parenthetical adding the most useful outcome detail. No filler or redundant wording.

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 tool has no annotations and no output schema, so the description must cover purpose and expected outcome; it does state the outcome at a high level. However, it omits the return format and whether ID ordering matters, which an agent would need for fully confident use.

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 each parameter having a basic description. The tool description adds the node-change context but does not clarify semantic details such as whether backupId1 is the base and backupId2 is the target. Baseline 3 applies because the schema already handles 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?

States a specific verb ('Compare') and a specific resource ('two workflow backup versions'), and tells the agent what kind of result to expect ('nodes added/removed/modified'). This clearly differentiates it from backup, restore, and list backup siblings.

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?

Gives clear context: use this when you need to inspect differences between backup versions. It does not explicitly name alternatives or exclusions, but the intended use case is unambiguous and does not overlap with any sibling tool.

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 disclose the operation's behavior. It only says 'trigger a workflow' without explaining side effects, whether it starts an asynchronous execution, whether the workflow must be active, or what the response contains.

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 short and front-loaded, containing no filler. It loses a point because its brevity sacrifices useful contextual details that could be conveyed in one or two additional phrases.

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 side-effecting trigger operation with no annotations and no output schema, the description is too thin. An agent cannot know what happens after calling it, whether it returns an execution ID, or what conditions must be met.

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% and the single 'id' parameter is documented as 'Workflow ID'. The description adds no new parameter meaning, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('trigger') and names the resource ('workflow'), clearly indicating an execution action. The word 'manually' helps separate it from automated triggers like trigger_webhook, though it does not explicitly contrast with activate_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?

No guidance is given about when to choose this tool over siblings such as activate_workflow, trigger_webhook, or get_execution. 'Manually trigger' implies a use case, but there are no explicit conditions, 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Safe for sharing' adds genuine context — that output is sanitized for external distribution — which aligns with the schema's stripIds default true and includeCredentials default false. However, it's minimal: it doesn't warn that setting includeCredentials to true undermines the safety promise, nor does it describe output structure or side effects.

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

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

A single sentence that is front-loaded with the verb and resource, followed by a compact parenthetical that conveys the key safety trait. Zero wasted words, no repetition of schema content, and every element 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 tool with 3 params and 100% schema coverage, the essentials for making a correct call are present: workflowId is required and documented. But with no annotations and no output schema, the description could do more — it doesn't address how to choose this over backup_workflow, what the returned JSON template contains, or the security implication of the includeCredentials escape hatch. Adequate but with clear 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%, so all three parameters (workflowId, stripIds, includeCredentials) are already documented with meaningful detail, including defaults and the INSECURE flag. The description adds no parameter-level information beyond what the schema provides, so the baseline score of 3 applies.

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

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

The description states a specific verb ('Export'), resource ('workflow'), and output format ('JSON template'), which is clear and concrete. The 'safe for sharing' qualifier hints at differentiation from siblings like backup_workflow or get_workflow, though it doesn't explicitly name them. The name itself is sufficiently descriptive.

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 on when to use this tool versus alternatives such as backup_workflow, get_workflow, or import_template. 'Safe for sharing' implies a use case but stops short of stating when to choose this over a backup or a raw workflow retrieval. An agent must infer the selection criteria from the tool name alone.

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

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

There are no annotations, so the description carries the behavioral burden. The verb 'Get' conveys read-only behavior, and 'before creating it' suggests no side effects, but the response format, error behavior for unknown credential types, and permissions are not disclosed. This is adequate but minimal.

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 concise sentence with no filler. The purpose is front-loaded ('Get required fields and structure') and the usage context ('before creating it') is appended efficiently.

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 single-parameter schema lookup tool, the description covers the essential context: what is retrieved and when to use it. There is no output schema, but the description's 'required fields and structure' gives enough shape expectation; more detail on the returned object would be nice but not necessary for correct invocation.

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 fully describes the single 'credentialType' parameter with examples. The description adds no further parameter-level detail, which is acceptable because schema coverage is 100% and no additional semantic burden falls on the description.

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'), the resource ('credential type'), and the deliverable ('required fields and structure'). It is easily distinguished from sibling tools like create_credential or get_node_schema because it explicitly targets credential-type schema retrieval.

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 'before creating it' gives clear temporal context, telling an agent to call this before create_credential. It does not explicitly mention alternatives or when not to use it, but the context is strong enough for the main use case.

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 transparency burden. 'Get full details' signals a read-only lookup and suggests richer output than a list. It does not disclose what specific details are returned, error behavior, or execution state handling, but for a simple getter this is a moderate 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?

A single concise sentence that front-loads the action ('Get'), the resource ('specific execution'), and the purpose ('for debugging'). Every word earns its place with no redundancy.

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

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

For a tool with one required parameter and no output schema, the description is mostly sufficient: it tells the agent what to get, why, and implies the value scope. It could be more explicit about what 'full details' contains, but the simple surface area keeps the missing context manageable.

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%: the only parameter, id, is described as 'Execution ID.' The description adds no new parameter semantics beyond 'specific execution,' so the schema already 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 uses a specific verb and resource: 'Get full details of a specific execution.' It clearly establishes what the tool does and implies a read operation. It doesn't explicitly contrast itself with list_executions or get_workflow, but the scope is distinct enough from siblings.

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 'for debugging' implies when this tool should be used, giving some context. However, it provides no explicit guidance on when not to use it or how it relates to list_executions as an alternative.

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 carry the behavioral disclosure burden. The verb 'Get' clearly implies a read-only operation, but the description does not explicitly state safety, error behavior, or what the returned schema looks like. It is adequate for a simple retrieval but lacks deeper 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 short sentences with no filler. The core purpose is front-loaded, and the usage guidance follows immediately. Every word 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 single-parameter read-only tool with no output schema, the description covers the essential information an agent needs to decide to call it and to provide the parameter. It could mention the return format or the fact that it returns a JSON schema, but this is a minor gap given the tool's simplicity.

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 already provides 100% coverage for the single parameter nodeName, including type and examples. The description adds minimal value beyond confirming that the parameter identifies a node type; it does not introduce new meaning not already 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 states a clear verb (get), a specific resource (parameter schema for an n8n node type), and the intent (understand inputs/options). It is distinct from siblings like get_credential_schema by focusing on 'node type', though it does not explicitly name alternatives.

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

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

The phrase 'Use this to understand what inputs/options a node accepts' gives a clear context for when to invoke the tool. However, it does not mention when not to use it or contrast it with related tools such as get_credential_schema or list_node_types.

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 carry the behavioral disclosure burden. The verb 'Get' implies a read-only operation, and 'full workflow JSON' indicates the return type, but it does not explicitly state side effects, authorization requirements, error behavior, or that it does not modify the template. This is adequate for a simple retrieval but lacks depth.

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 of seven words: 'Get full workflow JSON for a template'. Every word carries meaning, with no filler or redundant statements. It is concise without sacrificing 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 one-parameter getter, the description plus schema provide the essentials: what the tool returns and what input it needs. However, it lacks contextual completeness regarding the relationship between templates and workflows, when to use this over 'get_workflow' or 'export_workflow_as_template', and what 'full workflow JSON' includes. The absence of an output schema increases the need for more context, which is not provided.

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%, and the 'id' parameter is already documented as 'Template ID from search results'. The tool description adds no extra meaning about the parameter or its format. Baseline 3 is appropriate since the schema carries the semantic weight.

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 ('Get') and resource ('full workflow JSON for a template'), making the primary function clear. It is distinguishable from siblings like 'get_workflow' by the focus on templates, but it does not explicitly differentiate itself from related tools such as 'search_templates' or 'import_template'.

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. The description only states what it does, not the context or conditions under which it should be selected. Sibling tools like 'search_templates' and 'import_template' are not mentioned, leaving the agent to infer when this is the appropriate choice.

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. 'Get detailed information' clearly indicates a read-only retrieval operation rather than a mutation, and it names the returned content categories. However, it does not disclose behavior around missing IDs, permission requirements, response format, or whether the result includes resolved expressions or credentials. It is adequate for a simple read, but there are clear gaps.

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 wasted words. It states the action, the resource, and the scope of returned information compactly and clearly.

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 one-parameter get operation with no output schema, the description is reasonably complete: it identifies the resource and the main categories of returned data. It could be slightly stronger by explicitly mentioning that it returns the full workflow object or that it is non-mutating, but the essentials for correct invocation are present.

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% because the only parameter, 'id', has a description ('The workflow ID'). The tool description adds no parameter-level meaning beyond the schema, so the baseline of 3 applies. There is nothing misleading, but also nothing extra.

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 ('Get'), a clear resource ('a workflow'), and the scope of the detail ('nodes, connections, settings'). This distinguishes it from the sibling list_workflows, which presumably returns a summary/collection, and from get_execution, which targets executions rather than 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 use when a caller needs full detail about a specific workflow, but it does not explicitly say when to prefer this over list_workflows or when an alternative such as get_execution would be more appropriate. The usage context is present only by implication, not by explicit guidance 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'dependency resolution' but does not explain what that entails, whether the imported workflow is created active or inactive by default, whether credential mapping is required, or what the tool returns on success. The description is too thin for a creation-type 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 a single, front-loaded sentence with no filler or redundant information. Every word contributes to conveying the core action and a key behavioral nuance.

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 no annotations and no output schema, the description should provide more context about return behavior, default import state, credential requirements, and failure modes. The vague 'dependency resolution' phrase does not fill those gaps, so the tool is not sufficiently described for an agent to invoke it with full confidence.

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 documents all four parameters with 100% coverage, so the baseline is 3. The description's 'dependency resolution' phrase gives some conceptual context for credentialMapping and skipNodeValidation, but it does not add substantial parameter-level detail 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 ('Import template') and result ('as new workflow'), with the additional qualifier 'with dependency resolution' that separates it from generic workflow creation tools. It clearly identifies the tool's unique purpose among siblings like create_workflow and export_workflow_as_template.

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 the tool should be used when a user wants to instantiate a new workflow from a template, but it does not explicitly state when to prefer this over create_workflow or how it relates to search_templates/get_template_details. There is no guidance on when not to use it or what preconditions must be met.

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 disclosure burden and does it well: it lists the exact checks performed and the return shape (score and issues). It stops short of explicitly stating that the operation is non-mutating, though 'lint' idiomatically implies read-only static analysis, and it does not describe the internal structure of individual issues.

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 compact sentences with zero filler: the first states the core purpose, the second packs in the check list and return format. Everything present earns its place, and the most identifying information is front-loaded.

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 single-parameter design and lack of output schema keep the burden modest, and the description covers the checks and return shape. However, it omits details about what an issue object contains (severity, node reference, type) and does not clarify the boundary against sibling validation tools, leaving meaningful ambiguity in the validation sibling cluster.

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 baseline of 3 applies. The schema already documents the 'workflow' parameter with required name and nodes plus optional connections. The tool description adds nothing about the parameter itself, focusing instead on the lint checks, which is acceptable given the schema already carries that weight.

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 ('lint') and resource ('workflow'), enumerates five concrete check categories (orphaned nodes, missing error handling, generic node names, hardcoded secrets, loop limits), and specifies the output (score 0-100 plus issue list). This scope clearly differentiates it from the validation siblings, which target structure, credentials, and expressions rather than best-practice scoring.

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 usage context is implied: a workflow object is passed in and evaluated against best practices, which signals a quality-review use case. However, there is no explicit when/when-not guidance or named alternatives, and with closely related siblings like validate_workflow_structure and suggest_workflow_improvements, an agent must infer which tool is appropriate for which scenario.

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 reasonably well: 'List' signals a non-mutating operation and the parenthetical reveals an important implementation trait—credentials are combined from workflows and a database fallback. It stops short of describing edge cases or output shape, but the core behavior is transparent.

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 dense sentence, front-loaded with the verb and resource, with the clarifying sourcing detail in parentheses. 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 low-complexity list tool with one optional parameter and no output schema, the description is nearly complete: it states scope, source, and default behavior. It would only need explicit output/return details or failure semantics to be fully 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%, and the only parameter (type) is already documented as an optional filter with an example. The tool description adds no extra parameter meaning beyond its 'all credentials' default, so baseline 3 applies.

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 operation ('List') and a clear resource ('all credentials available in n8n'), and adds a useful provenance detail ('parsed from workflows + database fallback'). This distinguishes it from sibling tools like get_credential_schema, create_credential, or delete_credential.

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?

It clearly indicates this is for enumerating credentials, giving context that this is the listing entry point. It does not explicitly name alternatives or exclusion cases, but the read-only listing intent is unambiguous and no conflicting sibling does the same thing.

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 behavioral disclosure. It only says 'recent' without explaining ordering, time range, default limit behavior, or whether execution data is included by default, leaving important behavioral expectations unstated.

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 concise sentence with no filler or repetition. It is efficient, though its brevity comes at the cost of behavioral and parameter detail.

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 4 parameters, no output schema, and no annotations, the description is too sparse to fully equip an agent to invoke the tool correctly. It omits filter semantics, default values, output shape, and sorting/recency behavior, leaving significant 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 coverage is only 50%, and the description does not clarify the undocumented parameters 'limit' and 'status'. It adds no meaning beyond the schema for workflowId and includeData, so it fails to compensate for the parameters that lack descriptions.

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 ('List') and resource ('workflow executions') with the intended purpose of checking status. It is clear enough to distinguish from siblings like get_execution (single execution) and list_workflows (different resource), though it does not explicitly name those alternatives.

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 'to check status' implies the intended use case, which helps an agent decide when to call this tool. However, there is no explicit guidance on when not to use it, such as when a single execution's full details are needed via get_execution.

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 burden. It clearly implies a read-only listing operation and avoids claiming side effects, but it does not disclose output shape, pagination, or whether only core nodes are included.

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, direct sentence with no filler. The subject, action, and scope are all front-loaded and every word 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 zero-parameter enumeration tool, the description is largely complete: it states the operation and scope. It lacks return-format details and explicit differentiation from get_node_schema, but the simplicity of the operation keeps those gaps minor.

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 takes zero parameters and the input schema is empty, so there are no parameter semantics to document. The baseline for zero-parameter tools is 4, and the description adds nothing misleading.

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 and resource: 'List available node types' scoped to 'this n8n instance.' It clearly communicates enumeration rather than details, though it does not explicitly contrast with sibling get_node_schema.

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?

Usage context is implied: use this when you need to enumerate the available node types in the current n8n instance. However, it does not explicitly say when to prefer get_node_schema for schema details or mention any 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?

With no annotations provided, the description carries the full burden. It clearly indicates a read-only behavior (listing backups) and specifies the return contents (timestamp, size, description). It does not mention ordering, pagination, or potential side effects, but for a simple list operation these are minor gaps that do not undermine correctness.

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, front-loaded sentence that conveys the action, the resource, and the output contents with no filler. Every word contributes useful meaning.

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 one-parameter list tool with no output schema, the description is sufficiently complete. It tells the agent what to call, what input is needed (schema covers it), and what kind of results to expect. Nothing required for correct invocation is 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?

Schema description coverage is 100%, so the schema already documents workflowId with a clear definition. The description adds nothing about parameter formats, defaults, or constraints beyond what the schema states, so the baseline score of 3 applies.

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

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

The description states a specific verb ('List') and resource ('backup versions for a workflow'), and adds the metadata components returned. This clearly distinguishes it from siblings like list_workflows, diff_workflow_versions, and restore_workflow without needing to inspect the schema.

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 intended use is implied: call this when you need to list backup versions for a workflow. However, there is no explicit guidance about when not to use it, such as 'to compare versions use diff_workflow_versions' or 'to restore use restore_workflow'. Context is clear but no alternatives or exclusions are provided.

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 full burden of behavioral disclosure. It does not state that this is a read-only operation, what the return shape looks like, whether pagination or limits apply, or how filters affect the result. The verb 'List' implies reading, but little else is 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?

The description is one short sentence with no redundant title repetition or filler. The core action and resource are front-loaded, making it 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?

The tool is a simple list operation with three optional parameters, and the schema covers those parameters. However, with no output schema and no annotations, the description could usefully mention return value or pagination behavior to be fully complete; it is minimally adequate but not rich.

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 descriptions of tags, limit, and active already document the parameters. The main description adds no further meaning beyond the implicit notion that filters narrow the list, which keeps it at 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 uses a specific verb ('List') and resource ('workflows') with scope ('in n8n'). It is clearly distinct from sibling tools like get_workflow (single item) and list_executions (different resource), so an agent can identify the operation without opening the schema.

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 choose this tool over get_workflow, list_executions, or the other workflow operations. The description only states the action and provides no exclusions, prerequisites, or selection criteria.

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 does disclose a non-obvious side effect: it auto-backups the current state before restoring. However, it does not explicitly state that the current workflow will be overwritten, nor mention permissions, irreversibility, or result behavior beyond that.

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 concise sentence with the action and primary target front-loaded. The parenthetical adds a critical behavioral safety note without padding 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 relatively simple three-parameter operation with no output schema, the description covers the core purpose and the main side-effect concern. It could be more complete by noting that the current workflow is replaced and that the backupId is obtained from list_workflow_backups, but enough is present for a correct call.

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 documents all three parameters at 100% coverage, including the default for autoBackupCurrent. The description's parenthetical about auto-backing up adds context but does not explain parameter 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 uses a specific verb ('Restore') and resource ('a workflow to a previous backup version'), making the operation unmistakable. It also distinguishes itself from related sibling tools like backup_workflow, list_workflow_backups, and diff_workflow_versions by naming a distinct action.

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 context for use is clear: use this tool when you need to revert a workflow to an older backup. It does not explicitly name alternatives or when-not-to-use conditions, but the action is unambiguous and no competing sibling performs the same revert operation.

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 behavioral disclosure. It only restates the search action without mentioning that this is a read-only operation, what the results contain, whether pagination or rate limits apply, or that the search accesses an external n8n.io endpoint.

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, efficient sentence with no filler. The verb and resource are front-loaded, and every word contributes to the purpose.

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 search tool with a fully documented schema, this is minimally adequate. However, with no output schema, the description does not mention what a search result looks like, whether results are paginated, or that get_template_details can be used to fetch full template information — information an agent would likely need to use the tool 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%, and both parameters already include useful examples ('github slack', 'Development'). The tool description adds no parameter-level meaning beyond contextualizing the search target as the n8n.io template library, so the baseline of 3 applies.

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?

States a specific action ('Search') and a specific resource ('n8n.io template library') with a clear object ('workflow templates'). This distinguishes it from siblings like get_template_details, which retrieve details of an already-identified template, and list_workflows, which operates on user 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 gives no guidance on when to use this tool versus alternatives such as get_template_details or import_template, and it does not state when not to use it. Usage context is only implied by the tool name and brief description.

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 meaningful behavioral detail by listing exactly which types of issues the tool identifies, and 'suggest' implies a non-mutating analysis. It stops short of stating the return format or explicitly confirming that the workflow is not modified, but for a suggestion tool this is adequate.

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

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

The description is two compact sentences with the action front-loaded. The detailed list of improvement categories is dense and useful without filler, and 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?

The tool is simple: one required workflow object, with the input schema already documenting the required structure. The description gives enough detail about what the analysis covers for an agent to invoke it correctly. The main gap is the lack of an explicit return shape, but the 'Identifies: ...' list partially fills that gap given there is no 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?

Schema coverage is 100%: the single workflow parameter is already described as 'Workflow object to analyze' and the nested schema defines required fields like name and nodes. The description adds no additional parameter-level meaning beyond what the schema already provides, so the baseline of 3 applies.

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 ('Analyze workflow and suggest improvements') and enumerates the concrete improvement categories it detects: missing Set nodes, error handling, slow loops, hardcoded values, triggers, and merge nodes. This clearly distinguishes it from sibling validation and linting tools, which check conformance rather than propose improvements.

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 intended use case is strongly implied: call this when the agent needs improvement suggestions for a workflow. However, the description never explicitly says when to prefer it over validate_workflow_structure, lint_workflow, or execute_workflow, and it does not state any exclusions or alternative conditions.

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 bears the full burden and does disclose an important side effect: a temporary workflow is created, and the operation is heavy. It stops short of describing cleanup, permissions, or whether the workflow persists, but the key behavior is revealed.

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 compact sentence communicates the action, the mechanism, and a cost warning with no filler. The warning is placed at the end as an appositive, keeping the core purpose front-loaded.

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 one-parameter tool, the description covers purpose, side effect, and cost. With no output schema, a little more context about the result format (e.g., boolean, thrown error) would make it fully complete, but nothing essential for invoking it is 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?

Schema coverage is 100% and the single parameter has a clear description ('Credential ID to test'), so the schema already carries the meaning. The tool description adds no additional parameter-level detail, matching 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 identifies the operation ('Test credential validity') and its mechanism ('creating a temporary workflow'), so the purpose is specific and understandable. However, it does not explicitly differentiate this from related siblings like validate_workflow_credentials or get_credential_schema.

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 'heavy operation - use sparingly' note gives clear practical guidance and warns against overuse. It does not name alternatives or state when not to use the tool, which prevents a 5.

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 must disclose behavioral traits. It only says the tool 'triggers' an endpoint 'for testing', without explaining side effects, whether the request actually fires, response behavior, or failure handling. The external side effect of triggering a webhook is a significant undisclosed trait.

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. Every word adds meaning, and it delivers the core purpose immediately.

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 tool with six parameters, no annotations, and no output schema, this one-line description is not enough. It omits invocation semantics beyond the schema (e.g., how webhook_path maps to a target, whether the request is actually sent, what the response contains) and leaves the agent guessing about expected outcomes.

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 83%, so the schema already documents webhook_path, body, method, headers, test_mode, and query_params. The description adds no parameter-level meaning beyond what the schema provides, so it meets the baseline but does not exceed it.

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 action ('Trigger') and a specific resource ('webhook endpoint'), and adds the purpose 'for testing'. None of the sibling tools target webhooks, so there is no ambiguity with workflow or credential 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 gives no guidance about when to use this tool rather than a sibling such as execute_workflow, and no exclusions or prerequisites are stated. An agent is left to infer the intended context from the tool name alone.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only conveys that this is a mutation operation. It does not mention whether data is merged or replaced, whether nodesAccess is overwritten wholesale, what happens if the id does not exist, or whether any validation is performed. This is a significant gap for a write 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 a single sentence with no filler. It front-loads the action and resource, then lists the updateable attributes. Every word 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?

There is no output schema and no annotations, and the tool involves a nested object and an array parameter. The description tells the agent what the tool does but not how updates behave (partial vs full replacement), what constraints apply, or what the result will look like. For a mutation tool, this is incomplete guidance.

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 each parameter. The description adds marginal value by summarizing the updateable fields, but it doesn't clarify the relationship between id and the other fields or the semantics of nodesAccess beyond what the schema says. 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 uses a specific verb ('Update') with a clear resource ('existing credential') and enumerates the exact updateable aspects (name, data, node access). This cleanly distinguishes it from create_credential, delete_credential, and test_credential without needing to open the schema.

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 'Update an existing credential' implies this is for modifying already-created credentials rather than creating or deleting them, but it does not explicitly name alternatives or state when not to use it. Sibling tools exist but are not referenced, so usage guidance is only implicit.

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 full burden of behavioral disclosure. It only says 'update an existing workflow' and gives no information about whether updates are partial patches or full replacements, whether omitted fields are reset, whether validation runs, whether changes are reversible, or what the mutation's side effects are.

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 with no wasted words, but it is severely under-specified for a tool with six parameters and nested objects. There is no structure, no parameter guidance, and no behavioral context, so the brevity is a weakness, not a strength.

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, no output schema, low schema description coverage, and many related sibling tools, this description is completely inadequate. The agent cannot determine correct invocation behavior, expected effects, or how to interpret 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 only 17%, with only 'id' documented as 'Workflow ID'. The description adds no parameter-level meaning, so the agent gets no help understanding the semantics of 'nodes', 'connections', 'settings', 'active', or whether a partial update is allowed.

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 verb ('update') and resource ('existing workflow'), which distinguishes it from sibling tools like create_workflow and delete_workflow. However, it does not mention what aspects of the workflow can be changed, so it is not fully differentiated from activate_workflow or validate_workflow 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?

No guidance is provided about when to use this tool versus alternatives. It implies the workflow must already exist and need modification, but there is no mention of exclusions, prerequisites, or relationship to create_workflow, activate_workflow, or validate_workflow_structure.

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. It explains what is checked (credential ID existence, type matching, optional validity testing), but it omits how results are returned (success/failure, errors), whether side effects such as network calls occur, and error behavior on invalid credentials.

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 concise sentences with the purpose front-loaded. The checks are listed in a compact, scannable manner 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?

The inputs and validation checks are adequately described for a tool of this complexity. However, with no output schema and no annotations, the description leaves out crucial details about the return format and behavior on failure, which an agent needs to invoke it correctly and interpret results.

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 baseline is 3. The tool description adds meaningful detail beyond the schema by specifying what the workflow object will be validated against ('credential IDs exist, credential types match node requirements') and clarifying that testCredentials triggers validity testing, enriching the generic schema descriptions.

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?

Description states a specific verb ('Validate') and resource ('workflow credentials') with a contextual phase ('before deployment'), and enumerates concrete checks. It is clearly distinct from sibling validation tools like validate_workflow_structure and validate_workflow_expressions, though it does not name alternatives explicitly.

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?

'Before deployment' provides clear contextual guidance for when this tool is appropriate. It does not list when-not-to-use or explicit alternatives, but the described checks define its domain well enough for an agent to select it over other validators.

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. It does reveal that the tool checks syntax, validates variable references, and warns about complex logic, indicating a non-mutating analysis. However, it does not state whether the tool modifies the workflow, what a response looks like, or whether any permissions are required.

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 with no filler: the first states purpose and target, the second lists checks in a scannable format. The most important information is front-loaded.

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 explains what the tool validates and hints at output through 'warns', but there is no output schema and no explicit description of the return value. It also omits any reference to sibling validation tools, leaving tool-selection partially to inference. For a single-parameter validation tool this is a noticeable but not severe 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?

The input schema has 100% coverage with a description for the only parameter ('Workflow object to validate'), and the tool description adds no parameter-level detail beyond the schema. The baseline of 3 applies because the schema already documents the parameter 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 uses a specific verb ('Validate') and a precise target ('n8n expressions {{ }} in workflow'), then lists three concrete checks: syntax errors, variable references, and complex-logic warnings. This clearly distinguishes it from sibling validators like validate_workflow_structure and validate_workflow_credentials even without naming 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?

The description implies this tool should be used when workflow expressions need validation, but it never explicitly states when to use it over validate_workflow_structure or validate_workflow_credentials, nor does it mention any exclusions. The usage context is inferable from the checks listed, but no direct guidance is provided.

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. It does disclose substantive behavioral content by listing 7 categories of checks the validation performs, which tells the agent what the tool will inspect. However, it omits outcome semantics entirely: whether validation failure throws an exception or returns a report, and whether the tool has any side effects. For a pre-deployment gate, the agent needs to know how to consume the result to decide whether to proceed.

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 zero wasted words. The first sentence front-loads purpose and timing; the second delivers a compact, high-signal enumeration of checks. Every clause 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 single-parameter tool with fully documented schema and a thorough check list, the description is nearly complete. The notable gap is the absence of an output schema or any description of return values/failure behavior, which matters for an agent using this as a validation gate. But the description covers purpose, timing, and scope thoroughly, so it earns a 4 rather than a 3.

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 baseline is 3, but the description adds real meaning beyond the schema's minimal 'Workflow object to validate.' The check list communicates semantic requirements on the nested workflow fields (node IDs must be unique, node types must be valid, connections must reference valid endpoints, no circular dependencies), which helps the agent construct a valid input or predict what the validator enforces.

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-action pair ('Validate workflow structure') with an explicit purpose ('before creation/deployment to catch errors early'). The enumerated check list (required fields, unique node IDs, valid connections, circular dependencies, trigger nodes) makes the scope unmistakable and clearly distinguishes it from sibling validation tools like validate_workflow_credentials and validate_workflow_expressions.

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 states when to use the tool: 'before creation/deployment to catch errors early.' This is clear timing guidance. However, it does not explicitly name alternatives or state when NOT to use it versus the overlapping siblings lint_workflow or validate_workflow_expressions, so it stops short of a 5.

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