NoClick

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

Annotations are all false, providing no safety hints, so the description carries the full burden. It discloses that the tool saves the result (mutation) but does not explain side effects like overwriting existing fields, reversibility, or permission requirements. The internal engine is mentioned but not elaborated. For a write operation, this is insufficient 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?

The description is compact and front-loaded with the core purpose. It uses a colon to introduce modes and a dash to clarify intent. It avoids redundancy and each sentence adds information, though the mode enumeration could be seen as slightly dense.

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 an output schema present, return values need not be explained, but the description does not mention error handling, prerequisites (beyond required params), or what happens if the node is already filled. The goal-driven aspect is mentioned but not elaborated enough to guide selection of modes. Some gaps remain for a mutation tool, but the output schema mitigates missing return details.

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 0%, so the description must explain parameters. It does explain mode and its values, and that single_field requires target_field. However, it does not detail what each mode fills beyond the labels, nor clarify the roles of workflow_id and node_id beyond obvious identification. It adds some meaning but does not fully compensate for the schema's lack of 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 clearly states the action (auto-fill) and the resource (a node's operation and/or config), and explains the mechanism (Pass 2/3 engine). It differentiates from sibling tools by being the only one that auto-fills node fields, and it explicitly mentions the offload intent. The modes are listed, giving concrete scope.

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

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

It gives context ('offload a hard node instead of hand-authoring every field') and implies when to use it. However, it does not explicitly name alternatives or state when not to use it, such as when manual control is preferred. The goal-driven mention adds context but lacks explicit exclusion 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?

The description warns that the credential is not live until the user finishes the link flow, but it doesn't disclose whether calling the tool creates a pending request or has any other side effects. No permission, rate, or error behavior is mentioned.

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?

Description is compact and organized with a use-case note after the core action. The capitalized 'CONNECT' and parenthetical details add a little noise but not enough to hurt.

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?

Covers the key preconditions and postcondition (search_credentials after), but leaves parameter semantics and potential side effects unresolved. Enough to understand the tool's role, but not fully self-contained for 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 prose mentions node type and credential type, but does not clarify which parameter is which, whether either is required, or the expected values. Since the schema has no parameter descriptions, the ambiguity is not resolved.

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

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

Clearly states the action (get a link to connect a credential) and the resource (OAuth/API key for node/credential type). It distinguishes from search_credentials by specifying the use case when no credential is connected yet.

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 gives a use condition and directs to re-check with search_credentials after the flow. It doesn't enumerate all alternatives, but the primary alternative is referenced and the condition is actionable.

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

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

The description conveys the primary side effect (creating a snapshot) and its non-destructive nature, but does not clarify whether an existing checkpoint with the same name is overwritten or if any additional side effects occur. Annotations provide no further detail, so the description carries the burden but falls short on edge cases.

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

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

The description is concise—two sentences, front-loaded with the action and purpose. No extraneous words or filler.

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

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

Given the existence of an output schema (per context signals), the description covers the main intent, usage, and outcome sufficiently. It lacks explicit handling of name conflicts or failure modes, but these are not strictly required for a basic understanding. The description is complete enough for an agent to decide when and how to use it.

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 has zero descriptions for parameters. The description indirectly implies workflow_id ('current workflow') and name ('named checkpoint'), but the optional 'description' parameter is never mentioned. It does not fully compensate for the lack of schema documentation.

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

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

The description clearly states the verb 'Snapshot' and the resource 'current workflow', and explains the purpose: creating a named checkpoint for later restoration. The added context about using it before risky edits reinforces the intent.

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 provides a usage scenario: 'Use before a risky batch of edits so you can roll back.' This tells the agent when to invoke the tool and distinguishes it from related tools like restore_checkpoint.

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

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

The description mentions that the tool returns the new workflow's id, which is useful behavioral information. However, it does not disclose side effects such as which workspace the workflow is created in or any permission requirements. The annotations are present but do not provide much detail beyond the basic flags.

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 that directly states the action and output. It is well-structured and to the point, with no unnecessary information.

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

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

While an output schema exists and the description notes the return id, it omits important context such as the required name parameter, the meaning and default of visibility vs organization_permission, and where the workflow is created. The tool description is too sparse to give a complete picture of how to call it correctly.

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

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

The description provides no explanation of the five parameters (name, folder_id, visibility, description, organization_permission). With 0% schema coverage, the description fails to compensate by describing parameter meanings, defaults, or constraints.

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

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

The description clearly states the verb 'create' and the resource 'workflow', specifying that it is a new empty workflow. This distinguishes it from sibling tools like update_workflow, delete_workflow, and get_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 provided on when to use this tool versus alternatives. It does not mention scenarios where creating a workflow is appropriate or where other creation tools (like create_checkpoint) should be used instead.

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

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

The annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds the statement 'This is irreversible,' which reinforces the destructive nature but doesn't add substantial new behavioral detail beyond what annotations already convey. It does not contradict the annotations, so the baseline of 3 is appropriate given the low bar set by annotations.

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

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

The description is two short sentences with no filler. It front-loads the action and then the critical warning about irreversibility. Every word earns its place, making it highly efficient.

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

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

Given the simplicity of the tool (one required parameter) and that the annotations cover destructive and idempotent behavior, the description is minimal but not wholly incomplete. It does not mention potential side effects like cascading deletions of related checkpoints or executions, nor does it clarify behavior for non-existent ids. However, with the output schema present and the low complexity, it's acceptable but not thorough.

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 has 0% description coverage, so the description must compensate. However, the description only says 'by id,' which is redundant given the parameter name 'workflow_id.' It provides no additional context about the format, how to obtain the id, or any special constraints. This adds minimal value beyond the schema itself.

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

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

The description states a specific verb ('Delete'), a clear resource ('workflow'), and the identifier ('by id'). This unambiguously distinguishes it from sibling tools like create_workflow or update_workflow. The action is perfectly clear with no ambiguity.

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

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

The description offers no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. It only notes that the action is irreversible, which is a safety warning rather than usage context. An agent has no explicit direction on when deletion is appropriate.

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

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

