CNAPS.ai MCP Server

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

Annotations already mark this as destructive (destructiveHint=true), but the description adds the critical nuance that cancellation is graceful: 'the flow will stop after completing the current processing step.' This is a behavioral detail not covered by annotations, and the suggestion to confirm via get_flow_status further improves 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 two sentences long, with the core action stated first and supporting details in sequence. Every phrase adds value: the graceful-stop nuance and the confirmation step are both non-redundant.

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 with no output schema, the description covers the essential context: what it does, how it behaves, and how to verify the result. The annotations and schema provide the remaining safety and parameter information, leaving no significant gaps.

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

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

The schema fully documents flow_id with 'The unique identifier of the running flow to cancel,' achieving 100% coverage. The description adds no additional meaning or format details for the parameter, so it meets the baseline for schema-driven cases.

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 'Cancel a currently running workflow,' a specific verb+resource statement that clearly distinguishes from siblings like run_flow (starts) and delete_flow (removes). The additional phrase 'Sends a stop signal' clarifies the mechanism, leaving no ambiguity about the tool's function.

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

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

The description implies usage by referencing 'currently running workflow' and directs the user to 'get_flow_status to confirm it has stopped,' providing a clear follow-up context. However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of full exclusion guidance.

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

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

The description presents the tool as a non-destructive validation action, but the annotations include destructiveHint=true, which contradicts the check semantics. The description does not disclose any destructive behavior and instead implies the opposite, creating a serious inconsistency.

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 core action, and every sentence contributes useful information. There is no redundancy 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?

For a simple check tool with one parameter, the description covers purpose, usage, and return contents (compatibility status, wiring details, required inputs, final outputs). However, it does not explicitly state that the tool is non-destructive, leaving a gap given the contradictory annotation.

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

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

Schema coverage is 100% for the single parameter, and the schema already provides a clear description with an example. The description adds minimal semantic value beyond reinforcing the order requirement, so the baseline score of 3 applies.

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

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

The description clearly states the specific verb 'check' with the resource 'pipeline compatibility' and the scope is explicit: validating a sequence of AI models before creating a flow. It distinguishes itself from sibling tools like create_flow and validate_flow by focusing on pre-flight compatibility checking.

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

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

The description provides clear usage context: use this to validate multi-model pipelines and avoid create_flow errors. It does not explicitly name alternatives or exclusions, but the intended use case is unambiguous 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 discloses that this tool performs both creation and execution in one step, and that it is asynchronous (poll get_flow_status). This adds behavioral context beyond the annotations (which already mark destructiveHint=true and readOnlyHint=false). However, it could mention side effects such as persistence or cost implications, but the annotation covers the destructive nature.

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 three sentences long, front-loaded with the core purpose, and every sentence earns its place: the first states what it does, the second distinguishes it from siblings, and the third provides sequential guidance. No redundancy or fluff.

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 combining creation and execution without an output schema, the description covers the essential steps: checking compatibility first, calling the tool, then polling get_flow_status. It could mention error handling or return values, but given the complex async workflow and rich siblings (e.g., diagnose_error), it is adequately complete.

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

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

Schema description coverage is 100%, so the schema itself thoroughly documents all five parameters, including detailed examples for models, parameters, and include_optional. The tool description adds no additional parameter semantics, as it focuses on the high-level workflow. Thus baseline 3 is appropriate.

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

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

The description states 'Create AND immediately run a multi-model pipeline in one step', combining specific verbs and resource, and clearly distinguishes this from sibling tools like create_pipeline and run_flow by saying it merges both actions. It also identifies the exact workflow (poll get_flow_status afterwards).

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 directs when to use this tool: 'no need to parse run_hint or call run_flow separately' and advises to 'Use check_pipeline_compatibility first to verify models can be wired together.' It also tells the agent what to do after calling (poll get_flow_status), providing clear contextual guidance versus 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 adds crucial context beyond the annotations by stating 'the raw key is returned ONCE — save it immediately, it cannot be retrieved later.' This critical behavioral trait is not captured in the annotations and is essential for the agent to warn the user.

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 at two sentences, with the primary purpose front-loaded and no unnecessary information. Every word earns its place.

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

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

Given the low complexity (2 parameters), the annotations cover mutability, and the description covers the one-time key return caveat, the description is complete. The absence of an output schema is mitigated because the description already indicates the raw key is returned once.

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

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

The input schema already provides clear descriptions for both parameters (description and expires_at), covering 100% of the schema. The tool description does not add further parameter semantics, so the baseline of 3 is appropriate.

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

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

The description clearly states 'Create a new API key for your workspace,' using a specific verb and resource. It distinguishes itself from sibling tools like list_api_keys and delete_api_key by focusing on creation.

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

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

The description implies the tool should be used when a new API key is needed, which is clear context. However, it does not explicitly mention alternatives or when not to use this tool, so it falls short of a full 5.

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

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

With annotations already indicating a non-read, potentially destructive mutation, the description adds context that the tool creates a public post, includes a snapshot of the flow, and enables discovery/forking. This clarifies the public side effect and the snapshot behavior, which isn't captured 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?

Two sentences, front-loaded with the main action ('Publish one of your flows'), and no wasted words. Every sentence provides relevant information about purpose or prerequisites.

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 create operation with 2 required params, the description fully covers prerequisites and the resulting side effect. It doesn't mention return values, but without an output schema and given the straightforward action, this is adequate. More detail on post-editing or visibility could be added, but not necessary for correct invocation.

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

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

Schema coverage is 100%, so the schema already documents all parameters. The description reinforces that source_flow_id comes from list_flows, but doesn't add further semantic detail beyond the schema's per-parameter descriptions. Baseline of 3 is appropriate.

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

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

Description clearly states the verb 'publish' and the resource 'your flows to the cnaps.ai community'. It distinguishes from siblings like create_flow and fork_community_flow by specifying that this creates a community post with a snapshot of the flow for others to discover and fork.

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 clear context: publishing a flow to the community. States prerequisites: 'Requires a source_flow_id (from list_flows) and a title', which tells the agent to first call list_flows. It doesn't explicitly exclude alternatives, but the community-publish intent is unambiguous 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 description reveals important behavioral traits beyond the annotations: auto-generation of input/output nodes and connections, wiring by matching output→input port types, fan-out of shared inputs, auto-expansion of shorthand nodes, auto-filling of default parameters, and auto-upload of text inputs as files. This is rich, useful context that explains how the tool behaves, not just what it does. No contradiction with annotations.

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

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

The main description is three sentences, front-loaded with the core purpose and the single most important behavioral fact (auto-generation). It is concise, avoids fluff, and every sentence contributes meaning. The longer parameter descriptions are part of the structured schema and are justified by the need to document complex formats. Overall, the prose is tightly written and well-structured.

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

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

Given the tool's complexity (5 parameters, flexible input formats, auto-generation rules), the description covers all critical aspects: formats for nodes (shorthand vs full), port-type matching, fan-out behavior, input_files semantics, and optional input handling. It includes examples and a clear decision heuristic for include_optional. Although there is no output schema, the description does not leave major gaps in understanding how to invoke the tool correctly.

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

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