The description discloses key behavioral traits: execution context ('runs in the iframe's context'), access level ('full DOM access'), and return value plus side effects ('captures async side effects'). This goes beyond the annotations, which only indicate readOnly and destructive flags.

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 long, front-loaded with the core action, and then provides relevant examples and output details. No unnecessary words, and the structure logically guides from purpose to use to expected behavior.

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?

While the description covers what the tool does and what it returns, it omits crucial context about the parameters (especially the optional node_id and workflow_id) and does not address potential errors or limitations. An agent may not know how to specify the target interface or workflow.

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 has 0% description coverage, and the description does not mention any of the three parameters (node_id, expression, workflow_id). Without explanation, an agent cannot infer their meanings or relationships, so the description fails to compensate for the lack of schema detail.

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

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

The description clearly states the tool's purpose with a specific verb ('evaluate') and resource ('interface node's iframe'), and provides concrete examples of usage. It distinguishes itself from sibling tools like get_node or update_interface by focusing on direct DOM interaction.

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 says when to use it ('Use this to interact with rendered interfaces') and gives specific use cases like clicking buttons, typing, and reading DOM. It does not explicitly contrast with alternatives, but the examples make the intended scope clear.

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, covering the primary behavioral aspect. The description does not add extra context beyond that (e.g., rate limits, auth needs), but it does not contradict the annotations either. Since the annotation bar is lower, a baseline score of 3 is appropriate.

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, no redundancy, and the main purpose is front-loaded. The mention of the return shape is concise and the annotation about search_operations is integrated naturally. No filler words.

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

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

For a simple tool with one parameter and no output schema, the description is complete: it states functionality, usage context, the parameter's purpose, and the return format. It also provides a sibling alternative, making it self-sufficient for an agent to decide correctly.

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

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

The schema has one parameter 'query' with type string and default. The description adds meaning by stating it is optional and filters by name, which goes beyond the schema's minimal definition. Given the high coverage (100% of parameters are mentioned), the added semantics earn a score above 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?

Clearly states it returns all ~65 node types with labels, and distinguishes itself from search_operations by indicating that for finding a node+operation for an intent, one should prefer search_operations. The verb 'Returns' is specific, and the resource (node types) is unambiguous.

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

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

Explicitly states when to use the tool ('Use to BROWSE the catalog') and when not to (prefer search_operations for intent-based lookup). This provides direct guidance on tool selection with no ambiguity.

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

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

The readOnlyHint annotation already establishes the non-destructive nature. The description reinforces the read-only aspect by saying 'Get', but it does not add additional behavioral details such as potential empty results or limits beyond what the schema provides.

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, direct, and free of redundant information. It conveys the core purpose and typical use cases without unnecessary elaboration.

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

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

The description covers the basic purpose and general use cases, but it lacks parameter explanations and does not mention the output schema. Since an output schema exists, not detailing return values is acceptable, but the absence of parameter details leaves some context gaps.

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

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

The schema has no parameter descriptions and the description does not elaborate on the meaning of 'level', 'limit', or 'workflow_id'. While parameter names are somewhat intuitive, without explicit explanations the semantics are not fully clarified, especially given the schema coverage is 0%.

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

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

The description clearly states the tool retrieves recent console output from interface node iframes, with a specific verb and resource. It mentions debugging use cases but does not explicitly differentiate from sibling tools like get_sdk_logs, though the 'interface node iframes' scoping provides reasonable distinction.

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

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

The description gives context on when it is useful (debugging rendering issues, runtime errors, SDK call results) but stops short of explicitly stating when to use this tool versus alternatives. It implies usage scenarios but does not provide clear 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?

Discloses the non-error fallback to the most-recently-updated workflow when no browser session exists and notes the _fallback/_warning flag. This goes beyond the readOnly annotation and gives agents accurate behavioral expectations.

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 organized into clear segments: primary purpose, fallback warning, alternative tools, and parameter usage. It is slightly verbose but every sentence adds useful information.

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

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

Given the simple optional parameter and no output schema, the description provides enough context: what is returned, fallback behavior, and how to filter nodes. No critical operational details are missing.

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

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

The schema provides no description for node_ids, but the tool description explains that it fetches only specific nodes when used. This compensates for the missing schema coverage, though it could explicitly state that omitting it returns all nodes.

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

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

Clearly states it retrieves the workflow currently open in the user's browser, including nodes, edges, and selected node. It distinguishes itself from get_workflow and list_workflows by explicitly naming 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?

Provides explicit guidance on when to use this tool versus alternatives: use get_workflow for a specific workflow and list_workflows to choose. Also explains the fallback behavior when no browser session is active.

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

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

The readOnlyHint annotation already indicates this is a read operation. The description adds return field information but does not disclose additional behavioral details (e.g., side effects, rate limits). Since annotations cover the safety profile, the bar is lower, and the description is adequate but not enriched.

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 highly concise, consisting of two sentences that deliver essential information without any fluff. It is well-structured 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 description effectively covers the tool's purpose, usage condition, and return fields. It lacks error-handling details or output format nuances, but for a simple lookup tool, it is sufficiently complete for an agent to use it correctly.

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

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

There is only one parameter, execution_id, but the description merely repeats the name without explaining what constitutes an execution_id or its expected format. The schema provides no description, so the parameter semantics are not enhanced. This is a clear gap given the low schema coverage.

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

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

The description clearly states the tool's purpose with a specific verb 'look up' and resource 'one run by execution_id'. It also distinguishes itself from list_executions by specifying the condition of when to use it, making it unambiguous.

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

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

Explicit guidance is provided: 'when you don't have its workflow_id; otherwise use list_executions'. This clearly tells the agent when to use this tool versus the alternative, leaving no ambiguity.

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

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

The description accurately reflects the read-only nature implied by annotations and adds concrete detail about what is being checked and what status values are returned. It discloses the scope of the health check without any side effects.

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

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

The description is compact and front-loaded with the core action ('Self-test the MCP server'), immediately followed by the purpose and return shape. 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?

Given the tool's simplicity and the presence of an output schema, the description covers all necessary context: what is tested, what the result means, and when to call it. It is fully sufficient for an agent to invoke correctly.

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

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

The input schema has zero parameters and 100% schema description coverage, so the baseline of 3 applies. The description adds no parameter-specific semantics, but none are needed for a no-argument health check.

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 tool as a self-test of the MCP server and specifies the exact resources checked (DB pool and execution receiver). It is easily distinguishable from sibling tools that handle workflows, nodes, or credentials.

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 instructs when to use the tool: to distinguish backend/infra problems from bad-input errors. This gives the agent a clear decision rule without ambiguity.

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

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

The description discloses the exact return shape and included fields, which is strong behavioral transparency. The read-only and non-destructive nature is already covered by annotations, and the description adds a meaningful performance note about avoiding whole-workflow loading.

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

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

The description is concise, front-loaded with the main purpose, and efficiently packs return shape and usage guidance into a few sentences. No redundant or filler content is present.

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

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

The description covers return format and the main alternative tool, but it leaves parameter meanings and edge cases undocumented. Given that the schema has zero description coverage, the description partially compensates but is not fully complete for an agent needing to invoke the tool correctly in all situations.

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 provides no descriptions for workflow_id or node_ids, and the description gives only implicit hints such as 'node(s)' and 'whole workflow'. It does not explicitly define what values are expected or how node_ids relate to the workflow, so parameter semantics are minimally addressed.

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

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

The description clearly states the tool's purpose: getting a node's setup including config, type, handles, output, disabled, and has_mock without loading the whole workflow. It also distinguishes itself from the sibling get_node_output by noting the leaner alternative for output-only needs.

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 advises using get_node_output when only a node's output is needed, which provides a clear alternative and condition. It also implies the primary use case is configuration-focused, though it does not enumerate every possible alternative in the large sibling set.

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

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

The description adds valuable behavioral context beyond the annotations: it clarifies that this tool does NOT return live node configs, which is a key non-obvious behavior. It also aligns with readOnlyHint, providing no contradiction.

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

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

The description is concise (three sentences), front-loads the purpose, and structures the information logically: what it does, what it doesn't do, parameter format, and alternatives. No unnecessary filler.

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

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

Given the tool's simplicity and the presence of an output schema, the description covers all essential aspects: purpose, parameter format, usage guidance, and distinction from related tools. It is complete without being verbose.

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

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

The description explains the parameter format explicitly with an example ('type:operation' pairs like ['automation-slack:send_message_to_channel']). Since the schema itself has no description, this fully compensates and clarifies the parameter usage.

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

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

The description clearly states the tool's function: it returns the config schema for a node type+operation, and explicitly distinguishes it from get_node which returns live saved configs. The verb 'returns' is specific and the resource is well-defined.

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

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

The description gives explicit guidance on when to use this tool versus alternatives: it labels itself as a 'manual fallback' and directs users to search_operations for intent lookup and update_workflow for building, making the usage boundaries clear.

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

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

The description discloses the return structure (a JSON object mapping node type to operations with fields like name, description, display_name, category, and guidance), which goes beyond the readOnlyHint annotation. It also states 'ALL operations' and 'known node type', implying potential errors for unknown types, though not explicitly. Overall, it provides solid behavioral 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?

The description is succinct, comprising three sentences. It front-loads the primary purpose, then provides usage context, and closes with the return format. There is no fluff or redundancy, making it efficient and well-structured.

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

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

The description covers the core functionality, usage comparison, and return schema, which is sufficient for a simple read-only operation. However, it lacks details on error handling (e.g., unknown node type), parameter constraints (e.g., array size, values), and does not elaborate on the 'guidance' field. These gaps are minor but could affect a fully autonomous agent.

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

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

The schema for the single parameter 'node_types' has no description, and the tool description only mentions a singular 'node type' while the parameter is an array. It does not explain whether multiple types can be passed, what constitutes a valid node type, or the expected format. This leaves significant ambiguity for the agent, requiring additional inference.

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

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

The description clearly states the tool's function: to enumerate all operations of a known node type. It uses the specific verb 'enumerate' and identifies the resource (operations of a node type), making the purpose unambiguous. It also distinguishes itself from related tools by calling itself a 'manual fallback'.

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

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

The description explicitly provides usage guidance by stating when to prefer alternatives: 'Prefer search_operations for intent-driven lookup, or update_workflow(include_operations=true) while building.' This gives clear direction on when to use this tool versus others, fulfilling the criterion.

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

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

The description discloses key runtime behavior, including the returned shape, the optional execution_id field, and the fact that output is null when no output exists. The readOnly annotation is consistent and the description adds useful edge-case information beyond the annotations.

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

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

The description is compact and well-structured, front-loading the main purpose and then explaining default versus specific-run behavior and the return format. No unnecessary words are present.

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 includes the return shape and a key edge case, which makes it self-sufficient for typical usage. It does not cover error scenarios, but the provided context is adequate given the output schema and annotations.

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 prose explains node_ids, workflow_id implicitly through context, and execution_id explicitly with default behavior. The schema has no per-parameter descriptions, but the description covers the important semantics and batch usage.

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

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

The description clearly states the tool's purpose: 'Get node outputs in a workflow'. It also distinguishes batch behavior and the optional execution_id scoping, making the resource and action unambiguous.

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

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

The description explains when to use the default latest-output behavior versus passing an execution_id for a specific past run. It does not explicitly compare against sibling tools like get_node_output_history, but the usage guidance for the primary parameter is clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the base is covered. The description adds useful behavioral context by noting results are 'newest first' and describing the return structure, going beyond the annotations without contradicting them.

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

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

The description is two focused sentences plus a compact return type. Every clause adds value—scope, ordering, contrast, and use cases—with no redundant or vague 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?

For a moderate-complexity read tool, the description includes the return shape and the primary use case. It does not mention error handling or authentication, but the output schema is present and the sibling context clarifies edge cases. Overall, it is adequately complete for an agent to call it correctly.

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

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

The schema has no per-parameter descriptions (0% coverage), so the description must compensate. It explicitly explains node_id (not a list) and limit ('last N'), but workflow_id is not mentioned or described. Since workflow_id is a required parameter, its role is left to inference, making this partially complete.

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

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

The description clearly states the action (get last N outputs), the resource (a single node across executions), and the scope (node_id, not a list). It explicitly contrasts with get_node_output, making the distinction unambiguous.

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

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

It provides explicit usage scenarios: 'Use to compare a node's output over time or find a past run.' It also names the alternative tool (get_node_output) and clarifies when not to use it, giving full guidance.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds valuable behavioral context: it returns only terminal statuses, the exact return shape, and its relationship to canvas chips. It does not mention error handling or rate limits, but for a simple one-parameter read, this is sufficient.

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 front-loads the purpose and includes the return shape. Every clause earns its place: the status types, the relationship to canvas chips, the alternative tools, and the re-fetch behavior. No fluff or redundancy.

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

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

Given the tool has an output schema (per context signals) and the description already provides the return shape, nothing an agent needs to call it correctly is missing. The single required parameter is clearly identified, the behavior is described, and the output format is stated. It is complete for a simple get tool.

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

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

The schema has zero description coverage for workflow_id, so the description carries the burden of clarifying its meaning. It does so by stating the tool operates 'for a workflow', making it clear workflow_id is the workflow identifier. While the parameter name is self-explanatory, the description reinforces its purpose without adding unnecessary detail.

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

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

The description clearly states the tool retrieves the latest terminal status (completed/error/skipped) and error per node for a workflow, with the specific verb 'get' and resource 'node statuses'. It distinguishes itself from run_workflow/run_nodes by noting they already include this map, so the agent knows exactly what this tool does and how it differs from related operations.

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

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

Explicitly says 'use this to re-fetch WITHOUT re-running' and names the alternatives (run_workflow/run_nodes) that already provide the same data. This gives clear when-to-use and when-not-to-use guidance, leaving no ambiguity about its role relative to sibling tools.

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

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