The input schema already provides exhaustive descriptions for all parameters (100% coverage), so the baseline is 3. The main description adds conceptual meaning beyond the schema by explaining the auto-wiring model, how input_files interact with auto-generated nodes, and the relationship between nodes and connections. This enhances understanding of parameters without repeating schema details. Slightly above baseline due to this added semantic layer.

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 'Create a new AI workflow' — a specific verb+resource that clearly states the tool's function. It distinguishes itself from the sibling create_pipeline by explicitly noting in the nodes parameter that simple pipelines should use create_pipeline instead. The description also clarifies the key auto-generation behavior, making the purpose unambiguous.

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

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

The description includes an explicit usage tip: 'For simple pipelines, prefer create_pipeline which is designed for model ID arrays.' This directly tells the agent when to choose an alternative tool. It also implies when this tool is appropriate (multi-model pipelines with auto-wiring, complex node configurations) and provides guidance for deciding the include_optional parameter. Clear when/when-not guidance is present.

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 destructiveHint=true and readOnlyHint=false, so the description adds useful context about auto-generation of nodes/connections via type matching. It does not detail side effects or permissions, but the annotation coverage lowers the burden; the added behavior insight pushes it above average.

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

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

The description is four sentences, front-loaded with purpose, then key advantage, then behavior, and finally usage guidance. Every sentence adds value with no redundancy, 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?

For a tool with 5 params and no output schema, the description covers the primary use case, distinguishes from siblings, mentions a prerequisite, and the schema handles parameter details. It is sufficiently complete for an agent to select and invoke 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?

Schema description coverage is 100% for all 5 parameters, so the description need not repeat parameter details. The description adds some context about 'pipeline order' related to the 'models' parameter, but no further parameter-specific meaning beyond the schema, matching the baseline of 3.

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

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

The description clearly states the verb 'Create' and the resource 'multi-model pipeline flow', distinguishing it from the sibling 'create_flow' by emphasizing 'EASIEST way' and listing advanced cases for the alternative. It also mentions the prerequisite 'check_pipeline_compatibility', making the tool's 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?

Explicit guidance is provided: use this tool for simple model-ID-based pipelines, check compatibility first, and use 'create_flow' for advanced cases. This fully addresses when to use and when not to use, with a clear alternative named.

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 explicitly stating 'This action is irreversible,' providing additional behavioral context not captured by the destructiveHint flag. It doesn't contradict 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 extremely concise, with two short sentences that immediately state the action and its irreversible nature. 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?

Given the tool's simplicity—one parameter, no output schema, and strong annotations—the description is complete. It covers the action, the scope, and the consequence, which is sufficient for an agent to use the tool correctly.

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

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

The input schema already provides full coverage for the api_key_id parameter, including instruction to use list_api_keys. The tool description itself does not add parameter-specific details, so the baseline score of 3 is appropriate.

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

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

The description uses the specific verb 'Delete' and clearly identifies the resource as 'an API key from your workspace.' It distinguishes itself from sibling tools like create_api_key and list_api_keys by stating the action clearly.

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 tool description provides clear context: it is used to delete or revoke an API key. However, it does not explicitly mention when not to use it or point to alternatives, so it falls short of explicit usage guidance.

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

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

Annotations already indicate destructiveHint=true, but the description adds critical nuance: the operation moves to trash rather than permanently deleting, and the flow is restorable. This discloses the reversible nature of the action beyond the annotation's binary destructive signal.

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 efficiently states the action, target, and key behavioral property (restorability). No unnecessary words, and it is front-loaded with the primary verb and object.

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 parameter set, existing annotations, and the presence of a sibling restore_flow tool, the description fully covers what the agent needs to know: the action is a move to trash and is reversible. No output schema is needed, and the description is sufficient for correct invocation.

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

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

The schema covers 100% of parameter semantics with a clear description for flow_id. The tool description adds no additional parameter context beyond the schema, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Move') with a specific resource ('workflow') and target state ('to trash'), clearly distinguishing it from permanent deletion tools like delete_api_key and from restore_flow. It conveys both action and destination.

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 states that the flow can be restored later, implying this is a soft delete and giving clear context for when to use it. It does not explicitly contrast with sibling tools like restore_flow or offer exclusions, but the restorability note provides sufficient 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 read-only, non-destructive operation, but annotations set readOnlyHint=false and destructiveHint=true. This is a direct contradiction. The description fails to disclose any destructive behavior or clarify the discrepancy, making it misleading for an agent.

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

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

The description is two sentences, front-loaded with the primary purpose, and every sentence adds value by specifying output content and usage context. No wasted words.

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

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

The description explains purpose, output content, and when to use it, which is fairly complete for a simple describe tool. However, the contradiction with the annotations (destructiveHint=true) remains unaddressed, leaving the agent uncertain about potential side effects. This gap reduces 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 is 100% with flow_id described as 'The unique identifier of the flow to describe.' The description adds no extra meaning beyond the schema, so a baseline score of 3 is appropriate.

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

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

The description clearly states the specific verb and resource: 'Get a human-readable description of what a workflow does.' It also details the content of the description (input types, model chain, output types) and distinguishes itself from get_flow by explicitly contrasting with raw JSON output.

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 usage guidance: 'Use this when the user asks what does this flow do? instead of returning raw JSON from get_flow.' This clearly identifies when to use the tool and names the alternative.

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

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

Annotations declare destructiveHint=true, but the description describes only analysis and suggestion of fixes, with no mention of any modifying or destructive action. This directly contradicts the annotation, so transparency must be scored as 1 per the rubric. The description itself provides helpful behavioral details about return values, but the contradiction invalidates trust.

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 three sentences long, front-loaded with the primary action, and every sentence adds meaningful information: what the tool does, what to provide, what it returns, and when to use it. There is no unnecessary detail or 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 fully covers what the tool does, when to use it, and what it returns, enumerating the specific outputs (root cause analysis, failing node, fix suggestion, confidence level). Even without an output schema, the description provides sufficient completeness for an agent to invoke the tool correctly. The only issue is the annotation contradiction, which is already captured in behavioral transparency.

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 full coverage (100%) with clear descriptions for both parameters. The description adds only marginal context by explicitly telling the user to provide flow_id, but this is already present in the schema. No additional semantic value is added beyond the schema descriptions, making a baseline score of 3 appropriate.

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

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

The description clearly states the tool's purpose with a specific verb ('Analyze') and resource ('failed pipeline execution'), and explicitly mentions the output (root cause analysis, failing node, fix suggestion, confidence). It also distinguishes itself by referencing get_flow_status, which is a sibling tool, and provides a use case that differentiates it from other 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 an explicit condition for use: 'Use this whenever get_flow_status shows a failed node.' This clearly communicates when to invoke the tool. However, it does not mention when not to use it or name alternatives, which prevents a perfect score. The provided context is otherwise sufficient.

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 contradicts the annotations. It states 'WITHOUT actually creating it' and implies no side effects, but annotations declare destructiveHint: true and readOnlyHint: false. This is a direct contradiction, so behavioral transparency is scored 1.

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

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

The description is four concise sentences, each carrying distinct value: purpose, behavior/return, usage guidance, and a critical constraint. It is front-loaded and free of redundancy.

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

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

For a tool with two parameters and no output schema, the description is thorough: it explains the purpose, the internal scaffold logic, the return value (full node structure, connections, run_hint), and a key constraint. It is sufficiently complete for an agent to select and invoke 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?

Schema description coverage is 100%, with both parameters already well-documented. The tool description adds context about auto-generated input/output nodes but does not provide additional meaning about parameter formats or behavior beyond what the schema already gives. Baseline 3 is appropriate.

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

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

The description clearly states the tool 'previews' what a flow would look like without creating it, using a specific verb and resource. It distinguishes itself from siblings like create_flow and create_pipeline by explicitly noting it verifies structure before committing.

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 clear when-to-use guidance: 'verify the pipeline structure before committing to create_flow or create_pipeline.' It also specifies a constraint (only accepts ai_model nodes), which implies when not to use it (e.g., not for input/output nodes). However, it does not mention alternative validation tools like validate_flow or check_pipeline_compatibility.

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 write/destructive behavior, and the description adds the useful detail that the copy has 'fresh state (no results).' However, it does not disclose what the tool returns (e.g., the new flow ID), which is an important behavioral aspect for a creation operation, especially with no output schema provided.

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 three sentences long, front-loaded with the core purpose, and contains no unnecessary information. It efficiently covers the action, behavior, and usage context.

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

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

The tool is simple, but because there is no output schema, the description should explain the return value. It doesn't mention what the tool returns, leaving a gap for an agent that needs the new copy's ID to proceed. Otherwise, the description is complete for basic usage, but this missing piece makes it incomplete.

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

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

The input schema provides 100% coverage with descriptions for both parameters (flow_id and name), including the default behavior for name. The description itself does not add additional parameter meaning, but the schema already handles it, so the baseline of 3 is appropriate.

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

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

The description clearly states the action ('Duplicate') and the resource ('existing workflow'), and it adds that it creates a 'deep copy with fresh state.' This differentiates it from sibling tools like create_flow (creating from scratch) and fork operations, and explicitly mentions update_flow as a follow-up.

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

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

The description provides explicit usage guidance: 'Use this to copy a flow and then modify it with update_flow, instead of recreating from scratch.' This tells the agent when to use this tool and suggests the alternative (recreating) that it replaces, making the decision 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 describes a read-only search operation ('Find models'), but annotations declare destructiveHint: true. This is a contradiction; the description does not address the destructive hint and instead implies non-destructive behavior. Since the description contradicts the annotation, this dimension scores 1.

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 three concise sentences, front-loaded with the primary purpose, then detailing the two directions and usage timing. 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?

The description covers the main functionality, direction options, and sorting, but it fails to address the destructiveHint annotation, which is a significant omission given the contradiction. It also lacks any error handling or return format details, though there is no output schema. The incomplete reconciliation with annotations makes it inadequate for fully correct use.

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

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

The schema has 100% coverage for both parameters, and the description adds depth by explaining the direction semantics: downstream finds models whose inputs match this model's outputs, upstream the reverse. It also notes the result sorting by matching ports, which adds behavior context beyond the schema.

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

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

The description clearly states the tool's function: 'Find models that can connect to a given model in a pipeline.' It distinguishes downstream vs upstream, which differentiates it from sibling tools like check_pipeline_compatibility and suggest_models.

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 timing guidance: 'Use this BEFORE creating a pipeline to ensure models can be wired together.' It also explains when to use 'downstream' vs 'upstream' direction. It does not name alternative tools, but the context is sufficient.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false, and the description adds behavioral context by explaining that the forked flow becomes owned by the user and can be run with run_flow or modified. This goes beyond what annotations provide, though it doesn't cover auth or rate limits.

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

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

The description is two sentences, front-loaded with the core action, and every sentence earns its place. It avoids fluff and efficiently communicates the purpose, source of the input, and post-fork possibilities.

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 a single parameter, no output schema, and clear annotations, the description fully covers what the tool does, where to get the input, and what to do with the result. It is complete for the complexity level.

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

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

Schema coverage is 100%, and the schema description already specifies 'The community post ID to fork (from search_community results).' The tool description reiterates this same guidance without adding new details, so it adds only marginal value beyond the schema.

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

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

The description uses a specific verb 'Fork (copy)' and identifies the resource as 'community workflow' which clearly distinguishes it from general flow or template operations. It does not explicitly name alternative sibling tools, but the scope is unambiguous enough to avoid confusion.

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

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

The description provides clear usage context: it tells the agent to get post_id from search_community results, and explains what can be done after forking. It does not explicitly state when not to use this tool or name alternatives, but the guidance is sufficient for a straightforward operation.

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

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

The description describes a copy operation, which is non-destructive, but annotations set destructiveHint=true, directly contradicting the description. This is a serious inconsistency, so the description fails to convey accurate 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 consists of two concise sentences. The first defines the action, and the second gives a useful next step. There is no unnecessary 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 single-parameter tool, the description adequately covers the action and a key subsequent step. However, it omits any mention of return values or side effects, which would be useful, but overall it is sufficiently complete for the tool's simplicity.

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

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

Schema coverage is 100% for the single parameter template_id, with a clear schema description referencing list_templates. The description adds no additional parameter semantics, so the baseline 3 applies.

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

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

The description explicitly states 'Fork (copy) a workflow template into your workspace', using a specific verb and resource. It clearly differentiates from siblings like duplicate_flow (for existing flows) and fork_community_flow (community flows).

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

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

The description provides context that after forking, you can run it with run_flow, implying a clear use case. It doesn't explicitly name alternatives or exclusions, but the target resource (template) is distinct and unambiguous.

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 claims a read-only status check, but annotations declare destructiveHint=true and readOnlyHint=false. This is a direct contradiction. The description does not disclose any destructive or side-effecting behavior, and the annotation suggests otherwise, so the transparency score is 1 with an 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 one concise sentence that conveys both the purpose and return behavior. No wasted words, front-loaded with the main action, and appropriately sized for the simple tool.

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

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

The description provides partial return value information (progress and output URLs) but fails to clarify the contradictory annotations (destructiveHint=true). It also doesn't specify behavior when the batch is still running or error conditions, leaving important gaps for a status-checking 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 single parameter batch_run_id is fully described in the schema (100% coverage) as 'The batch run identifier returned by run_batch.' The tool description adds no additional parameter semantics beyond what the schema already provides, so a baseline 3 is appropriate.

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

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

The description clearly states the tool checks the status of a batch run, with a specific verb ('Check') and resource ('status of a batch run'). It distinguishes from sibling tools like get_flow_status by focusing on batch runs specifically.

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 batch runs, and the parameter description mentions it is returned by run_batch, but there is no explicit guidance on when to use this vs alternatives or exclusions. It is not misleading, but lacks direct usage context.

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

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

The description describes a read-only operation ('Get detailed information'), but annotations mark destructiveHint=true and readOnlyHint=false. This is a direct contradiction. The description provides no context to resolve the conflict or disclose any side effects, making it unsafe for an agent to rely on.

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 purpose, then usage context. Every word earns its place; no fluff or repetition. It's a model of concise, informative writing.

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 lists the specific content fields returned (title, content, tags, input/output types, engagement stats), compensating for the lack of an output schema. It also provides a use case ('preview a post before forking it'), making it reasonably complete for a simple single-parameter tool. However, the contradiction with annotations leaves a gap in safety transparency.

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

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