The annotations already declare readOnlyHint and destructiveHint. The description adds detail on the content of the logs (results, errors, timing, node) but does not disclose additional behavioral traits beyond what annotations provide, so it neither adds nor contradicts.

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

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

The description is two sentences, front-loaded with the primary action and then providing useful context. It is concise and free of unnecessary 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?

The description gives some context about the output (what the logs show) but omits any explanation of the input parameters. It is partially complete but lacks the detail needed for full understanding, especially given the output schema is 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?

The schema has three parameters (limit, filter, workflow_id) but the description provides zero explanation for any of them. With 0% schema coverage, the description fails to compensate, leaving the agent without guidance on how to use these parameters.

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

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

The description clearly states the action ('Get recent SDK call logs') and the specific resource ('from the interface iframe'), distinguishing it from sibling tools like get_console_logs. It also provides context for its use ('debugging interface node issues').

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 a clear use case ('Useful for debugging interface node issues') but does not explicitly contrast with alternatives such as get_console_logs. It implies when to use but does not name the 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?

The annotations already declare readOnlyHint and destructiveHint, so the bar is lower. The description adds useful context about the browser-only nature and the null return when no workflow is open, which goes beyond the annotations to clarify edge-case behavior.

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

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

The description is concise and well-structured, with the primary purpose stated first and the alternative usage mentioned second. No redundant or irrelevant information is included, making it easy to parse quickly.

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

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

For a tool with no parameters and a simple purpose, the description provides all necessary context: what it returns, when it returns null, and when to prefer it over a sibling tool. The output schema is available separately, so no further explanation is needed.

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

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

The tool has no parameters, so the schema coverage is effectively 100% and the baseline applies. The description does not need to explain parameters, and no extra semantic information is required.

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

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

The description clearly states the tool's purpose with a specific verb 'Get' and a specific resource 'the node the user currently has SELECTED'. It also distinguishes this tool from get_current_workflow, making its unique role unambiguous.

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

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

The description explicitly tells when to use this tool instead of the alternative: 'get_current_workflow already returns selectedNodeId — use this only for a quick peek at the selected node's data.' This provides a clear condition for selection.

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

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

The description adds behavioral context beyond the readOnlyHint annotation by mentioning the token reduction benefit of node_ids. It implies a read-only operation consistent with the annotation, and provides a hint about the default behavior (fetching all nodes and edges) without enumerating side effects or errors.

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: the first states the primary purpose, and the second gives a practical usage tip. It is concise, front-loaded with the main action, and contains no redundant or extraneous information.

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

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

Given that no output schema is provided, the description adequately covers the tool's core functionality and an important parameter option. It does not need to explain return formats or error handling for this simple read operation, so it is sufficiently complete for its complexity.

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

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

The description clarifies the semantics of node_ids as an optional filter to limit fetched nodes, which is not evident from the schema alone. It does not explicitly describe workflow_id, but that parameter is self-explanatory given the tool's purpose. Overall, it compensates well for the lack of 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?

The description clearly states the verb 'Get' and the resource 'workflow details', specifying the content as 'all nodes, edges, and their configs'. This distinguishes it from sibling tools like get_node or get_current_workflow by indicating it returns the full workflow structure.

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 guidance on when to use the node_ids parameter ('to fetch only specific nodes (reduces token usage for large workflows)'), but does not explicitly compare this tool to alternatives like get_node or get_current_workflow. It implies a use case but lacks direct when/when-not guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the read-only nature is covered. The description adds value by disclosing that the result is a hierarchical structure scoped to user access, and includes workflow counts—context beyond the annotations. It does not discuss edge cases or error behavior, but for a simple no-parameter get tool this is sufficient.

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 no filler. The purpose and return structure are front-loaded in the first sentence, and the usage guidance in the second. Every word earns its place, making it easy for an agent to parse quickly.

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

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

For a no-parameter, read-only tool with an existing output schema, the description covers everything an agent needs: what it does, what it returns (hierarchical tree with counts), and when to use it. It is complete without over-explaining, as the output schema handles detailed return fields.

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

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

The tool has zero parameters, so the schema description coverage is trivially 100%. Per the baseline for 0 params, a score of 4 is appropriate. The description does not need to explain parameters, and it instead clarifies the output structure, which is useful.

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 and resource ('Get the complete folder tree') and clearly describes the output ('Returns all folders the user has access to in a hierarchical structure with workflow counts'). It differentiates from sibling tools like list_workflows and create_workflow by framing itself as the discovery mechanism for folder IDs, so the purpose is unambiguous.

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

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

The description explicitly instructs when to use the tool: 'Use this to discover folder IDs for list_workflows or create_workflow.' This gives a concrete use case, though it doesn't mention when not to use it or alternative folder-related tools like update_folders. Still, the guidance is clear and actionable.

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

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

The annotations already indicate read-only and non-destructive behavior. The description adds useful expectations about output format and ordering, which goes beyond the annotations.

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

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

The description is a single, concise sentence with no redundant words. It efficiently communicates the action, target, ordering, and output fields.

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 list operation, the description provides all necessary context: what is listed, for which workflow, in what order, and what fields are returned. No output schema is needed given this clarity.

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 only parameter workflow_id is not described in the schema, but the description's phrase 'a workflow's' makes its purpose clear. No additional details about format or constraints are provided, but the meaning is sufficiently conveyed.

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

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

The description clearly states the tool lists a workflow's saved checkpoints, with explicit details on ordering (newest first) and fields returned (id, name, timestamp). This distinguishes it from sibling tools like create_checkpoint and restore_checkpoint.

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 purpose is clear enough for an agent to infer when to use it, but it does not explicitly contrast with alternatives such as restore_checkpoint or list_workflows. The guidance is implied rather than stated.

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

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

The readOnly and destructive annotations already indicate no side effects, and the description adds transparency by listing possible statuses and the resulting credential_id on fulfillment. No contradictions exist.

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

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

The description is concise, uses only two sentences, and front-loads the core purpose and usage context without unnecessary 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?

The description includes the return shape, status values, and the event that triggers use, which is sufficient for an agent to call the tool correctly. It could be slightly more explicit about status filter values, but overall context is strong.

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 single status parameter is mentioned as a filter, and the possible status values are implied in the return shape (pending|fulfilled|cancelled), but the description does not explicitly state that those are the accepted filter values or explain the default behavior.

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

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

The description clearly states the tool polls the status of connect_credential requests that were previously minted, and distinguishes it from related operations by referencing the connect_url handoff. It gives a specific verb, resource, and purpose.

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 says to use this tool after handing the user a connect_url to check whether the request finished, which provides clear when-to-use guidance. It does not contrast with search_credentials or connect_credential, but the primary usage context is well stated.

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

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