The schema already fully describes the only parameter (post_id) with a clear description: 'The community post ID (from search_community results).' The tool description adds no additional semantics beyond what the schema provides, so the baseline of 3 applies.

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

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

The description clearly states the tool retrieves detailed community post information, listing specific attributes (title, content, tags, input/output types, engagement stats). It clearly distinguishes itself from siblings like search_community (which lists posts) and get_flow (which gets a flow). The verb 'get' matches the tool name and 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?

The description provides explicit usage context: 'Use this to preview a post before forking it.' This tells the agent when to use the tool. It doesn't explicitly name alternatives, but the context is clear enough given the sibling list includes search_community and fork_community_flow.

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 declare destructiveHint=true and readOnlyHint=false, implying the tool may have side effects or mutations. Yet the description says 'Get detailed information about a specific workflow,' which clearly indicates a read-only operation. This directly contradicts the annotations, warranting a score of 1 per the rubric.

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

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

The description is a single sentence that is concise and front-loaded with the core purpose. It contains no filler or redundant information, earning a perfect score.

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

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

The tool is simple (one parameter) and has no output schema, so the description must carry the full burden. It does indicate the type of details returned (nodes, connections, parameters), but the contradiction with annotations leaves the agent confused about safety. The missing usage context and behavioral inconsistency make it incomplete for reliable invocation.

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

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

The input schema has 100% coverage since flow_id is described as 'The unique identifier of the flow.' The description adds no additional semantics for the parameter (e.g., format, examples, or constraints). It focuses on the output rather than the parameter, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool 'Get detailed information about a specific workflow, including its nodes, connections, and parameters.' It identifies the verb (get) and resource (specific workflow details). However, it does not distinguish itself from sibling tools like describe_flow or get_flow_status, so it falls short of a 5.

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

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

No usage guidance is provided. The description does not specify when to use this tool versus alternatives like describe_flow or get_flow_status, nor does it mention any prerequisites or selection criteria. It only gives a basic definition, leaving the agent without decision support.

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 states this is a read-only 'check', but annotations include destructiveHint=true and readOnlyHint=false, directly contradicting the described behavior. This is a significant inconsistency that could mislead an agent into thinking the tool has destructive 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 sentences, front-loaded with the primary purpose and then a concise description of return value. No wasted words.

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

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

The tool is simple with one parameter and no output schema. The description explains what is returned (per-node status and output URLs), which is sufficient for basic use. It could mention possible statuses, but that is not critical for a low-complexity tool.

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

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

The input schema fully covers the only parameter (flow_id) with a clear description. The tool description adds no additional parameter context, but schema coverage is 100%, so baseline of 3 is appropriate.

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

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

The description clearly states the tool checks the execution status of a workflow, with a specific verb ('check') and resource ('execution status of a workflow'). It also distinguishes from siblings like run_flow, cancel_flow, and get_flow by focusing on status and output files.

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

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

The description implies this is used after running a flow to inspect its status and outputs. It does not explicitly name alternatives or exclusions, but the context is clear enough that the agent can infer when to use it versus related tools.

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

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

The description describes a read-only operation ('Get'), but the annotations include destructiveHint=true and readOnlyHint=false, directly contradicting the description. No additional behavioral context is provided to resolve this conflict.

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

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

The description is a single sentence that is front-loaded with the verb and resource. It is concise and contains no 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?

For a simple zero-parameter tool, the description provides essential output information. However, the contradictory annotations and lack of an output schema leave ambiguity about the exact response structure and whether any side effects exist.

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 baseline is 4. The description does not need to add parameter semantics, and it appropriately includes output fields instead.

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') and the resource ('your user profile information'), listing example fields (ID, email, name). This distinguishes it from sibling tools like get_workspace_info or get_flow.

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 it should be used to fetch the current user's profile, but it does not explicitly state when to use it versus alternatives, nor does it mention any conditions or exclusions. There is no comparison with other 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 description directly contradicts the annotations. It says 'Get detailed information' (a read operation) while annotations include destructiveHint: true and readOnlyHint: false. This is a serious inconsistency that misleads the agent about potential side effects. The description also fails to disclose any safety or permission traits beyond what the annotations already misstate.

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, tightly packed sentence with no filler. Every word contributes to understanding the tool's scope and return content, making it highly efficient and well-structured.

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

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

The tool is simple (one parameter), but the absence of an output schema places a burden on the description to explain return values. It mentions inputs, outputs, parameters, and plan requirements, but fails to address the contradictory annotations or clarify that this is a non-destructive read. The description is incomplete in resolving safety and side-effect expectations.

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

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

Schema coverage is 100%, and the parameter model_id is well-described with examples. The description adds semantic value by specifying that the returned information includes inputs, outputs, parameters, and plan requirements, which enriches the meaning of the model_id parameter and the tool's purpose. This goes beyond the schema's bare identifier 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 uses a specific verb and resource: 'Get detailed information about a specific AI model'. It clearly distinguishes from siblings like list_models (listing all models) and get_model_parameters (parameters only) by mentioning inputs, outputs, parameters, and plan requirements. This leaves no ambiguity about the tool's 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 provides no guidance on when to use this tool versus alternatives. It does not mention when to use get_model vs list_models or get_model_parameters, nor any exclusions or prerequisites. The context is clear but the lack of comparative usage guidance limits helpfulness.

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 describes a read-only 'Get' operation, but annotations set readOnlyHint=false and destructiveHint=true, implying the operation may have side effects. This is a direct contradiction, and the description provides no additional behavioral context to resolve it.

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, front-loaded with the main action and followed by a useful usage context. Every word earns its place with no redundancy.

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

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

For a simple tool with one parameter and no output schema, the description adequately states purpose and use case. However, the annotation contradiction introduces confusion about actual behavior, though the description itself is largely 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 input schema fully documents model_id with a clear description, and the description reiterates it's for a specific model. No additional parameter semantics are provided beyond the schema, but since schema coverage is 100%, baseline of 3 is appropriate.

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

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

The description clearly states the tool retrieves the configurable parameters schema for a specific AI model, using the specific verb 'Get' and a specific resource. It distinguishes itself from sibling tools like get_model by focusing on parameters schema and even mentions the use case for creating flows.

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

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

The description provides clear usage context: 'Use this to understand what settings can be adjusted when creating a flow with this model.' However, it does not explicitly mention when not to use the tool or name alternative tools, falling short of full exclusion guidance.

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

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

The description says 'Get your notifications', indicating a safe read operation, but the annotations set destructiveHint=true and readOnlyHint=false. This is a direct contradiction: the description implies non-destructive read behavior while annotations flag it as destructive. This violates the rule that score 1 applies when the description contradicts 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 sentences, immediately identifies the tool's purpose, then mentions pagination. There is no filler or redundant information. Every sentence earns its place, and the structure is front-loaded with the core action.

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 fully explains what the tool does and how pagination works, which is sufficient for a simple one-parameter tool. However, the annotation contradiction leaves the agent uncertain about the tool's safety profile, so the overall context is not fully reliable. It is adequate but with a notable gap in consistency.

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 'cursor' is fully described in the schema with instructions for pagination. The description adds the same semantic by mentioning 'Use next_cursor from response for subsequent pages' but doesn't provide extra meaning beyond the schema's 100% coverage. The baseline of 3 applies as the schema does the heavy lifting.

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

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

The description clearly states 'Get your notifications (likes, comments, forks, follows, mentions)', using a specific verb and resource with concrete types. It distinguishes itself from sibling tools like get_unread_notification_count by focusing on retrieving full notification items, not counts, and from mark_read variants by being a read operation.

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

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

The description implies the primary use case—fetching the user's notifications—and explains pagination behavior. However, it does not explicitly contrast with get_unread_notification_count or other notification tools, nor does it state when to prefer this tool over alternatives. The context is clear but lacks specific when-not or alternative 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 directly contradicts the annotations. It claims a read-only operation via 'get', while annotations set readOnlyHint=false and destructiveHint=true, implying the tool may mutate state or have destructive side effects. No behavioral context is provided to reconcile this.

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 clear sentence, front-loaded with the key information. It is appropriately sized for a simple tool with no parameters and no output schema, with no wasted words.

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

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

The description is too sparse given the contradictory annotations. It fails to explain the actual behavior (e.g., whether it is a true read or has side effects), does not describe the return value, and offers no context about scope or filtering. This is insufficient for safe 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 tool has zero parameters and the schema is empty, so the baseline of 4 applies. The description does not need to add parameter details beyond what the schema already covers.

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

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

The description clearly states the action ('get') and the specific resource ('number of unread notifications'), making it distinct from the sibling tool get_notifications, which likely returns a list. It is specific and unambiguous.

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

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

There is no guidance on when to use this tool versus alternatives. The description does not mention any contextual cues, exclusions, or alternative tools such as get_notifications for retrieving details.

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 characterizes the tool as a read-only information retrieval ('Get', 'Shows'), but annotations declare destructiveHint: true and readOnlyHint: false. This is a direct annotation contradiction, and the description provides no behavioral disclosure to resolve it.

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, front-loaded with the primary purpose and free of redundant detail. Every word adds value.

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

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

Given the tool's zero-parameter interface and simple informational nature, the description adequately conveys its function. However, the annotation contradiction introduces confusion that is not addressed in the description, slightly reducing 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?

With zero parameters, schema coverage is 100%. The description adds meaningful context by explaining what the tool returns (usage percentage, plan limits, reset schedule), exceeding the baseline for parameter-less tools.

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' with a specific resource 'GPU usage for your workspace' and details what it shows (percentage, plan limits, reset schedule). This distinguishes it from siblings like get_workspace_info or get_flow_status.

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

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

The description implies usage when a user needs to check GPU usage, limits, or reset schedule, but it does not explicitly mention alternatives or exclusions. The context is sufficient for basic guidance but lacks explicit when-to-use vs. 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 states 'Get information' implying a non-destructive read operation, but annotations declare destructiveHint: true, readOnlyHint: false, and idempotentHint: false. This is a direct contradiction; the description completely fails to disclose any destructive or non-idempotent behavior, which could mislead the agent about the tool's 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 a single, concise sentence that directly states the tool's purpose and key output. Every word earns its place, with no redundancy 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?

While the simple tool with no parameters could be adequately described by this short sentence, the annotations contradict the description and the tool lacks an output schema. The description does not address why destructiveHint is true or reconcile the read-only implication with the annotations, leaving critical safety information incomplete.

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

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

The tool has zero parameters, so schema description coverage is 100% and no parameter explanations are needed. The description adds value by listing the returned data fields, which is beyond the empty schema, aligning with the baseline of 4 for tools with no 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 uses a specific verb ('Get') and resource ('workspace_info'), and explicitly lists the information returned ('subscription plan, member count, and seats'). This clearly distinguishes it from sibling tools like get_me or get_usage, which focus on other aspects.

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 such as get_me or get_usage. The context signals show sibling tools that could overlap, but the description offers no exclusions or specific scenarios, leaving the agent to infer usage.

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 describes a read-only operation, but annotations set destructiveHint=true and readOnlyHint=false, directly contradicting the description. This is a serious inconsistency.

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, front-loaded with the action and then the return details. No wasted words.

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

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

The description covers the purpose and output fields. For a zero-parameter tool, it is sufficiently complete, though it does not address pagination or side effects, which is mitigated by the simple scope.

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?

No parameters exist, so the description correctly omits parameter details. The baseline of 4 applies since the schema has no parameters requiring explanation.

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 lists all API keys in the workspace and mentions the displayed fields (preview, status, usage stats, expiration). Distinguishes from sibling tools like create_api_key and delete_api_key.

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?

Implies the tool is for viewing keys, but does not explicitly mention alternatives or conditions. Since it's the only list operation among siblings, the context is clear, though no exclusions are provided.

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

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

The description says 'List AI workflows', implying a non-destructive read operation, yet the annotations indicate destructiveHint=true and readOnlyHint=false. This is a direct contradiction, and the description does not disclose any actual side effects or behavioral nuances. The tool's true behavior is opaque and inconsistent with its stated purpose.

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 core action ('List AI workflows'), and includes essential output details (returned fields, pagination). Every word earns its place, with no fluff 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?

With no output schema, the description should compensate by explaining return values; it does mention flow names, statuses, metadata, and pagination. However, given the contradictory annotations (destructiveHint=true) and no discussion of potential side effects or prerequisites, the description is incomplete for understanding the tool's full behavior. It covers the basics but leaves significant gaps.

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

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

The schema covers all three parameters (page, state, search) with descriptions, so the baseline is 3. The description adds only that pagination exists, but does not explain parameter usage or defaults beyond what the schema already provides. It neither enhances nor hinders parameter understanding.

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

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

The description uses a specific verb ('List') and resource ('AI workflows') and clearly distinguishes from sibling tools like get_flow or describe_flow by indicating it returns multiple items with metadata. It states the scope ('in your workspace') and output content, 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 implies this tool is for enumerating workflows ('List AI workflows'), which contrasts with tools that retrieve or modify a single flow. However, it does not explicitly state when to use this vs alternatives, nor any exclusions or prerequisites. Usage context is implied but not fully articulated.

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 declare destructiveHint=true and readOnlyHint=false, which directly contradict the description's implication of a read-only listing operation. This is a serious annotation contradiction because 'List available LLM providers' is inherently non-destructive and read-only. No behavioral context is provided to reconcile this conflict.

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 of concise, high-value information: the first states the action and output, the second explains the significance ('Configured providers enable external model nodes in workflows'). Every word earns its place, with 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's simplicity (no parameters, no output schema), the description is nearly complete, covering what is listed, the configuration status check, and the practical consequence. However, the contradictory destructiveHint annotation undermines overall contextual clarity, preventing a perfect score.

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, and the schema coverage is 100% (empty properties), which serves as the baseline for a perfect score of 4. The description adds value by explaining what the output indicates—whether API keys are configured—which is the primary semantic meaning beyond the empty schema.

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

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

The description clearly states the tool lists available LLM providers and their API key configuration status, matching the name and providing a specific verb and resource. It distinguishes itself from sibling tools like list_models and list_api_keys by focusing on providers and their configured status.

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

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