Annotations already mark readOnlyHint=true and destructiveHint=false, so the description adds value by disclosing ordering (newest first), filtering capabilities, and the list of returned fields. It doesn't mention pagination details, but that's a minor gap given the annotations cover safety.

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, front-loaded with the core purpose and key fields, followed by filtering options and a usage hint. No unnecessary words or repetition.

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

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

Given the output schema exists and annotations cover safety, the description provides enough detail on purpose, fields, filtering, and usage. It omits explicit pagination semantics, but the default limit and cursors are inferable from the schema, so the tool is callable without missing critical information.

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 0%, so the description must compensate. It explains status, trigger_source, and search filters, but does not cover after, before, limit, or workflow_id semantics. Workflow_id is self-evident as required, but the pagination parameters (after/before) and limit are undocumented in both schema and 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 tool lists recent executions of a workflow, with a specific verb (list), resource (executions), ordering (newest first), and the fields returned. It distinguishes itself from siblings like get_execution_status by focusing on multiple executions.

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

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

The description explicitly says 'Use to find triggered/scheduled/failed runs and their execution_ids,' providing a clear use case. It doesn't name alternative tools or exclusions, but the context is sufficient for an agent to decide when to call it.

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

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

The description discloses that only id, name, and description are returned, not the full body, and that load_skill is needed for the body. Combined with the readOnlyHint annotation, behavior is reasonably transparent, though pagination or ordering are not mentioned.

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, focused sentence that states the purpose, output shape, and relationship to load_skill without unnecessary detail or repetition.

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

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

Given the tool has no parameters and is a simple read-only listing operation, the description contains all necessary context: what is listed, what fields are returned, and how to get more detail. No additional information is needed.

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

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

The tool has no parameters, and the description introduces no ambiguous parameter expectations. Since there is no input schema to elaborate on, parameter semantics are fully covered.

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

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

The description clearly states the tool lists reusable skills and specifies the returned fields (id, name, description). It also distinguishes this tool from load_skill by noting the body is fetched separately.

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 primary use case is to enumerate available skills before loading one, and points to load_skill for full body retrieval. However, it does not explicitly mention when not to use this tool or compare it to other listing tools.

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

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

Annotations already declare read-only and non-destructive behavior. The description adds valuable context by specifying the returned fields and its observational debugging role, reinforcing the safe nature without introducing any hidden 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?

Two concise sentences that front-load the action, then list the output fields and the purpose. No unnecessary words.

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

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

Includes the output fields and a specific use case. For a simple read-only list operation, this is sufficient, especially since the output schema is available to fill in remaining details.

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 sole parameter execution_id is implied by the context of workflow execution, but the description does not explicitly define it. With no schema-level description, a brief mention of what execution_id refers to would have been clearer.

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 (list tool calls) and resource (workflow execution), lists returned fields, and clearly identifies its debugging purpose.

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 suggests using it to debug what an AI agent node did, but does not contrast with similar tools like get_execution_status or get_console_logs, which could help clarify when to prefer this 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?

The annotations already indicate read-only and non-destructive behavior, and the description does not add further behavioral details such as pagination, filtering behavior, or side effects. The description is consistent with the annotations, but it provides no extra transparency beyond what is already declared.

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

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

The description is extremely concise and to the point, consisting of a single sentence. It communicates the essential purpose and return fields without unnecessary verbosity, which is ideal for quick comprehension.

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

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

Given that the schema lacks parameter descriptions, the overall description is sparse. It does not convey return format, error conditions, or how to combine parameters (e.g., whether query and folder_id are mutually exclusive). This leaves important context missing for an agent deciding how to invoke the tool.

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

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

The schema provides no descriptions for any of the three parameters (limit, query, folder_id). The description only mentions the return fields and does not explain the meaning or usage of these parameters, leaving the agent without guidance on how to set them effectively.

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

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