The description implies when to use this tool: when you need to check whether workspace API keys are configured for providers, and notes that configured providers enable external model nodes in workflows. It does not explicitly exclude alternatives, but the context is clear enough for an agent to select this tool for provider availability checks.

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 implies a read-only operation ('List'), which directly contradicts the annotation destructiveHint: true and readOnlyHint: false. No additional behavioral traits are disclosed beyond the return value list, and the contradiction makes this highly misleading.

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, front-loaded with the main action and return values. No 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?

For a list tool with rich schema, the description adequately states the returned fields and filter usage. It lacks mention of pagination or default behavior, but given the schema richness, this is not a critical gap. However, the contradiction with annotations reduces completeness in practice.

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 covers all 5 parameters with descriptions, so the schema already provides the meaning. The description only says 'optional filters' without adding details beyond the schema, yielding the baseline score.

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

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

The description uses the specific verb 'List' with the resource 'AI models on cnaps.ai', clearly distinguishing it from siblings like get_model and find_compatible_models. The return fields are stated.

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 clear context that filters should be used to narrow results, giving practical usage guidance. However, it does not explicitly mention when to prefer alternative tools like get_model or exclude cases, so it stops short of a 5.

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

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

Annotations declare destructiveHint=true and readOnlyHint=false, but the description says 'List', implying a read-only operation. This is a direct contradiction between the description and the structured annotations, resulting in the lowest score.

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, front-loaded with the main action ('List curated workflow templates'), then defines the context and next step. No wasted words.

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

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

The tool is simple with no parameters, but the description fails to address the contradictory destructiveHint annotation, which is a critical safety concern. Additionally, without an output schema, the description doesn't explain what the returned list contains beyond 'templates', leaving some ambiguity.

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

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

The tool has zero parameters and an empty schema, so the baseline for this dimension is 4. The description correctly omits parameter explanations since none exist.

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 action ('List') and the resource ('curated workflow templates on cnaps.ai'). It also distinguishes from sibling tools like list_flows and list_models by specifying 'templates' rather than generic flows or models.

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 context that templates are pre-built, tested workflows and explicitly directs the user to fork_template to use a template. Lacks explicit exclusions for when not to use this tool, but the guidance 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 indicate destructive=true, readOnly=false, and openWorld=true. The description only restates the literal action without adding context about side effects, irreversibility, or scope beyond what the annotations convey. The open world hint is not addressed.

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 with no redundancy. It is front-loaded and perfectly appropriate for the tool's trivial complexity.

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

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

For a zero-parameter tool, the description adequately states the core action. However, it does not differentiate from sibling mark_notification_read or explain consequences, and the openWorldHint suggests potential side effects that are not described. Adequate but with clear gaps.

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

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

There are zero parameters and the schema is empty, so schema coverage is 100%. Per instructions, a baseline of 4 applies when there are no parameters; the description has nothing to clarify.

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 clear verb and resource: 'Mark all notifications as read.' It explicitly states the scope ('all') which distinguishes it from the sibling tool 'mark_notification_read' that handles a single notification.

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 use case (when you want to mark all notifications as read) but does not explicitly contrast with alternatives like mark_notification_read or get_unread_notification_count. There is no when/when-not guidance or mention of prerequisites.

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 aligns with annotations (readOnlyHint=false, destructiveHint=true) and adds the scope of the action ('specific'). However, it does not disclose additional behavioral traits such as idempotency, error conditions, or irreversibility, which are only partially covered by 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, efficient sentence that immediately states the action and target. It is front-loaded with the verb and contains no redundant words, earning a perfect score for conciseness.

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

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

Given the tool's simplicity (one required parameter, full schema coverage, and annotations covering safety), the description is largely sufficient. It names the action and target but omits details like return behavior or edge cases, which are not critical for this simple mutation tool.

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

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

The schema already provides a complete description of 'notification_id' ('The notification ID to mark as read.'). The tool description adds no new meaning beyond what the schema and parameter description already convey, so a baseline score of 3 is appropriate.

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

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

The description clearly states the action ('mark as read') and the resource ('a specific notification'). Including 'specific' distinguishes it from the sibling tool 'mark_all_notifications_read', making the scope 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 no explicit guidance on when to use this tool versus alternatives. It does not mention the existence of 'mark_all_notifications_read' or any conditions for selecting this tool over others, providing no usage direction beyond the basic action.

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 declare destructiveHint=true and readOnlyHint=false, while the description says 'Analyze a flow' and 'returns suggestions' with patches for the caller to apply. This implies a read-only analysis, contradicting the annotations. Since the description contradicts structured metadata, the score is 1.

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. It front-loads the purpose, provides concrete examples, mentions the patch mechanism, gives usage context, and explains the optional parameter in a single paragraph 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?

No output schema exists, so the description must explain return values; it does by saying 'returns rule-based suggestions' each with a mechanical patch. It covers usage context and optional behavior. However, the contradiction with annotations leaves uncertainty about side effects, preventing a perfect score.

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

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

Schema coverage is 100%, with each parameter fully described. The description reiterates the include_llm_analysis parameter but adds no new syntax or semantic detail beyond the schema. Baseline 3 is appropriate as the schema does the heavy lifting.

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

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

The description clearly states the tool analyzes a flow for performance and cost optimization opportunities, with specific examples (moving upscale nodes, avoiding resolution overflow). It distinguishes itself from sibling tools like diagnose_error or validate_flow by focusing on optimization suggestions with mechanical patches.

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: 'before running a flow or while iterating on its design.' It also explains when to enable the optional include_llm_analysis parameter. However, it does not name alternative tools or explicitly state when not to use, so it's not a perfect 5.

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

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

The description states 'Rename a workflow,' which conveys a mutating operation, consistent with the annotations (readOnlyHint=false, destructiveHint=true). However, it does not disclose any additional behavioral details such as irreversibility, permission requirements, or impact on dependent resources, so it adds little 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 consists of a single, direct sentence with no unnecessary words. It is appropriately sized for the tool's simplicity and front-loads the core 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 tool is simple with two well-documented parameters and clear annotations, so the description covers the fundamental functionality. However, it lacks usage context, such as when to prefer this over update_flow, and does not describe any potential side effects beyond the destructive hint.

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

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

The input schema already provides descriptions for both parameters (name and flow_id) with 100% coverage, so the description does not need to explain them. The description itself adds no parameter-level semantics beyond what the schema provides, which aligns with the baseline for high schema coverage.

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

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

The description uses the specific verb 'Rename' with the resource 'workflow', clearly identifying the intended operation. It distinguishes from siblings like delete_flow or create_flow, though it does not explicitly differentiate from update_flow, which could also modify 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?

The description provides no guidance on when to use this tool versus alternatives such as update_flow or duplicate_flow. There is no mention of prerequisites, exclusions, or typical use cases.

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

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

The annotations include destructiveHint=true and readOnlyHint=false, but the description adds context that 'reports are stored and analyzed to improve the platform.' This goes beyond annotations but does not detail side effects, data handling, or irreversibility. No contradiction with annotations.

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

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

Two sentences, front-loaded with the action, no wasted words. It efficiently covers purpose and usage in a compact form.

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 rich schema (12 params, all with descriptions) and the simple reporting purpose, the description is complete: it explains why to use the tool and what happens afterward. No output schema is needed for this kind of action.

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

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

Input schema covers 100% of parameters with descriptions, so the baseline is 3. The tool description adds no extra meaning about parameters; all needed semantics are already in the schema.

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

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

The description clearly states the tool's purpose: 'Report a tool failure or confusion to the cnaps.ai team.' This is a specific verb+resource (report + to team) and distinguishes it from siblings like 'diagnose_error' by focusing on sending feedback rather than analyzing errors.

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 tells when to use the tool: 'when you encounter persistent errors, unclear documentation, or missing features.' However, it does not mention alternatives or when NOT to use it, so it lacks the full exclusion guidance for a 5.

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

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

Annotation contradiction. The description says 'restore' which is non-destructive, but destructiveHint=true indicates a destructive operation. This is a serious inconsistency because restoring implies undoing deletion, not causing destruction, and the description does not explain any destructive 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 sentences, front-loaded with the main action, and the second sentence provides a useful cross-reference to a sibling tool. Every word earns its place, and there is no redundancy.

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

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

For a single-parameter tool, the description covers purpose and usage guidance, but the contradiction with destructiveHint creates ambiguity about safety and side effects. This makes the overall context less reliable for an agent.

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

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

Schema coverage is 100%, so the schema already documents flow_id as 'The unique identifier of the trashed flow to restore.' The description adds no additional parameter-specific meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description clearly states the action (restore), the resource (a workflow), and the state transition (from trash to active). It distinguishes itself from siblings like delete_flow and list_flows by specifying the exact 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?

It explicitly tells the agent to use list_flows with state='trashed' to find trashed flows, providing a concrete alternative for a prerequisite step. This gives clear context on when this tool 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?

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, establishing this is a mutating, non-idempotent operation. The description adds that it returns a batch_run_id for tracking and that inputs are arrays of file URLs, which is useful behavioral context. However, it does not elaborate on side effects, permissions, or asynchronous behavior beyond the tracking ID, so it only moderately supplements 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 two sentences, front-loaded with the primary purpose, and contains no redundant information. Every phrase adds value, from the batch mode clarification to the input node array behavior and return value.

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

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

The tool is moderately complex, with no output schema, but the description covers the essential return value (batch_run_id) and the asynchronous nature implied by tracking. It also references the prerequisite upload step. It could be more complete by mentioning potential failure modes or that the workflow runs asynchronously, but given the annotations and sibling tools like get_batch_status, it is sufficiently complete 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?

Schema coverage is 100% with both parameters well-documented in the input schema. The description adds a minor detail by noting that inputs are file URLs uploaded via upload_file and that each input node receives an array, which slightly enriches the schema's example. But the schema already conveys the structure, so the description provides only nominal extra 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 uses the specific verb 'Run' and identifies the resource as 'a workflow in batch mode with multiple input file sets,' clearly distinguishing it from the sibling tool run_flow. It also explains the batch-specific behavior of each input node receiving an array of file URLs, which differentiates it from a single-run tool.

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

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

The description provides clear context on when to use this tool: for batch mode with multiple file sets, and it references upload_file as the source of file URLs. It also mentions the batch_run_id for tracking, which implies using get_batch_status for follow-up. However, it does not explicitly exclude run_flow for single workflows, so the usage guidance is strong but not fully explicit about 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 discloses the critical behavioral trait of asynchronous execution, which is not captured in annotations. It also provides operational context around input handling via upload_file. The annotations already signal destructive and non-read-only behavior, and the description complements them without 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?

Two sentences, each serving a clear purpose: the first states the core function, the second explains async behavior and input source. No filler or redundancy. The description is front-loaded and efficiently conveys essential information.

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

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

For an async execution tool without an output schema, the description adequately explains the overall flow: execute, then poll with get_flow_status, and how to supply inputs. It could explicitly mention what the tool returns (e.g., a run ID) for polling, but that is implied by the reference to get_flow_status. The annotations and sibling tools fill some remaining 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 input schema has 100% description coverage, so the baseline is 3. The description adds value by linking the inputs parameter to file URLs from upload_file, a useful cross-reference not present in the schema. It doesn't repeat schema details but provides actionable context for 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 action ('Execute an AI workflow') and provides scope (asynchronous execution, input node handling). It distinguishes from sibling tools like dry_run_flow and run_batch by emphasizing the actual execution and the need to poll for completion with get_flow_status. The verb+resource is specific and avoids tautology.

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

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

The description gives clear usage context: flows run asynchronously, so the agent must poll via get_flow_status. It also provides guidance for handling flows with input nodes by referencing upload_file for file URLs. However, it doesn't explicitly mention when to prefer alternatives like dry_run_flow or run_batch, which would warrant a 5.

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

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

Annotation contradiction: annotations declare destructiveHint=true and readOnlyHint=false, while the description describes a read-only search operation. This is a serious inconsistency. The description also provides no additional behavioral context (e.g., side effects, auth needs), so it fails to clarify the 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?

Three sentences, each with a distinct purpose: description, search dimensions, and usage guidance with return value. No filler or redundancy.

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

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

The description provides a return value hint (post IDs) since there is no output schema, but the annotation contradiction leaves a major gap in behavioral expectations. It does not explain pagination or sort behavior, though schema covers those. Overall, incomplete due to the contradiction.

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

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

Schema coverage is 100%, so the baseline is 3. The description mentions 'keyword, input/output modality, or tags' which loosely maps to query, input_type/output_type, and tags, but adds no new semantic detail beyond what the schema already provides.

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

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

The description clearly states the tool searches for community-shared AI workflows, with specific search dimensions (keyword, input/output modality, tags). It also distinguishes itself by mentioning the result is post IDs for forking with fork_community_flow, which separates it from related sibling 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?

Explicitly states when to use: 'Use this to discover existing workflows before creating new ones.' It implies integration with fork_community_flow but does not name alternative tools or exclusions. Clear context, though no explicit when-not-to-use.

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

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

Annotations set destructiveHint=true, but the description describes a purely informational action (returning model recommendations). This directly contradicts the annotation, so transparency scores minimum per rule.

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

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

Three sentences: action, usage alternative, and return format. Front-loaded and every sentence earns its place with no 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?