The description clearly states the action ('List') and the resource ('the user's workflows'). It also specifies the returned fields (id, name, description, timestamps), making the tool's purpose unambiguous and distinguishing it from siblings like get_workflow which fetches a single workflow.

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

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

The description implies usage for listing multiple workflows but does not explicitly contrast with alternatives such as get_workflow or list_workspaces. While the purpose is clear, there is no guidance on when to prefer this over other listing tools, leaving the agent to infer context from the sibling names.

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

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

Annotations already mark it as read-only and non-destructive; the description adds useful context about the output scope (personal + organizations) and that it indicates the active workspace, going beyond the annotations without contradicting them.

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

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

The description is concise, well-structured, and front-loaded with the primary purpose. The second sentence adds the key detail about active workspace, and the pointer to switch_workspace is relevant and succinct.

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 sufficiently explains what the tool returns (available workspaces and active status) for a simple listing tool. While it does not detail every possible output field, the presence of an output schema and the straightforward nature of the tool make the description adequate.

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

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

There are no parameters, so the description cannot add parameter-specific meaning. It provides a clear baseline for a zero-parameter tool, and the description's mention of scope and active workspace compensates for the empty input schema.

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

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

Clearly states the tool lists the user's available workspaces, including personal and organizational ones, and identifies the active workspace. This makes the purpose specific and distinguishes it from related tools like switch_workspace.

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 indicates the tool is for listing/checking workspaces and directs users to switch_workspace for changing the active workspace, providing a clear when-to-use and when-not-to-use distinction.

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

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

Annotations already indicate read-only and non-destructive behavior. Description adds conditional auth requirement and dependent-field context, which are useful behavioral details. No side effects or pagination behavior are mentioned, but the output schema exists.

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

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

Two sentences convey purpose, examples, auth constraint, and dependent-field usage without unnecessary words. Well structured 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?

With an output schema present, return values are covered externally. The description gives sufficient context for typical dropdown-loading use cases, though page_token semantics are omitted.

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?

Description explains context and credential_id meaning, and implies node_type/field_name through 'node field'. It does not explain page_token at all, and schema descriptions are absent, so parameter coverage is partial.

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 clearly states the tool loads dynamic dropdown options for a node field, with concrete examples (spreadsheets, sheets, channels). This distinguishes it from sibling load_skill and load_value 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?

Provides actionable guidance: credential_id for authenticated nodes and context for dependent fields. Does not explicitly name alternative tools or state when not to use it, so it falls just short of full guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. Description adds valuable detail about the content returned (XML and/or guidance text), which is beyond annotations and helps the agent know what to expect.

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

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

Single, dense sentence that packs action, content, purpose, and usage hint without waste. Front-loaded with the core operation.

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

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

With an output schema present, return values need no explanation. Description covers the action, input source, and intended use. Could add an explicit when-to-use vs alternatives, but that's minor given the overall clarity.

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 0%, so description must compensate. It provides a source for valid values ('Use ids from list_skills') but does not explicitly define what skill_id represents (e.g., unique identifier). It gives a useful pointer but lacks full 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?

Clear verb 'load' with specific resource 'skill' and scope 'full body'. States content (XML workflow and/or guidance text) and purpose ('to mimic its structure when building'). Differentiates from list_skills by referencing it for IDs and from other load tools by specifying the skill resource.

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 instructs to 'Use ids from list_skills', establishing a prerequisite and a related tool. Implies usage when building workflows to mimic structure. Does not explicitly exclude alternatives (e.g., list_skills for enumeration), but the context is clear enough.

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

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

The description explicitly discloses side effects beyond the annotations: 'a few fields provision on load — webhook_url registers the endpoint, hosted_url mints the link — idempotent, but not a pure read.' This transparently communicates that despite being idempotent and non-destructive, it is not a pure read-only 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 dense yet concise, packing a clear purpose, usage examples, side-effect warnings, and return format into a few sentences. It uses effective punctuation (em-dashes, parentheses) to structure information without unnecessary verbosity.

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

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

The description covers the core functionality, examples, edge case for listing fields, return shape, and side effects, which is sufficient for a tool of moderate complexity. It does not enumerate all possible field names or error conditions, but these are not critical for basic usage and the description is reasonably 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?

The description explains the crucial field_name parameter, including its default '' behavior for listing available fields. It also clarifies that the return value follows the field's native shape. However, it does not elaborate on node_id, workflow_id, or context, relying on their self-explanatory names, which is acceptable but not fully explicit.

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

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

The description clearly states the tool fetches a node's LIVE computed field, distinguishing it from stored config. It provides concrete examples (webhook_url, active_alarms, file_browser) and explains the field_name='' usage to list available fields, making the purpose unambiguous.

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

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

The description gives implicit usage guidance by noting that the tool returns computed values not stored in config and that calling with an empty field_name lists available options. However, it does not explicitly name alternative tools or scenario-based recommendations, so it falls short of fully explicit when/when-not guidance.

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

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

Annotations indicate idempotent, non-destructive, and readOnlyHint false. The description adds the environmental requirement of a NoClick tab, which is useful context. It does not contradict annotations and provides enough transparency for the action's side effect (opening a browser tab).

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 redundant phrases. It efficiently conveys the tool's purpose and the key prerequisite.

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 action, the description covers the main purpose and a prerequisite. However, it does not mention potential error conditions (e.g., workflow not found, tab missing) or any return value, though an output schema exists, which mitigates the need for return-value explanation.

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

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

The only parameter `workflow_id` has no description in the schema (0% coverage) and the tool description does not elaborate on its format, source, or meaning. The parameter name is somewhat self-explanatory, but the description fails to compensate for the missing schema details.

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 ('Open'), the resource ('workflow'), and the context ('in the user's browser'), distinguishing it from sibling tools like run_workflow or get_workflow. The requirement of a NoClick tab adds specific context.

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

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

The description provides a prerequisite (NoClick tab open) but does not explicitly state when to use this tool versus alternatives. It implies usage for displaying a workflow in the browser, but lacks direct comparison or condition-based guidance.

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

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

The description indicates a reporting action but does not explicitly state side effects such as creating a persistent record or sending a notification. The annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false) provide no additional clarity. Since the description lacks explicit behavioral disclosure, it only partially meets transparency expectations.

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

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

The description is concise and well-structured: a clear purpose statement, a usage condition, and a brief explanation of priority. It avoids unnecessary detail and is easy to parse.

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

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

Given the tool has 7 parameters and no schema descriptions, the description should cover all parameters to be complete. It only addresses priority and description, leaving 5 parameters unexplained. Additionally, it does not mention the output schema, though that may be less critical. The incomplete parameter coverage makes the tool hard to use correctly.

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

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

The schema has 7 parameters with zero descriptions, and the tool description only explains 'priority' (1-10 scale) and gives guidance for 'description' (what to include). The other parameters (title, node_type, workflow_id, error_message, priority_justification) remain unexplained, leaving significant ambiguity for the agent.

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

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

The description clearly states the tool's purpose: 'Report a bug encountered while building or running a workflow.' It specifies the action (report), the object (bug), and the context (building/running a workflow). This is sufficient to distinguish it from sibling tools like request_feature.

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?

Explicit guidance is provided on when to use the tool: 'Use this when you encounter an error, unexpected behavior, or something that doesn't work as expected.' It also instructs on what to include, giving clear conditions for invocation.

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

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

Annotations do not indicate side effects, and the description implies submitting a request but does not state what happens afterward, whether it creates a persistent record, or what response the caller should expect. No contradiction exists.

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

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

The description is one focused sentence with no filler, front-loading the purpose and usage conditions 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?

With 7 parameters and an output schema, the description omits parameter meanings, return behavior, and side effects. It covers only selection criteria and the priority scale, which is too sparse for complete invocation 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?

Only priority is partially explained ('1-10, higher = more urgent'); title, description, use_case, node_type, workflow_id, and priority_justification are left undefined with 0% schema coverage. The description does not compensate for this gap.

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 the specific action 'Request a feature' for workflow building and lists concrete triggers (missing capability, unsupported workflow pattern, improvement), which clearly distinguishes it from siblings like report_bug.

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 says 'Use this when' and enumerates three scenarios, plus explains the priority scale. This gives clear selection guidance even without mentioning when not to use it.

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

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

Explicitly mentions the destructive nature (replaces current graph) and the side effect of re-registering webhook/cron resources, going beyond the destructiveHint annotation and giving clear behavioral expectations.

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?

Conveys purpose, behavior, and a warning in two concise sentences without unnecessary detail, making it easy to parse and act upon.

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?

Covers the essential aspects: the action, the side effects, and the irreversibility. An output schema is present, so not describing return values is acceptable.

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

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

The description does not elaborate on workflow_id or checkpoint_id. Since the schema provides no parameter descriptions (0% coverage), the description fails to add meaning, though the parameter names are somewhat self-explanatory.

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

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

Clearly states it restores a workflow to a saved checkpoint, replaces the current graph, and re-registers webhook/cron resources. This distinguishes it from sibling tools like create_checkpoint or list_checkpoints.

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?

Provides explicit guidance that the operation is irreversible and recommends creating a checkpoint first if the current state is needed. However, it does not explicitly compare with alternatives like open_workflow, so it lacks a full when-to-use vs. when-not-to-use breakdown.

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

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

The description is highly transparent: it states real side effects ('the target node really executes'), warns against write/send/payment nodes, explains auto-mocking and missing upstream behavior, details sequential execution, and clarifies tool-metadata returns for agent-wired nodes. It aligns with destructiveHint=true and adds substantial behavioral detail beyond annotations.

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

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

The description is dense but well-organized: purpose first, key execution semantics next, side-effect warning prominently, then return format. No redundant filler; every sentence adds useful information.

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

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

The description covers the essential context an agent needs: what the tool does, how predecessor nodes are handled, side effects, sequencing, agent-wiring behavior, and output structure. It is complete for the tool's complexity, even without a formal 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?

The schema has 0% description coverage, but the description compensates partially: it clarifies return_output=true vs truncated preview and explains node execution semantics. workflow_id and node_ids are not individually described in prose, though their roles are inferable from 'Run specific nodes in a workflow' and the schema names.

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

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

The description clearly states the tool's purpose: 'Run specific nodes in a workflow for testing.' It identifies the resource (workflow nodes), the action (run), and the intended context (testing), distinguishing it from full-workflow execution.

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 good usage guidance by specifying 'for testing', explaining predecessor auto-mocking behavior, and prominently warning about side effects. It could be slightly stronger by explicitly contrasting with run_workflow, but the intent is clear enough for an agent to choose this tool appropriately.

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

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

The description discloses that running the workflow actually executes every node, including sends, external writes, payments, and deletes—information that goes beyond the destructiveHint annotation. It also notes that outputs are truncated unless return_output is true.

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 dense but structured with clear sections for side effects, returns, and parameter usage. Every sentence carries operational value, though it is somewhat long.

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

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

It covers validation prerequisite, side effects, output format, and parameter details. No output schema exists, so the description adequately fills the gap for a successful execution.

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?

Despite zero schema coverage, the description explains the inputs parameter (simulating form submission/webhook) and the return_output parameter (full outputs vs truncated previews). workflow_id is self-explanatory as the target workflow.

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 opens with 'Execute a workflow,' a specific verb and resource. It also distinguishes itself from validate_workflow, making its purpose unmistakable.

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 explicitly instructs to run validate_workflow first to catch build errors, and warns against running write/send/payment nodes without user approval, offering clear when-to-use and safety guidance.

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

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

Annotations already provide idempotent/read-only/destructive hints. The description usefully adds that this saves a draft rather than publishing, and that repeated iteration is expected. It doesn't detail overwrite behavior, but the idempotentHint covers repeated-call safety.

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

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

The description is front-loaded with purpose, then carries an IMPORTANT usage call and practical content guidelines. The second paragraph is long but justifiable because it specifies exactly what title and description content the agent should produce.

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

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

The description is largely complete: it specifies when to call the tool, what to include in the title and description, and an output schema exists to describe results. Minor gaps are explicit workflow_id semantics and clarification of draft-overwrite behavior, but neither is critical.

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

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

With 0% schema coverage, the description compensates well: it defines title as a brief workflow description with an example, and description as detailed markdown covering pipeline, input, and output. workflow_id is not explicitly explained but is clearly implied as the target workflow from 'for a workflow'.

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: 'Save a template draft (title and markdown description)' for a workflow, and clarifies this is a pre-publish iteration step. It distinguishes the tool from sibling update operations by framing it as draft-saving before library publication.

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 call it: after every workflow is built or significantly modified. It also gives a clear context of iterating on template content before publishing, though it doesn't name alternatives or when-not-to-call cases.

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

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

The annotations already indicate readOnly and non-destructive behavior, and the description adds that the tool returns matching credentials with id, name, type, and metadata. It does not contradict the annotations and gives a reasonable picture of expected output. It does not cover edge cases like empty results or exact-match semantics, but that is not required for a search 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 two sentences, front-loads the core action and return fields, and avoids unnecessary detail. Every sentence contributes useful context without redundancy.

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

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

The description provides enough context for an agent to understand the tool's purpose and basic return shape. It does not mention output schema details or permission requirements, but these are not critical given the annotations and the simple search semantics. The sibling tools provide surrounding context, though the description does not reference them.

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 has three parameters with no descriptions, and the tool description does not explain any of them individually. The parameter names (limit, query, credential_type) are somewhat self-explanatory, but with zero schema-level description coverage the description should compensate more explicitly. Default values and filtering behavior are left entirely to inference.

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

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

The description clearly states the tool searches the user's credentials and returns specific fields (id, name, type, metadata). It also identifies the primary use case: finding credentials when configuring nodes that require authentication. However, it does not explicitly distinguish itself from the sibling 'connect_credential' or 'list_credential_requests' tools.

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

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

The description gives a practical use case ('Use to find credentials when configuring nodes that require authentication') but does not explicitly mention when to prefer this tool over siblings like connect_credential or list_credential_requests. The guidance is implied rather than explicitly contrasted with 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?

The description explains that detail_level controls the amount of data returned and that it avoids loading all operations at once. Combined with readOnly/destructive annotations, this gives a solid picture of behavior, though output specifics are left to the schema.

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

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

Three concise sentences that front-load the purpose and then explain optional parameters and behavior. No redundant or filler content.

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

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

The description is complete for a search tool with an output schema, but it does not mention what the response shape is beyond the detail_level behavior. Since an output schema exists, this is acceptable and not a major 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 description covers query, node_types, and detail_level semantics in detail. Limit is not described, and the schema has no parameter descriptions, so there is a minor gap but overall sufficient guidance.

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

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

Clearly states the tool searches operations across node types by intent, matching name, description, display_name, and category. This distinguishes it from sibling tools like search_credentials and gives a precise 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?

Provides practical guidance on scoping with node_types, choosing detail_level, and progressive disclosure to avoid loading all operations. It could be stronger by contrasting with get_node_operations, but the instructions are clear enough.

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

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

The description goes beyond the annotations by explaining the effect of switching: it changes which workflows, folders, and credentials are visible. This is useful behavioral context not captured by the readOnlyHint/destructiveHint flags.

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

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

The description is two concise sentences that front-load the purpose and follow with usage and effect. Every sentence adds value, with no redundant or vague 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?

For a simple one-parameter tool, the description covers purpose, parameter semantics, and the visible side effect. Since an output schema exists, not describing return values is acceptable, and nothing critical 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?

Although the schema provides no description for organization_id, the tool description fully explains its meaning and accepted values ('pass an organization_id', 'pass null/empty'). This completely compensates for the schema's lack of parameter documentation.

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

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

The description clearly states the action ('Switch') and the resource ('workspaces'), and distinguishes between personal and organization workspaces. It immediately tells the agent what the tool does and why it exists.

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 explicit instructions on how to use the tool: pass an organization_id to switch to that org, or pass null/empty to switch to personal. It lacks an explicit 'when not to use' or alternatives, but the usage context is clear and actionable.

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

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

The description explicitly lists delete_folder and move_workflow operations, which are destructive/mutating actions. However, the annotations declare destructiveHint=false, contradicting the behavior described. This is a direct annotation contradiction.

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 structured with clear sections for commands, processing order, alias rules, and examples. Every sentence adds necessary information; there is no fluff or redundancy.

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

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

Given the single string parameter and the output schema, the description fully covers the XML syntax, operation semantics, ordering constraints, alias usage, and examples. It provides enough context for an agent to call the tool correctly.

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

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

The only parameter, updates_xml, has no schema description, but the tool description compensates thoroughly by documenting the XML format, supported commands, attribute meanings, processing order, and local alias behavior. This gives the agent all needed information to construct the parameter value.

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

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

The description clearly states the tool's purpose: batch folder mutations using XML commands. It names the resource (folders) and the verb (mutations/updates), making it distinct from folder retrieval tools like get_workflow_folders.

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 explains that this tool handles multiple operations in one call and provides detailed XML command examples. It does not explicitly contrast with alternative single-operation tools, but the batch-oriented wording and examples make the intended usage clear.

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

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

The description discloses non-obvious behavior: interface nodes not already on the grid are auto-created with defaults, and blocks cannot overlap. Combined with the annotations (readOnly=false, idempotent=true, destructive=false), this gives a good picture of side effects, though it does not mention failure modes for invalid IDs or overlapping placements.

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 succinct and well-organized. It uses short paragraphs, code-style XML examples, and a concise list of grid constraints, making it easy to scan and understand without unnecessary verbosity.

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

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

The description covers the core mechanics, constraints, and ID requirements, which is sufficient for most usage scenarios. It lacks an explanation of workflow_id and does not describe the output or return value, but the provided details are relevant and actionable.

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 updates_xml parameter is well explained through the XML command examples, including the required id format. However, workflow_id is not described at all, and since the schema provides no description coverage, half of the parameters lack semantic guidance.

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

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

The description clearly states the tool's purpose: positioning and arranging interface blocks on a 12-column grid. It distinguishes this from sibling tools by focusing specifically on grid layout for interface-* nodes, rather than general workflow editing or evaluation.

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 concrete usage instructions through XML command examples and grid constraints. It implicitly indicates when to use this tool (for arranging interface blocks) without explicitly contrasting alternatives, but the command examples and domain scope make the intended usage clear.

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

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

Annotations already communicate read/write and non-destructive intent. The description adds meaningful behavioral detail: validation rejects invalid operation names with the valid list, provider-wired nodes do not execute in the flow, dynamic options are resolved, and a processing order is specified. It could be slightly more explicit about the full scope of mutation side effects, but is largely 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?

The description is extremely long and dense, mixing many rules, examples, and caveats into one block. It is organized with XML snippets and a processing order, but the sheer volume and repetition make it harder to scan. It is still structured enough to avoid a lower score.

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

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

Despite sparse schema, the description covers the essential usage scenarios, error handling, edge cases, and preferred patterns. The output schema exists, so return-value details are not required. It is slightly incomplete only in not defining workflow_id / idempotency_key semantics explicitly.

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 0%, but the description compensates substantially: it explains updates_xml syntax, reserved attributes, dynamic option suffixes, include_operations, include_configs, and include_dynamic_options. However, workflow_id and idempotency_key are essentially only named in the input schema and not described, so it stops short of a 5.

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?

Opens with 'Batch XML mutations on a workflow', naming the exact verb and resource. This clearly distinguishes it from sibling read-only tools like get_workflow and get_current_workflow, and from update_workflow_metadata.

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?

Provides extensive guidance on when to use this tool and how to choose among alternatives, including agent/provider wiring vs. fixed pipelines, trigger-* nodes vs. integration-native triggers, and the processing order for mutations. It also gives explicit 'do not' guidance, such as not templating trigger references into agent messages.

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

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

The description only says 'update' without elaborating on effects, requirements (e.g., workflow existence), or side effects. Annotations indicate non-read-only and non-destructive, but the description adds no behavioral context beyond the verb.

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

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

The description is a single concise sentence with no redundant information, directly stating the tool's 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?

The description omits return value details, error handling, and failure scenarios (e.g., workflow not found). While an output schema exists, the description does not clarify what happens on success or failure, leaving the tool's behavior ambiguous.

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?

Parameters are not described beyond their names. The schema has no field descriptions, and the tool description does not explain the semantics of nullable fields (e.g., whether null clears the value) or any constraints on workflow_id.

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

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

The description clearly states the action (update) and the specific resource (workflow's name and/or description), distinguishing it from sibling tools like update_workflow that likely handle broader changes.

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 alternative update tools (e.g., update_workflow). The description lacks any mention of prerequisites, alternatives, or exclusion 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?

The readOnlyHint annotation already indicates no side effects, and the description adds useful behavioral context: it runs headlessly, uses a server-side sandbox, does not open a browser tab, and returns syntax/runtime errors. This goes beyond the annotation and clarifies the tool's execution environment.

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, compact sentence that leads with the primary action and includes relevant execution details. It is slightly dense due to the parenthetical and dash, but it remains focused and free of unnecessary content.

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

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

The description covers the tool's purpose, execution mode, and return type at a high level, but it leaves questions about successful output format, parameter relationships, and how errors are represented. Given the low parameter schema coverage, more context would be needed for full completeness.

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

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

Schema coverage for the two parameters is 0%, and the description does not explain how workflow_id and node_id are used or relate to the jsx_source being read. The agent is left without any parameter-level guidance, so the description fails to compensate for the missing schema documentation.

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

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

The description clearly states the tool validates an interface node's JSX/React component in a headless, server-side sandbox and returns syntax/runtime errors. It distinguishes this from broader workflow validation by focusing on interface nodes and their jsx_source.

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

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

The description implies usage for validating interface components without a browser, but it does not explicitly explain when to prefer this over similar sibling tools like eval_interface or validate_workflow. It gives some context but lacks direct guidance on alternative selection.

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

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

The description explicitly notes no side effects, aligns with the readOnlyHint annotation, and explains the meaning of credentials_disconnected and the proper fix, making behavior 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?

The description is dense but well-structured, covering purpose, return shape, and an important edge case, though it is slightly longer than strictly necessary.

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 gives good operational context and return-shape details, but the missing parameter explanations leave the overall context incomplete for fully 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 schema provides no descriptions for workflow_id or node_ids, and the description does not explicitly explain how node_ids affects validation or what workflow_id refers to, leaving parameter semantics under-specified.

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

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

The description clearly states the tool validates a workflow without running it, provides a specific verb and resource, and distinguishes it from run_workflow and update_workflow.

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

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

It explicitly says to use the inline verdict while building and validate_workflow as the final gate before run_workflow, and contrasts with update_workflow, giving clear when-to-use guidance.

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