Description covers the essential return behavior and usage context. However, the unresolved destructiveHint contradiction slightly undermines completeness, and the description does not mention optional narrowing parameters (though schema covers 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?

Schema coverage is 100% with detailed descriptions and examples for all three parameters. The description adds no extra parameter semantics, so baseline 3 applies.

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

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

Description uses a specific verb ('Suggest'), identifies the resource ('individual AI models'), and scopes the action to 'a specific task', clearly distinguishing it from the sibling tool suggest_pipeline.

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?

Description explicitly states when to use this tool ('when the user specifically asks about model options for a single processing step') and when to use suggest_pipeline instead ('multi-step goal'), providing unambiguous 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 discloses that it is a suggestion step and does not execute pipelines ('After getting a suggestion, use create_pipeline...'), which implies non-destructive behavior. It adds behavioral context beyond annotations by explaining parameter inference and multi-language support. The destructiveHint annotation is not contradicted because the description does not claim to be purely read-only, but it does not explicitly address the annotation's warning, hence a small deduction.

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 'RECOMMENDED FIRST STEP' and contains three dense sentences, each conveying actionable information. It is slightly verbose with all caps but every sentence earns its place 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 tool is complex, and the description covers its purpose, usage order, parameter semantics, and next steps. It lacks explicit return format details, but given the absence of an output schema, the high-level description of 'optimal model pipeline with parameter recommendations and wiring' is adequate. Sibling context further clarifies its role.

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

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

Schema coverage is 100% with clear descriptions for task, input_type, and output_type. The description adds value by giving examples ('remove person from photo', '배경 제거해줘') and explaining that '4K' maps to scale_factor=4, which is semantic enrichment beyond schema.

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

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

The description clearly states the tool's function: 'returns the optimal model pipeline with parameter recommendations and wiring' for image/video/text processing. It distinguishes from siblings by naming list_models and suggest_models and highlighting multi-step task handling and parameter inference.

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 marks itself as 'RECOMMENDED FIRST STEP' and instructs to use it BEFORE list_models or suggest_models, with clear reasons (handles multi-step, parameter inference, automatic model selection). It also provides next-step guidance to create_pipeline or create_and_run_pipeline.

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

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

The description adds valuable behavioral context beyond annotations: parameters are merged with existing values (so unspecified parameters retain current values) and running flows cannot be updated. This complements the destructiveHint and readOnlyHint 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 and well-structured: it starts with the primary purpose, then usage, merge behavior, and a limitation. Every sentence contributes essential information without redundancy.

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

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

Given the tool's moderate complexity, the description covers purpose, usage, merge semantics, and a key constraint. The detailed schema handles parameter documentation, so the description is sufficiently complete for an agent to invoke the tool correctly.

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

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

The input schema already provides complete descriptions for both parameters, including examples and merge semantics. The description adds only general examples of model settings, not significantly more meaning beyond the schema's existing 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 updates node parameters in an existing workflow, with specific examples (scale_factor, steps, seed). It distinguishes from sibling tools like update_flow_tags and create_flow by specifying that it updates node parameters without recreating the flow.

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 to modify model settings without recreating the flow, and provides a clear when-not-to-use condition: 'Cannot update a flow that is currently running.' This gives clear guidance on appropriate usage.

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 the tool as destructive and not read-only, but the description adds the critical nuance that only 'manual tags' are replaced, not necessarily all tags. This goes beyond the annotations and helps the agent understand the exact 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 short, front-loaded sentences with no wasted words. The description earns its place 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?

For a simple two-parameter tool with annotations, this description is adequate. It covers the core behavior and effect, and the absence of an output schema is not a major gap at this complexity level.

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

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

Schema coverage is 100%, so the schema already explains flow_id and tags clearly. The description adds the replacement semantics but no additional parameter-level details, aligning with the baseline expected when the schema fully documents parameters.

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

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

The description clearly states the tool updates tags on a workflow and clarifies the replacement behavior. It is specific and distinguishable from sibling tools like update_flow or rename_flow.

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

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

The description implies the tool is used to set the full set of tags, and the explicit 'Replaces all existing manual tags' warns against expecting a merge. However, it does not explicitly mention when not to use it or name alternatives, leaving some room for 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?

Annotations already indicate destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds valuable behavioral context: it downloads from a public URL, accepts a specific list of file types, and registers files for AI workflows. It does not mention side effects like permanent storage or deletion possibilities, but with annotations covering the core safety traits, a 4 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?

The description is moderately long but each sentence serves a purpose: stating the primary action, listing supported types, indicating a key use case, and providing an important exclusion. It is well-structured and front-loaded, though the final sentence somewhat reiterates the 'public URL' point from the opening. It remains clear and 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?

The description covers purpose, usage guidelines, supported types, constraints, and alternatives. It is complete for a tool with two parameters and no output schema. It clearly tells the agent when to use this tool and when to choose upload_image instead, making it self-sufficient for correct invocation.

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

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

Schema description coverage is 100%, so parameter descriptions already exist. The description adds meaningful context beyond the schema by enumerating supported file types and emphasizing that the file_url must be a public HTTP/HTTPS URL. This clarifies the expected format and constraints, going beyond the basic 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 tool's purpose: 'Upload a file from a public URL for use in AI workflows.' It uses a specific verb and resource, and explicitly distinguishes itself from the sibling tool upload_image by noting 'If the user wants to upload an image/video from the chat, use upload_image instead.'

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

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

The description provides explicit usage guidance with context, including when to use the tool ('Use this to register a video for the Video Analysis node'), when not to use it ('use upload_image instead'), and the condition for use ('ONLY for when the user provides a public HTTP/HTTPS URL'). It also names the alternative sibling tool, making the decision 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 two-step process (call without token, then with token), the 15-minute wait, and the return of file URLs. This goes beyond the annotations, which only indicate non-read-only and destructive hints. However, the destructiveHint=true from annotations is not addressed or explained in the description, leaving a minor gap.

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

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

The description is longer than typical, but every sentence contributes necessary context for a multi-step tool. It is structured with step labels, making it easy to follow. It earns a slightly above-average score for being detailed without being verbose.

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

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

Given the lack of an output schema, the description explains the return value (file URLs) and even specifies how they can be used in create_flow or run_flow. It includes timeout and the two-step protocol. Missing details include what happens on timeout or error, and why the destructive hint is set, so it is not fully complete.

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

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

The schema already provides 100% coverage of the token parameter, and the description reinforces this by explaining the exact workflow: omit to create, then provide immediately to wait. This adds procedural meaning beyond the schema's static description, clarifying the token's lifecycle.

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

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

The description clearly states that this is the DEFAULT method to get files from users (images, video, or audio) and it creates a browser upload link. It distinguishes from directly provided URLs or local file paths, but there is a sibling tool 'upload_file' that is not differentiated. Thus it is specific but not fully distinguished from all siblings.

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

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

The description explicitly tells when to use: whenever the user wants to process/upload a file but has NOT provided a direct URL or local file path. It also states a critical limitation: files cannot be transferred from chat to cnaps.ai via MCP. This provides clear contextual guidance and an implicit alternative.

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

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

The annotations mark this tool as destructiveHint: true, yet the description describes only validation checks with no mention of side effects or mutations. This is a direct contradiction, undermining trust in the tool's behavior. The description adds some context (returns {valid, issues}) but fails to reconcile the destructive hint.

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-loading the purpose in the first sentence, followed by specific checks and usage guidance. It contains no fluff and every sentence adds value, making it 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?

For a simple validation tool with one parameter and no output schema, the description covers purpose, checks, return format, and usage. However, it omits any clarification about the destructiveHint annotation, which is a significant gap given the contradiction. This prevents it from being fully complete.

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

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

The input schema already fully describes flow_id with a clear description, achieving 100% schema coverage. The tool description does not add further parameter-level semantics beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose with a specific verb and resource: 'Validate a workflow before running it.' It also lists specific checks (trashed state, missing input files, disconnected nodes, currently running) and provides a return value, distinguishing it from related tools like run_flow or dry_run_flow.

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 recommends using this tool before run_flow to catch problems early, providing clear usage context. It does not mention when not to use it or alternative tools beyond run_flow, but the guidance is direct and actionable.

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