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

With no annotations provided, the description carries the full burden and does well by disclosing key behaviors: it explains the batch conversion process, the 'skip_failures' parameter's effect on error handling, and the return format (dictionary mapping names to SMILES or errors). However, it omits details like rate limits, authentication needs, or performance characteristics.

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

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

The description is well-structured with clear sections (purpose, args, returns, examples) and uses bullet points in examples for readability. However, the 'Args' section redundantly repeats schema information, and the examples are lengthy, slightly reducing efficiency. Overall, it is front-loaded and informative.

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, 100% schema coverage, and the presence of an output schema (implied by 'Returns' section), the description is complete. It covers purpose, parameters, return values, and provides practical examples, leaving no significant gaps for an AI agent to understand 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%, so the schema already fully documents both parameters. The description repeats the parameter descriptions verbatim in the 'Args' section, adding no additional semantic context beyond what the schema provides. This meets the baseline but does not enhance understanding.

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

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

The description clearly states the specific action ('Convert multiple molecule names to SMILES in batch') and distinguishes it from the sibling 'molecule_lookup' tool by emphasizing batch processing. The title 'batch_molecule_lookup' reinforces this distinction, making the purpose immediately apparent.

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

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

The description provides clear context for when to use this tool ('Useful for preparing multiple molecules for workflows or screening'), but it does not explicitly state when not to use it or mention alternatives like the sibling 'molecule_lookup' for single-molecule conversions. The guidance is helpful but lacks explicit exclusions.

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

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

With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it mentions credit limits ('max_credits'), time variability based on workflow type and molecule count, and subscription requirements for certain workflow types ('nmr requires subscription upgrade'). However, it doesn't explicitly state whether this is a read-only or mutation operation.

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

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

The description is well-structured with clear sections (formatting notes, args, usage contexts, supported types, returns, examples). While comprehensive, some information like the extensive examples could be considered slightly verbose, though each example serves a distinct illustrative purpose for different workflow types.

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 6-parameter tool with no annotations and no output schema, the description provides excellent coverage: purpose, usage guidelines, parameter formatting, behavioral constraints, return values, and multiple examples. The main gap is lack of explicit safety/authorization information, but otherwise it's nearly complete for agent understanding.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds significant value beyond the schema by providing formatting notes with concrete examples, explaining what 'auto-generated' means for names, clarifying that empty strings use defaults, and listing supported workflow types with availability notes. This compensates well for the schema's technical 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 specific action ('Submit multiple workflows of the same type for different molecules') and distinguishes it from sibling tools by emphasizing batch processing efficiency. It explicitly mentions using the Rowan v2 API, which provides technical context not present in the tool name alone.

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 contexts with a 'Useful for:' section listing four specific scenarios (high-throughput property prediction, library screening, dataset generation, systematic comparison). It also distinguishes this tool from single-workflow submission siblings by emphasizing batch efficiency for multiple molecules.

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

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

No annotations are provided, so the description carries full burden. It states 'Create a protein' which implies a write/mutation operation, but doesn't disclose behavioral traits like whether this requires authentication, what happens on duplicate names/PDB IDs, rate limits, or side effects. The return format is mentioned but lacks detail on structure or errors.

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

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

The description is appropriately concise with a clear purpose statement followed by Args and Returns sections. However, the Args section redundantly repeats schema information without adding value, and the Returns section is vague ('Dictionary containing protein information'). It's front-loaded but includes some waste.

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

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

Given that this is a mutation tool with no annotations, 2 parameters, and an output schema exists (implied by 'Has output schema: true'), the description is minimally adequate. It states the purpose and parameters but lacks important context like behavioral transparency, usage guidelines, and detailed return semantics that the output schema might cover.

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

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

Schema description coverage is 100%, so the schema already fully documents both parameters. The description repeats the parameter descriptions verbatim from the schema ('Name for the protein', 'PDB ID code') without adding any additional semantic context, examples beyond '1HCK', or constraints. This meets the baseline for high schema coverage.

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

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

The description clearly states the action ('Create a protein') and the resource source ('from a PDB ID'), which is specific and unambiguous. However, it doesn't distinguish this tool from sibling tools like 'upload_protein' or 'retrieve_protein', leaving some ambiguity about when to use this versus those alternatives.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'upload_protein' or 'retrieve_protein'. It mentions the PDB ID input but doesn't explain prerequisites, use cases, or exclusions. This leaves the agent with minimal context for tool selection.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Delete a protein' but doesn't clarify if this is permanent, reversible, requires specific permissions, or has side effects (e.g., cascading deletion of associated data). For a destructive tool with zero annotation coverage, this lack of detail is a significant gap, though it at least correctly identifies the action as deletion.

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

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

The description is front-loaded with the core action ('Delete a protein') and uses a structured format with 'Args:' and 'Returns:' sections, making it easy to parse. However, the 'Returns' section is redundant given the presence of an output schema, and the overall content could be more concise by omitting this repetition.

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

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

Given the tool's destructive nature, lack of annotations, and presence of an output schema, the description is minimally adequate. It covers the basic purpose and parameter but misses critical behavioral details (e.g., permanence, permissions). The output schema handles return values, so the description's inclusion of 'Returns' is unnecessary but not harmful. For a deletion tool, more context on risks and dependencies would improve completeness.

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

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

The description adds minimal value beyond the input schema, which has 100% coverage for the single parameter 'uuid'. It repeats the parameter description verbatim ('UUID of the protein to delete'), providing no additional context such as format examples or where to obtain the UUID. With high schema coverage, the baseline score of 3 is appropriate, as the schema already documents the parameter adequately.

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

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

The description clearly states the action ('Delete') and resource ('a protein'), making the purpose immediately understandable. It distinguishes this tool from siblings like 'list_proteins', 'retrieve_protein', and 'create_protein_from_pdb_id' by specifying a destructive operation. However, it doesn't explicitly mention what 'delete' entails (e.g., permanent removal vs. soft deletion), which prevents a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing the protein's UUID from 'list_proteins' or 'retrieve_protein'), nor does it warn against misuse (e.g., deleting proteins in use by workflows). While the tool name implies a destructive action, explicit usage context is absent.

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

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

No annotations are provided, so the description carries full burden. It mentions pagination behavior ('page' and 'size' parameters) and return format ('List of protein dictionaries'), which is helpful. However, it doesn't disclose critical behavioral traits like whether this lists all proteins or filtered subsets, authentication requirements, rate limits, error conditions, or what fields the dictionaries contain. For a read operation with zero annotation coverage, this leaves significant gaps.

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

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

The description is appropriately concise with three short lines. It's front-loaded with the core purpose ('List proteins'), followed by parameter and return details. There's no wasted text, though the parameter explanations are redundant with the schema. The structure is clear but could be more efficient by omitting the schema-duplicate details.

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

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

Given the tool's low complexity (simple list operation), 100% schema coverage, and presence of an output schema (implied by 'Has output schema: true'), the description is minimally adequate. However, it lacks context about what 'proteins' means in this system, how results are ordered, or any limitations. With no annotations, it should provide more behavioral context to be fully complete.

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

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

Schema description coverage is 100%, with both parameters ('page' and 'size') fully documented in the schema. The description repeats the parameter explanations verbatim from the schema ('Page number (0-indexed)', 'Number per page'), adding no additional meaning. According to the rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description.

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

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

The description states 'List proteins' which is a clear verb+resource combination, but it's extremely minimal. It doesn't specify what kind of proteins (e.g., all proteins, user's proteins, public proteins) or provide any context about the scope. While it distinguishes from siblings like 'retrieve_protein' (singular) and 'create_protein_from_pdb_id', it lacks the specificity needed for a 4 or 5 score.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'retrieve_protein' (for single proteins) or 'batch_molecule_lookup' (which might overlap). There's no context about prerequisites, filtering capabilities, or typical use cases. The agent must infer usage from the name alone.

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

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

With no annotations provided, the description carries full burden. It discloses pagination behavior and error handling (HTTPError), which are valuable. However, it doesn't mention authentication requirements, rate limits, performance characteristics, or what happens when no workflows match criteria. The 'Returns' section describes output format at a high level but lacks detail about dictionary structure.

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

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

The description is well-structured with clear sections (Args, Returns, Raises) and efficiently communicates key information. However, the opening sentence is somewhat redundant with the tool name, and the parameter documentation could be more concise given the comprehensive schema coverage.

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

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

For a read-only list operation with 8 parameters and no output schema, the description provides adequate but not comprehensive coverage. It explains filtering and pagination but lacks details about authentication, rate limits, and the structure of returned workflow dictionaries. Given the complexity (8 parameters, no annotations), more behavioral context would be helpful.

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

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

Schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly. The description's 'Args' section essentially repeats what's in the schema without adding significant new semantic context. The baseline is 3 when schema does the heavy lifting, though the description does reinforce parameter purposes.

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

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

The description clearly states the verb ('List') and resource ('workflows'), and specifies filtering criteria. However, it doesn't explicitly differentiate from sibling tools like 'retrieve_workflow' (singular) or explain how this list operation relates to workflow submission tools.

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

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

No guidance is provided about when to use this tool versus alternatives. The description doesn't mention sibling tools like 'retrieve_workflow' (for single workflow) or explain that this is for browsing/searching workflows rather than retrieving specific ones. No prerequisites or context for usage are stated.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it converts identifiers to SMILES, handles various input types, includes a fallback mechanism, returns SMILES or error messages, and provides examples of successful conversions. It lacks details on rate limits, authentication needs, or error handling specifics, but covers core functionality well.

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

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

The description is well-structured with clear sections (purpose, args, context, returns, examples) and uses bullet points for readability. It is appropriately sized but includes some redundancy (e.g., repeating parameter info from the schema). Most sentences add value, such as explaining the tool's role in workflows and listing input types.

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, no annotations, and an output schema (implied by 'Returns' section), the description is complete. It covers purpose, parameters, usage context, return values, and examples. The output schema handles return format details, so the description need not elaborate further, making it sufficient for effective use.

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

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

Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds minimal value beyond the schema: it repeats the parameter descriptions in the 'Args' section and provides examples of 'molecule_name' inputs. No additional syntax, format, or constraints are explained, meeting the baseline for high schema coverage.

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

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

The description clearly states the tool's purpose: 'Convert molecule names to SMILES using Chemical Identifier Resolver (CIR).' It specifies the verb ('convert'), resource ('molecule names'), and output format ('SMILES'), and distinguishes it from siblings like 'validate_smiles' (which validates rather than converts) and 'batch_molecule_lookup' (which handles multiple inputs).

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

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

The description provides clear context for when to use this tool: 'enables natural language input for molecules by converting common names, IUPAC names, CAS numbers, and other identifiers to SMILES strings that can be used with Rowan workflows.' It lists supported input types and includes examples. However, it does not explicitly state when not to use it or name alternatives like 'validate_smiles' for already-known SMILES strings.

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

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

No annotations are provided, so the description carries the full burden. It mentions that it 'retrieves a list' (implying read-only) and notes potential HTTP errors, but lacks details on permissions, rate limits, or what happens if the calculation UUID is invalid. It adds some context but is incomplete for a tool with no annotations.

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

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

The description is well-structured and concise, with a clear purpose statement followed by Args, Returns, and Raises sections. Every sentence serves a purpose, and there's no redundant information, making it easy to parse.

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

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

Given the tool's low complexity (1 parameter, no nested objects) and the presence of an output schema (implied by 'Returns' section), the description is reasonably complete. It covers the basic operation and error handling, though it could benefit from more behavioral details given the lack of annotations.

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

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

The schema description coverage is 100%, so the schema already documents the 'uuid' parameter fully. The description repeats the parameter info in the Args section but doesn't add meaning beyond what the schema provides, such as format examples or constraints. Baseline 3 is appropriate given high schema coverage.

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

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

The description clearly states the tool's purpose: 'Retrieve a list of molecules from a calculation.' It specifies the verb ('retrieve') and resource ('molecules from a calculation'), making it understandable. However, it doesn't explicitly differentiate from sibling tools like 'molecule_lookup' or 'batch_molecule_lookup,' which might retrieve molecules from other sources.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or contexts where this retrieval is preferred over other molecule-related tools, leaving the agent without usage direction beyond the basic purpose.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. While 'retrieve' implies a read operation, it doesn't specify whether this requires authentication, has rate limits, returns partial vs complete data, or handles errors (e.g., invalid UUID). The mention of returning a 'dictionary' is helpful but insufficient for a mutation-free tool with zero annotation coverage.

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

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

The description is appropriately brief and front-loaded with the core purpose in the first sentence. The Args/Returns sections are structured but slightly redundant with the schema. Every sentence serves a purpose, though the parameter documentation could be more integrated to avoid repetition.

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

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

Given the tool's simplicity (single parameter, read-only operation) and the presence of an output schema (implied by 'Has output schema: true'), the description is minimally adequate. However, with no annotations and multiple sibling tools, it lacks context on authentication, error handling, and differentiation from alternatives, leaving gaps for an AI agent.

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

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

The schema description coverage is 100%, with the single parameter 'uuid' fully documented in the schema. The description repeats the parameter information without adding meaningful context beyond what's already in the schema (e.g., format examples, validation rules, or where to find UUIDs). This meets the baseline score when schema coverage is high.

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 ('retrieve') and resource ('protein by UUID'), making the purpose immediately understandable. It distinguishes itself from siblings like 'list_proteins' (which returns multiple items) and 'create_protein_from_pdb_id' (which creates rather than retrieves). However, it doesn't explicitly contrast with 'retrieve_workflow' or 'retrieve_calculation_molecules', which have similar retrieval patterns but different resources.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'retrieve_protein' over 'list_proteins' for finding a specific protein, or how it relates to 'upload_protein' or 'create_protein_from_pdb_id' for protein creation. There's also no mention of prerequisites like needing an existing protein UUID.

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

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

With no annotations provided, the description carries full burden and does well by disclosing key behaviors: it's a read operation (implied by 'retrieve'), returns complete data in one call, includes error handling details (raises ValueError/RuntimeError), and shows polling patterns in the example. It doesn't mention rate limits or authentication specifics beyond API errors, but covers most essential behavioral aspects.

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

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

The description is well-structured with clear sections (description, args, returns, example, raises) and front-loads the core purpose. The example is detailed but necessary to demonstrate usage patterns. Some redundancy exists (e.g., 'Returns: Dictionary with complete workflow data' repeats earlier points), but overall it's efficient and informative.

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

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

Given the tool has 1 parameter with 100% schema coverage and an output schema exists, the description provides excellent completeness. It explains what the tool does, when to use it, includes a comprehensive example with error handling, and covers behavioral aspects. No significant gaps remain for this type of retrieval tool.

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

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

Schema description coverage is 100% for the single parameter 'uuid', so the baseline is 3. The description adds value by explaining the UUID is 'of the workflow to retrieve' and showing its usage in examples, providing context beyond the schema's basic description. However, it doesn't add format details (like UUID version) or validation rules.

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 'retrieve' and resource 'workflow data', specifying it includes 'status, results, and metadata'. It distinguishes from siblings like 'list_workflows' (which lists workflows) and 'workflow_delete' (which deletes workflows) by emphasizing this is for retrieving complete data of a specific workflow.

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

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

The description explicitly states 'This is THE primary function for getting workflow information in a single API call', providing clear guidance on when to use it. It also includes an example showing usage for checking status and getting results, which implicitly contrasts with alternatives like polling or separate status-check tools.

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

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

No annotations are provided, so the description carries the full burden. It states the tool sanitizes a protein but doesn't disclose what 'sanitize' entails (e.g., structural cleanup, format conversion, validation), whether it's a read-only or destructive operation, permission requirements, or rate limits. The description is vague about behavioral traits beyond the basic action.

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

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

The description is appropriately sized and front-loaded, with the core purpose stated first. The Args and Returns sections are structured but somewhat redundant with the schema. Every sentence serves a purpose, though the Returns statement is minimal and could be more informative if not for the output schema.

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

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

Given the tool has one parameter with full schema coverage and an output schema exists, the description is reasonably complete for its complexity. It covers the basic purpose and parameter, though it lacks details on behavioral aspects. The output schema handles return values, so the description's minimal Returns statement is acceptable.

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

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

The schema description coverage is 100%, with the single parameter 'uuid' documented in the schema as 'UUID of the protein to sanitize'. The description repeats this exactly in the Args section, adding no additional meaning or context beyond what the schema provides. With high schema coverage, 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: 'Sanitize a protein for docking.' It specifies the action (sanitize) and resource (protein) with a clear goal (for docking). However, it doesn't explicitly differentiate from sibling tools like 'upload_protein' or 'create_protein_from_pdb_id', which might also involve protein preparation steps.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether the protein must already exist in the system), exclusions, or relationships to sibling tools like 'submit_docking_workflow' that might involve docking processes. Usage context is implied but not explicit.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool 'submits' a workflow, implying it initiates a calculation that may consume resources (credits), and it mentions tracking via workflow name and folder. However, it lacks details on behavioral traits such as whether this is an asynchronous operation, expected runtime, error handling, or what happens if credits are exceeded. The description adds some context but is incomplete for a submission tool.

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

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

The description is well-structured with sections for purpose, args, returns, and examples, making it easy to scan. However, it includes redundant information (e.g., repeating parameter details already in schema) and could be more concise by focusing on value-added content. The ADMET explanation is useful but slightly 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 tool's complexity (submission workflow with 4 parameters) and lack of annotations and output schema, the description is moderately complete. It covers the purpose, parameters, and returns at a high level, but it lacks details on behavioral aspects like async handling, error cases, or output structure. The examples help but do not fully compensate for missing context.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description repeats parameter information in the 'Args' section but does not add significant meaning beyond what the schema provides, such as explaining SMILES format nuances or credit usage implications. It meets the baseline for high schema coverage without enhancing parameter understanding.

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

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

The description clearly states the tool's purpose with specific verb ('submit') and resource ('ADMET workflow'), and it distinguishes this tool from siblings by specifying it predicts 'drug-like properties using ADMET-AI' rather than other types of calculations like docking or protein analysis. The description goes beyond the name by explaining what ADMET stands for and its role in drug discovery.

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

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

The description implies usage context through the ADMET explanation and examples, suggesting this is for early-stage drug discovery assessment. However, it does not explicitly state when to use this tool versus alternatives like 'submit_basic_calculation_workflow' or other sibling tools, nor does it provide exclusions or prerequisites for use.

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

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

With no annotations provided, the description carries full burden. It mentions 'returns a workflow object for tracking progress', which is useful, but doesn't disclose critical behavioral traits like whether this is a long-running async operation, error handling, rate limits, authentication needs, or cost implications (despite 'max_credits' parameter). For a submission tool with no annotation coverage, this is a significant gap.

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

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

The description is well-structured with a concise opening statement followed by helpful examples. However, the examples are lengthy (taking most of the text) and could be more efficiently integrated; some sentences in the examples don't directly enhance understanding beyond the first one.

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 (7 parameters, no output schema, no annotations), the description is moderately complete. It covers purpose and provides examples, but lacks output details, error handling, and behavioral context needed for a submission tool. It's adequate but has clear gaps in guiding the agent on what to expect after 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 the schema already documents all 7 parameters thoroughly. The description adds minimal value beyond the schema—it mentions 'configurable methods and computational tasks' which aligns with the 'method' and 'tasks' parameters, but provides no additional syntax, format, or semantic details. Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the tool's purpose with specific verbs ('submit', 'performs') and resources ('basic calculation workflow', 'quantum chemistry calculations'), and distinguishes it from siblings by specifying it's for 'fundamental' calculations with 'configurable methods and computational tasks', unlike specialized workflows like docking or protein analysis.

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

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

The description implies usage through examples showing specific scenarios (e.g., energy calculation, optimization), but lacks explicit guidance on when to use this tool versus alternatives like 'submit_conformer_search_workflow' or 'submit_docking_workflow'. It doesn't state prerequisites or exclusions.

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

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

With no annotations provided, the description carries the full burden. It effectively discloses key behavioral traits: it's a submission tool (implies mutation/write operation), mentions credit spending ('max_credits'), and provides practical context like default values and performance implications ('Higher values = more thorough but slower'). However, it doesn't explicitly state error conditions 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?

Perfectly structured and front-loaded: purpose statement first, then parameter details with clear explanations, followed by usage scenarios and return information. Every sentence adds value with no redundancy. The example is appropriately placed at the end for illustration without disrupting the flow.

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

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

For a complex 9-parameter tool with no annotations and no output schema, the description does an excellent job covering purpose, parameters, usage, and behavior. It provides a concrete example showing proper invocation. The only minor gap is lack of explicit information about return format details beyond 'Workflow object', but this is partially mitigated by the example showing usage.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds significant value by explaining parameter semantics beyond the schema: it clarifies protein can be 'PDB ID string' or 'Protein UUID string', specifies pocket format as 'JSON string "[[x1,y1,z1], [x2,y2,z2]]"', and explains the practical meaning of 'exhaustiveness' and 'max_credits'. The example also demonstrates proper 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 specific action ('Submit a batch docking workflow') and resource ('for high-throughput virtual screening using Rowan v2 API'), distinguishing it from siblings like 'submit_docking_workflow' (single docking) and other workflow types (e.g., 'submit_admet_workflow'). It explicitly mentions handling multiple ligands against a single protein target.

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 scenarios ('Useful for: - Virtual screening campaigns - Lead optimization - Fragment library screening - Structure-activity relationship studies'), which clearly indicate when to use this tool. It differentiates from siblings by focusing on batch processing of multiple ligands, unlike 'submit_docking_workflow' which likely handles single ligands.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does an excellent job describing key behavioral traits: the rapid conformer generation mode details (RDKit/MMFF, 300 conformers, 0.10 Å RMSD cutoff), the return format (Workflow object), and the computational resource implications (max_credits parameter). It doesn't mention rate limits or authentication requirements, but provides substantial operational context.

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

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

The description is well-structured with clear sections (purpose, Args, behavioral details, Returns, Example). Most sentences earn their place, though the Args section could be more concise since it largely duplicates schema information. The front-loaded purpose statement is excellent, but some redundancy with the schema prevents 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?

For a complex workflow submission tool with 7 parameters and no annotations or output schema, the description provides substantial context: purpose, all parameters (via schema), behavioral details about the conformer generation mode, return value information, and an example. It doesn't explain error conditions or provide more detailed examples, but covers the essentials well given the complexity.

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

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

Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description's Args section largely repeats what's in the schema with minor variations (e.g., 'gas phase' vs 'vacuum' for solvent). The example adds some value by showing a minimal usage pattern, but doesn't provide significant semantic information 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 specific action ('Submit a conformer search workflow') and resource ('using Rowan v2 API'), distinguishing it from sibling tools like 'submit_conformers_workflow' or 'submit_basic_calculation_workflow' by specifying the exact workflow type. The opening sentence provides immediate clarity about what this tool does.

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

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

The description provides clear context for when to use this tool (for conformer search workflows with specific parameters like initial molecule and optimization methods). However, it doesn't explicitly state when NOT to use it or name specific alternatives among the many sibling workflow submission tools, which prevents a perfect score.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool does (submits a workflow that generates molecular conformations), explains the purpose ('essential for accurate property predictions and understanding molecular flexibility'), and mentions resource constraints ('Maximum credits to spend'). However, it doesn't disclose potential side effects like whether this consumes computational resources asynchronously or requires specific permissions.

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

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

The description is well-structured with clear sections (purpose statement, Args, explanatory paragraph, Note, Returns). It's appropriately sized for an 11-parameter workflow tool. While efficient, the Args section could be more concise since it duplicates schema information, and the explanatory paragraph could be integrated more tightly with the purpose statement.

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

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

For a complex workflow tool with 11 parameters and no output schema, the description provides good context. It explains the tool's purpose, distinguishes it from siblings, documents all parameters, and describes what it returns. However, without annotations or output schema, it could better explain the workflow's asynchronous nature, potential errors, or the structure of the returned Workflow object.

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

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

The schema description coverage is 100%, so the baseline is 3. The description includes an 'Args' section that lists all parameters with brief explanations, but these largely repeat what's already documented in the schema properties. It adds minimal additional context beyond what the structured 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's purpose with specific verbs ('submit', 'generate') and resources ('conformers workflow', 'molecular conformations'). It explicitly distinguishes this tool from its sibling 'submit_conformer_search_workflow' by explaining that this workflow focuses on 'conformer generation and enumeration' while the sibling performs 'conformational search with optimization'.

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

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

The description provides explicit guidance on when to use this tool versus alternatives. It includes a dedicated note section that directly contrasts this tool with 'submit_conformer_search_workflow', explaining that this one 'focuses on conformer generation and enumeration' while the sibling performs different functionality. This gives clear context for tool selection.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: it's a submission workflow (implies mutation/creation), includes credit usage constraints ('Maximum credits to spend'), and specifies typical runtime ('10-30 seconds to complete'). However, it doesn't mention permissions, error handling, or whether the workflow is reversible, leaving some gaps.

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

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

The description is well-structured with clear sections (Args, Calculates, Returns, Example) and front-loaded purpose. It includes useful details like descriptor types and examples, but the list of descriptor categories could be more concise. Overall, it's efficient with minimal waste, though slightly verbose in parts.

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 no annotations and no output schema, the description does a good job covering the tool's context: it explains what the tool does, lists parameters with examples, describes output ('Workflow object'), and includes behavioral details like credit limits and runtime. However, it lacks information on error cases or how to handle the returned workflow object, leaving minor gaps.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema, such as clarifying that 'folder_uuid' uses a default folder if empty and 'max_credits' of 0 means no limit, but these are largely redundant. Baseline score of 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 specific action ('Submit a molecular descriptors calculation workflow') and resource ('using Rowan v2 API'), distinguishing it from sibling tools like 'submit_admet_workflow' or 'submit_basic_calculation_workflow' by focusing on descriptor calculation. It provides a comprehensive list of descriptor types being calculated, making the purpose explicit and differentiated.

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

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

The description implies usage through examples (e.g., basic descriptor calculation, complex molecule) but does not explicitly state when to use this tool versus alternatives like 'submit_basic_calculation_workflow' or 'batch_submit_workflow'. It mentions typical completion time (10-30 seconds), which offers some contextual guidance but lacks explicit when/when-not instructions or named alternatives.

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

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

With no annotations provided, the description carries full burden. It discloses that the tool 'automatically handles protein creation from PDB ID and sanitization if needed', which is valuable behavioral context. However, it doesn't mention critical aspects like whether this is a long-running asynchronous operation, what happens on submission failure, or any rate limits/authentication requirements.

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

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

The description is front-loaded with the core purpose, but includes extensive parameter documentation that largely duplicates schema information. While the examples are helpful, they add substantial length. The structure could be more efficient by focusing only on what the schema doesn't already cover.

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 complex tool with 12 parameters, no annotations, and no output schema, the description provides good parameter semantics and examples. However, it lacks critical context about the workflow's asynchronous nature, error handling, and relationship to sibling tools. The 'Returns' section is minimal, stating only 'Workflow object' without detailing its structure or how to track completion.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds significant value by providing concrete examples of parameter formats (PDB ID strings, JSON structures, SMILES strings), explaining what 'exhaustiveness' controls ('Higher values = more thorough but slower'), and clarifying that 'max_credits: 0' means 'no limit'. This goes well beyond the schema's basic 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 with the specific verb 'submits' and resource 'Docking workflow to the API'. It distinguishes from siblings like 'submit_batch_docking_workflow' by focusing on single workflow submission, though it doesn't explicitly contrast with other docking-related tools like 'submit_conformer_search_workflow'.

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

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

The description provides no guidance on when to use this tool versus alternatives. With siblings like 'submit_batch_docking_workflow', 'submit_conformer_search_workflow', and 'submit_pose_analysis_md_workflow', there's no indication of when this single docking submission is preferred over batch processing or other related workflows.

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

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

With no annotations provided, the description carries full burden and does well by disclosing critical failure conditions ('workflow will fail if atom counts don't match'), computational cost implications ('Maximum credits to spend'), and workflow organization behavior ('folder to organize this workflow'). It doesn't fully cover rate limits or detailed error responses, but provides substantial behavioral context.

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

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

The description is well-structured with clear sections (purpose, constraints, args, returns, examples) and every sentence adds value. It front-loads the most critical information (purpose and constraints) and uses examples efficiently to illustrate complex parameter relationships 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?

For a complex 9-parameter workflow submission tool with no annotations and no output schema, the description provides substantial context including purpose, constraints, parameter relationships, and return value explanation. It could benefit from more detail about the returned 'Workflow object' structure, but otherwise covers most essential aspects given the complexity.

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

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

With 100% schema description coverage, the baseline is 3, but the description adds significant value by explaining the critical relationship between reactant and product parameters ('MUST have same atom count'), providing context for JSON settings parameters, and clarifying default behaviors. The examples further illustrate parameter usage beyond 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 specific action ('Submit a double-ended transition state search workflow') and resource ('using Rowan v2 API'). It distinguishes from sibling tools by focusing on transition state searches between reactant and product molecules, unlike other workflow types like docking or ADMET.

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

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

The description explicitly states when to use this tool ('More robust than single-ended TS optimization when both endpoints are known') and provides critical constraints ('Reactant and product MUST have the exact same number and types of atoms'). It also distinguishes from alternatives by mentioning single-ended TS optimization as a comparison point.

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

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

With no annotations provided, the description carries full burden. It discloses that this is a workflow submission tool (implying it's a write operation that initiates calculations), mentions credit spending limits via max_credits, and describes what the tool returns (a workflow object). However, it doesn't cover important behavioral aspects like error conditions, timeouts, authentication requirements, or what happens with invalid inputs.

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

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

The description is well-structured with clear sections (purpose, args, returns, example) and front-loaded with the main purpose. However, the Fukui indices explanation could be more concise, and some parameter details in the Args section slightly duplicate schema information. Overall efficient but with minor redundancy.

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

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

For a 7-parameter workflow submission tool with no annotations and no output schema, the description provides adequate but incomplete context. It covers the purpose, parameters, returns, and includes an example, but lacks information about error handling, rate limits, authentication requirements, and detailed output structure. The absence of output schema means the description should ideally explain the workflow object structure more thoroughly.

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

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

Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description adds minimal value beyond the schema - it provides example values for optimization_method and fukui_method options, and clarifies that solvent_settings is a JSON string. However, it doesn't add significant semantic context beyond what's already in the parameter 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 specific action ('Submit a Fukui indices calculation workflow') and resource ('using Rowan v2 API'), distinguishing it from siblings like submit_admet_workflow or submit_basic_calculation_workflow. It explicitly mentions calculating Fukui indices to predict molecular reactivity, which is a distinct computational chemistry task.

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

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

The description provides clear context for when to use this tool (for Fukui indices calculations to predict molecular reactivity), but doesn't explicitly state when not to use it or name specific alternatives among the sibling tools. It implies usage for reactivity analysis but lacks explicit exclusions or comparisons to other workflow submission 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?

With no annotations provided, the description carries full burden and does well by explaining what the tool does (submits a workflow for pKBHX prediction), mentions resource constraints (max_credits parameter), provides context about hydrogen bond basicity importance, and shows return type. However, it doesn't disclose execution time, error conditions, or authentication requirements that would be helpful 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 well-structured with clear sections (purpose, Args, explanation, Returns, Examples) and appropriately sized. However, the Args section largely duplicates schema information, and the hydrogen bond basicity explanation paragraph could be more tightly integrated with the tool's purpose rather than appearing as a separate educational note.

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 workflow submission tool with 6 parameters, 100% schema coverage, but no annotations or output schema, the description provides good context: clear purpose, parameter examples, return type indication, and practical examples. It could improve by explaining workflow states, error handling, or how to retrieve results using sibling tools like retrieve_workflow.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema through the Args section that mostly repeats schema information, though it provides helpful examples showing parameter usage in context. Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the specific action ('submit a hydrogen bond basicity workflow'), the resource ('to predict pKBHX values'), and distinguishes it from siblings by focusing on hydrogen bond basicity prediction rather than other computational chemistry workflows like ADMET, docking, or pKa calculations listed among 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 provides implied usage through examples showing different scenarios (basic prediction, with conformer search/optimization, for drug molecules), but lacks explicit guidance on when to use this tool versus alternatives like other workflow submission tools or when not to use it. No direct comparison to sibling tools is provided.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the tool 'submits' a workflow and returns a 'Workflow object,' implying a write operation with tracking, but lacks details on permissions, rate limits, costs (beyond credits), or error handling. The example adds some practical context but doesn't fully compensate for the missing annotation coverage.

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

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

The description is well-structured with clear sections (purpose, args, use cases, returns, example) and avoids redundancy. However, it could be more front-loaded by moving the 'Useful for' bullet points earlier for quicker scanning, and the example is detailed but necessary for clarity.

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

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

Given the complexity (8 parameters, workflow submission), no annotations, and no output schema, the description is adequate but has gaps. It explains the purpose, parameters, and use cases well, but lacks details on behavioral aspects like authentication, response format beyond 'Workflow object,' or error scenarios, making it minimally viable but not fully comprehensive.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds marginal value by grouping parameters in an 'Args:' section and providing an example that illustrates usage with 'initial_molecule,' 'protonate,' and 'name,' but doesn't significantly enhance understanding beyond the schema. The baseline is 3, but the example and clear parameter listing justify a slight bump.

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

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

The description clearly states the specific action ('Submit an ion mobility (CCS) prediction workflow') and resource ('using Rowan v2 API'), distinguishing it from siblings like 'submit_admet_workflow' or 'submit_docking_workflow' by focusing on collision cross-section prediction for ion mobility mass spectrometry.

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

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

The description provides clear context for when to use this tool ('Predicts collision cross-section (CCS) values... Useful for: - Validating experimental IM-MS data - Predicting CCS values for method development - Structural characterization of biomolecules'), but does not explicitly mention when not to use it or name specific alternatives among the 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?

With no annotations provided, the description carries full burden. It discloses that this is a submission/write operation ('Submits'), mentions credit spending limits ('Maximum credits to spend'), and describes the return value ('Workflow object'), but doesn't cover important behavioral aspects like error handling, asynchronous nature, execution time, or what happens when max_credits is exceeded.

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

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

The description is well-structured with clear sections (Args, Returns, Example) and front-loads the purpose. The example is helpful but could be more concise. Some parameter explanations in the description slightly duplicate schema information, but overall it's efficiently organized.

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

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

For a complex 8-parameter workflow submission tool with no annotations and no output schema, the description provides adequate basics but lacks important context. It explains what the tool does and parameters but doesn't cover workflow lifecycle, error scenarios, or what the returned 'Workflow object' contains. Given the complexity, more behavioral context would be helpful.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by providing an example with specific parameter usage (HNCO + H₂O IRC), clarifying that 'folder_uuid' uses 'Empty string for default folder', and giving typical ranges for 'step_size' (0.03-0.1 Bohr). However, it doesn't explain the computational differences between method options.

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

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

The description clearly states the specific action ('Submits') and resource ('Intrinsic Reaction Coordinate workflow to the API'), distinguishing it from sibling tools like 'submit_basic_calculation_workflow' or 'submit_docking_workflow' by specifying the IRC calculation type. The first sentence provides a complete purpose statement.

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

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

The description implies usage context through the example (HNCO + H₂O IRC) and parameter explanations, but lacks explicit guidance on when to choose this tool over alternatives like 'submit_double_ended_ts_search_workflow' or 'submit_scan_workflow'. No when-not-to-use or prerequisite information is provided.

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

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

With no annotations provided, the description carries full burden and does an excellent job disclosing key behavioral traits: performance characteristics (8x speed difference, ~5 min vs ~40 min runtime), waiting requirements ('WAIT ~5 min (fast) or ~40 min (slow)'), polling guidance ('Use workflow_is_finished() to poll'), and rate limit warnings ('not more than once per minute to avoid loops'). It doesn't cover all possible edge cases, but provides substantial operational context.

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

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

The description is well-structured with clear sections (purpose, performance, modes, args, returns, examples) and every sentence adds value. It could be slightly more concise in the parameter explanation section, but overall it's efficiently organized with no wasted text.

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

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

For a complex 10-parameter workflow tool with no annotations and no output schema, the description provides excellent context: clear purpose, detailed usage guidelines, performance expectations, runtime behavior, and practical examples. The main gap is the lack of information about the return format ('Workflow object' is vague), but given the comprehensive operational guidance, this is a minor limitation.

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

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

With 100% schema description coverage, the baseline is 3. The description adds significant value by explaining the practical implications of key parameters: it clarifies that compute_aqueous_solubility=False enables 'fast mode' for relative comparisons while True enables 'slow mode' for absolute values, and provides performance context. However, it doesn't add meaningful context for all 10 parameters beyond what the schema provides.

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

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

The description clearly states the specific action ('Submit a Macroscopic pKa workflow') and resource ('using Rowan v2 API'), with detailed explanation of what it calculates (pKa values, microstate populations, net charge across pH range). It effectively distinguishes from siblings by focusing on macroscopic pKa calculations, unlike other workflow tools for different purposes like docking or solubility.

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

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

The description provides explicit guidance on when to use fast vs. slow modes: 'Fast mode (False): ... Sufficient to determine which pH has highest/lowest solubility' and 'Slow mode (True): ... Only needed for absolute values or fold-changes.' It also includes practical examples with specific use cases, making it clear when to choose each alternative.

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

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

With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it's a submission tool (implies mutation), mentions runtime ('10-30 minutes depending on sequence length'), and explains the return value ('Returns: Workflow object representing the submitted workflow'). However, it doesn't mention error conditions, authentication needs, 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 well-structured with clear sections (Args, Valid output formats, Returns, Examples), but contains some redundancy (parameter explanations repeated from schema) and could be more front-loaded. The runtime information at the end is useful but could be integrated earlier.

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 5-parameter mutation tool with no annotations and no output schema, the description does well by explaining the purpose, usage scenarios, parameters, return values, and providing examples. It covers the essential context needed to use the tool effectively, though it could benefit from more behavioral details like error handling.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema - it repeats parameter explanations and provides examples but doesn't add significant semantic context that isn't already in the 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 specific action ('Submit a multiple sequence alignment workflow') and resource ('using Rowan v2 API'), distinguishing it from sibling tools like submit_protein_cofolding_workflow or submit_docking_workflow by focusing exclusively on MSA generation for protein sequences.

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 lists when to use this tool ('Useful for: Protein structure prediction with AlphaFold2/ColabFold, Structure prediction with Chai-1, Structure prediction with Boltz-1, Evolutionary analysis and homology modeling') and provides clear alternatives through the output format options, helping users choose appropriate configurations.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool does (submits a workflow for sequential geometry refinement), mentions efficiency benefits, and provides context about credit limits. However, it doesn't disclose potential rate limits, authentication requirements, or error conditions.

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

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

The description is well-structured with clear sections (purpose, args, use cases, returns, examples). While comprehensive, some sentences could be more concise, such as the multi-paragraph explanation of use cases. However, all content earns its place by providing necessary 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?

For a complex 8-parameter workflow tool with no annotations and no output schema, the description provides substantial context: clear purpose, parameter explanations, use cases, return value description, and extensive examples. It adequately compensates for the lack of structured metadata, though could benefit from more behavioral details.

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

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

With 100% schema description coverage, the baseline is 3. The description adds value by grouping parameters in an 'Args:' section with clear explanations and default values, and the examples demonstrate how parameters interact in practical scenarios, providing context beyond the schema's technical 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 with specific verbs ('submit a multi-stage optimization workflow') and resource ('sequential geometry refinement'). It distinguishes from siblings by focusing on multi-stage optimization for geometry refinement, unlike other workflow tools for docking, descriptors, or protein-related tasks.

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

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

The description explicitly states when to use this tool ('particularly useful for: - Large or complex molecules - Transition state searches - High-accuracy geometry requirements - Systems where initial geometry is poor'). It also provides multiple examples showing different use cases, helping distinguish from alternative workflow 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?

With no annotations provided, the description carries full burden and does well: it explains this is a workflow submission (implying asynchronous processing), mentions credit spending limits, and describes what microscopic pKa calculation entails. However, it doesn't disclose potential rate limits, authentication requirements, or error conditions.

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

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

Perfectly structured: starts with purpose statement, provides conceptual explanation, lists parameters with examples, describes return value, and includes a practical code example. Every sentence earns its place with no redundancy or wasted words.

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

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

For a 7-parameter workflow submission tool with no annotations and no output schema, the description does well: explains the calculation type, parameters, returns, and includes an example. However, it doesn't fully address what happens after submission (how to monitor workflow, typical runtime, or how to retrieve results).

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by providing a clear conceptual explanation of microscopic pKa, practical examples of parameter values, and an example showing how to use the tool with specific parameters, going beyond the schema's technical 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 specific action ('Submit a microscopic pKa prediction workflow') and resource ('using Rowan v2 API'), with a detailed explanation of what microscopic pKa means. It distinguishes from siblings by focusing specifically on pKa prediction, unlike other workflow tools for different calculations like docking, ADMET, or protein operations.

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

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

The description implies usage for pKa prediction of molecules via SMILES strings, but doesn't explicitly state when to use this tool versus alternatives like submit_macropka_workflow (a sibling tool) or other chemical analysis workflows. The example provides a concrete use case but lacks broader contextual 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?

With no annotations provided, the description carries full burden and does well: it discloses that the workflow 'can take 1-3 hours depending on simulation length' (performance expectation), mentions credit usage via max_credits parameter, and implies computational resource consumption. However, it doesn't explicitly state whether this is a read-only or destructive operation, or if it requires specific permissions.

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

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

Well-structured with purpose upfront, important warnings highlighted, parameter details organized, and examples provided. Some redundancy exists between the 'Args' section and schema, but overall it's efficiently organized. The runtime warning at the end is appropriately placed.

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 complex workflow tool with 8 parameters, no annotations, and no output schema, the description provides substantial context: purpose, prerequisites, parameter guidance, examples, and runtime expectations. It could be more complete by explicitly stating the operation type (read/write) and any authentication requirements, but it covers most essential aspects well.

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

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

Schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly. The description repeats parameter information in the 'Args' section but adds minimal value beyond what's in the schema. The baseline of 3 is appropriate since the schema does the heavy lifting, though the description does provide helpful context about the protein UUID requirement.

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: 'Submit a pose analysis molecular dynamics workflow using Rowan v2 API' with specific outcomes like assessing binding pose stability, calculating binding free energies, analyzing interactions, and validating docking results. It distinguishes from siblings by focusing on MD simulations for protein-ligand complexes, unlike tools like submit_docking_workflow or submit_admet_workflow.

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

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

Explicit guidance is provided: 'IMPORTANT: The protein parameter must be a UUID... You cannot use PDB IDs directly. Use the create_protein_from_pdb_id tool first to create a protein, then use its UUID here.' This clearly states when to use this tool (after protein creation) and references an alternative (create_protein_from_pdb_id) for prerequisite steps.

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

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

With no annotations provided, the description carries the full burden. It effectively discloses that this is a submission tool (implying asynchronous/mutation behavior), mentions resource usage via 'max_credits', and clarifies that it returns a 'Workflow object' for tracking. However, it lacks details on error handling, rate limits, or authentication needs.

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

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

The description is well-structured with a clear purpose statement, parameter list, returns section, and example. It is appropriately sized for an 11-parameter tool, though the example is lengthy. Every sentence adds value, but some redundancy exists between the parameter list and schema.

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

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

Given the complexity (11 parameters, no annotations, no output schema), the description is adequate but incomplete. It covers submission behavior and parameter usage but lacks details on the returned Workflow object structure, error conditions, or asynchronous nature. The example helps but doesn't fully compensate for missing output schema.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by grouping parameters logically (e.g., listing all args with brief explanations), providing an example that illustrates practical usage, and clarifying dependencies like 'compute_strain' requiring 'do_pose_refinement'. This compensates for the schema's technical 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 specific action ('Submits a protein cofolding workflow') and resource ('to the API'), distinguishing it from siblings like submit_docking_workflow or submit_admet_workflow by focusing on protein-ligand cofolding. The example further clarifies the tool's unique application.

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 protein cofolding with optional ligands, but does not explicitly state when to use this tool versus alternatives like submit_docking_workflow or submit_basic_calculation_workflow. No exclusions or prerequisites are mentioned, leaving the agent to infer context from the tool name and parameters.

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

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

With no annotations provided, the description carries the full burden. It mentions that the tool 'submits' a workflow and returns a 'Workflow object,' indicating it's a write operation that creates something. However, it lacks details on permissions, rate limits, costs (beyond max_credits), or error handling. The example adds practical context but doesn't fully disclose behavioral traits.

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

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

The description is well-structured with a clear opening sentence, an 'Args' section listing parameters, additional explanatory text, a 'Returns' section, and an example. It's appropriately sized but could be more front-loaded; the core purpose is stated early, but some details are spread out. Overall, it's efficient with little waste.

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

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

Given the complexity (6 parameters, no annotations, no output schema), the description is moderately complete. It covers the purpose, parameters, and includes an example, but lacks output details (beyond mentioning a 'Workflow object'), error handling, or integration context with sibling tools. For a submission tool with multiple parameters, more contextual information would be beneficial.

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

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

Schema description coverage is 100%, so the schema already documents all parameters well. The description adds minimal value beyond the schema, such as clarifying that 'folder_uuid' uses a default folder if empty and 'max_credits' of 0 means no limit. This provides slight enhancement, but most semantics are covered in the schema, warranting a baseline-adjusted 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 clearly states the tool's purpose: 'Submit a redox potential calculation workflow using Rowan v2 API' and 'Calculates reduction and/or oxidation potentials for a molecule using quantum chemistry methods.' It specifies the action (submit), resource (redox potential calculation workflow), and distinguishes it from sibling tools like submit_admet_workflow or submit_pka_workflow by focusing on redox potentials.

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

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

The description implies usage through the example and parameter descriptions but doesn't explicitly state when to use this tool versus alternatives. For instance, it doesn't compare with submit_basic_calculation_workflow or other workflow tools, leaving the agent to infer based on the redox focus. Some guidance is present but not comprehensive.

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

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

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it's a submission tool (implies mutation/write operation), mentions 'This workflow can take 40 minutes to complete' (execution time), and describes what the tool does (scans to map potential energy surface). However, it doesn't mention permissions, rate limits, or error handling, which are important for a workflow submission tool.

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

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

The description is well-structured with clear sections (purpose, args, returns, example, note). It's appropriately sized for an 8-parameter tool, but the 'Args:' section is somewhat redundant with the schema. The front-loaded purpose statement is effective, though some sentences could be more concise.

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 complexity (8 parameters, workflow submission), no annotations, and no output schema, the description does a good job: it explains the purpose, lists parameters, provides an example, and notes execution time. However, it could be more complete by explaining the return value in more detail (beyond 'Workflow object') and mentioning error cases or prerequisites.

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

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

Schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly. The description adds minimal value beyond the schema by listing parameters in the 'Args:' section, but it doesn't provide additional context like parameter interactions or advanced usage tips. The baseline of 3 is appropriate since the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: 'Submit a potential energy surface scan workflow using Rowan v2 API' and 'Performs systematic scans along specified molecular coordinates (bonds, angles, or dihedrals) to map the potential energy surface.' It uses specific verbs ('submit', 'scan', 'map') and distinguishes this from sibling tools like 'submit_basic_calculation_workflow' or 'submit_conformer_search_workflow' by focusing on systematic coordinate scanning.

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

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

The description implies usage context through the example ('Water angle scan') and mentions this is for 'systematic scans along specified molecular coordinates,' but it doesn't explicitly state when to use this tool versus alternatives like 'submit_basic_calculation_workflow' or other sibling workflows. It provides some guidance through the example but lacks explicit when/when-not statements or named alternatives.

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

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

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: the workflow 'can take 5 minutes to complete' (indicating potential latency), and it explains default behaviors for empty strings in parameters. However, it does not mention error handling, rate limits, or authentication needs, leaving some gaps.

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

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

The description is well-structured with clear sections (purpose, args, returns, examples, note on timing). It is front-loaded with the core purpose and includes useful examples. Some redundancy exists (e.g., repeating parameter info from schema), but overall it is efficient and informative.

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 complexity (6 parameters, no output schema, no annotations), the description is fairly complete. It covers purpose, parameters, returns, examples, and timing. However, it lacks details on output format (beyond 'Workflow object') and error cases, which could be improved for full contextual understanding.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema, such as clarifying that solvents can be SMILES or names and providing example JSON strings. This meets the baseline for high schema coverage without significant enhancement.

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

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

The description clearly states the specific action ('Submit a solubility prediction workflow') and resource ('using Rowan v2 API'), with a detailed explanation of what it predicts ('solubility (log S) of a molecule in multiple solvents at various temperatures using machine learning models'). It distinguishes from siblings like 'submit_admet_workflow' or 'submit_docking_workflow' by focusing on solubility prediction.

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 solubility prediction workflows but does not explicitly state when to use this tool versus alternatives like 'submit_basic_calculation_workflow' or other workflow tools. It provides context through examples but lacks explicit guidance on when-not-to-use or direct alternatives for solubility tasks.

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

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

With no annotations provided, the description carries full burden. It discloses that this is a submission tool (implies mutation/creation), mentions resource constraints ('Maximum credits to spend'), and provides context about what gets calculated. However, it doesn't mention authentication needs, rate limits, or whether the workflow can be stopped/updated/deleted (though sibling tools suggest these exist).

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

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

The description is appropriately front-loaded with the core purpose, but includes extensive examples and application contexts that, while helpful, make it longer than necessary. The formatting notes and examples section are valuable but could be more concise. Every sentence earns its place, but the structure could be tighter.

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 6 parameters, no annotations, and no output schema, the description does well by explaining the tool's purpose, providing parameter guidance, and giving examples. However, it doesn't fully describe the return value ('Workflow object representing the submitted workflow' is vague) or mention how to track/retrieve results using sibling tools like 'retrieve_workflow'.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds significant value by explaining the 'states' parameter in detail (defining multiplicity, providing spin state examples from singlet to quintet), and includes formatting notes that clarify how to structure the JSON array. This goes well beyond what the schema provides.

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

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

The description clearly states the tool's purpose with specific verb ('submit') and resource ('spin states workflow'), and explains what it calculates ('energies of different spin multiplicities'). It distinguishes itself from sibling tools like 'submit_basic_calculation_workflow' by focusing specifically on spin state calculations.

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

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

The description provides clear context about when to use this tool ('Spin state calculations are essential for understanding...') with specific applications listed. However, it doesn't explicitly state when NOT to use it or name alternatives among the sibling tools for different types of calculations.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully communicates that this is a submission/mutation operation ('Submit a strain energy calculation workflow'), mentions resource consumption ('Maximum credits to spend'), and describes what the tool returns ('Workflow object representing the submitted workflow'). It also provides a practical example showing usage patterns.

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

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

The description is well-structured with clear sections (purpose, Args, use cases, Returns, Examples) and appropriately sized. While somewhat detailed, each section serves a purpose - the use cases section is particularly valuable for guiding appropriate tool selection. The example provides concrete implementation guidance without being overly 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?

For a mutation tool with no annotations and no output schema, the description does a good job of providing context. It explains what the tool does, when to use it, what parameters mean, what it returns, and provides an example. The main gap is the lack of explicit behavioral warnings (like irreversible actions or specific error conditions) that would be helpful for a submission 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?

With 100% schema description coverage, the input schema already documents all parameters thoroughly. The description's 'Args' section essentially repeats what's in the schema without adding significant additional context or semantics beyond what the structured fields already provide. The baseline of 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the specific action ('Submit a strain energy calculation workflow') and resource ('using Rowan v2 API'), distinguishing it from sibling tools like 'submit_basic_calculation_workflow' or 'submit_conformer_search_workflow' by focusing specifically on strain energy calculations. It provides a clear verb+resource combination with explicit differentiation.

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

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

The description provides clear context about when to use this tool ('Useful for analyzing: Ring strain in cyclic systems, Conformational strain in crowded molecules, Steric interactions in cage compounds'), giving concrete examples of appropriate use cases. However, it doesn't explicitly state when NOT to use it or mention specific alternatives among the 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?

With no annotations provided, the description carries the full burden. It discloses that this 'submits' a workflow (implying an asynchronous operation that initiates a calculation), mentions credit spending limits, and describes the purpose ('searches for different tautomeric forms... evaluates their relative stabilities'). However, it doesn't mention authentication requirements, rate limits, whether the workflow can be stopped/canceled, or what happens on failure.

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?

Well-structured with clear sections (purpose, args, explanation, returns, example). The tautomer explanation sentence is useful but could be more integrated. The example is helpful but adds length. Overall efficient with minimal waste.

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

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

For a workflow submission tool with 4 parameters, 100% schema coverage, but no annotations and no output schema, the description does an adequate job. It explains the purpose, parameters, and provides an example, but doesn't cover important behavioral aspects like error handling, asynchronous nature, or how to monitor/retrieve results (though sibling tools like 'retrieve_workflow' 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?

Schema description coverage is 100%, so the baseline is 3. The description adds value by grouping parameters in an 'Args:' section with clear explanations, providing an example showing how to use the tool with minimal parameters, and explaining the significance of 'max_credits: 0 for no limit'. However, it doesn't add substantial semantic context beyond what's already in the 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 specific action ('Submit a tautomer search workflow') and resource ('using Rowan v2 API'), and distinguishes it from siblings by focusing on tautomer search specifically. It explains what tautomers are ('structural isomers that readily interconvert'), which helps differentiate from other molecular analysis tools in the sibling list.

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

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

The description implies usage through the example (2-Pyridone tautomers) and the explanation of what tautomers are, but doesn't explicitly state when to use this tool versus alternatives like 'submit_conformer_search_workflow' or 'submit_basic_calculation_workflow'. No explicit when-not-to-use guidance or prerequisites 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool uploads a protein, implying a write operation, but doesn't mention critical details like authentication requirements, potential side effects (e.g., overwriting existing proteins), rate limits, or error handling. This leaves significant gaps for an agent to understand how to use it safely and effectively.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by structured sections for args and returns. It avoids unnecessary fluff, but the 'Args' and 'Returns' sections could be integrated more seamlessly into the flow rather than as separate bullet points, slightly affecting structure.

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

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

Given that there's an output schema (implied by 'Returns: Dictionary containing protein information'), the description doesn't need to detail return values. However, as a write operation with no annotations, it lacks completeness in behavioral aspects like error cases or side effects, making it minimally adequate but with clear gaps for safe usage.

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

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

The schema description coverage is 100%, meaning the parameters are fully documented in the schema itself. The description adds no additional semantic context beyond what's in the schema (e.g., format constraints for 'file_path' or naming conventions for 'name'), so it meets the baseline for adequate but unenriched parameter information.

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

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

The description clearly states the action ('Upload a protein') and resource ('from a PDB file'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'create_protein_from_pdb_id' or 'sanitize_protein', which prevents a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'create_protein_from_pdb_id' (which creates from an ID rather than a file) or 'sanitize_protein' (which might process an existing protein). There's no mention of prerequisites, such as needing a valid PDB file path, or exclusions.

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

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

With no annotations provided, the description carries the full burden. It discloses the tool uses RDKit and returns a dictionary with validation status and properties, which is helpful. However, it doesn't mention error handling, performance characteristics, rate limits, or authentication requirements, leaving behavioral gaps.

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

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

The description is appropriately sized and front-loaded with the core purpose. However, the structure includes redundant sections like Args (which repeats schema info) and Examples (which is helpful but could be more concise). Most sentences earn their place, but minor trimming is possible.

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 (validation with property extraction), no annotations, and no output schema, the description is partially complete. It covers the basic operation and return structure but lacks details on error cases, performance, or integration with sibling tools, leaving room for improvement.

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

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

Schema description coverage is 100%, so the schema already documents the single parameter. The description adds minimal value beyond the schema by repeating 'SMILES string to validate' in the Args section. No additional syntax, format details, or constraints are provided beyond what's in the schema.

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

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

The description clearly states the tool's purpose with specific verbs ('validate a SMILES string' and 'return basic molecular properties'), identifies the resource (SMILES string), and distinguishes it from sibling tools like molecule_lookup or batch_molecule_lookup by focusing on validation rather than lookup operations.

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

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

The description implies usage context through the examples and mentions RDKit, but doesn't explicitly state when to use this tool versus alternatives like molecule_lookup or when not to use it. No explicit guidance on prerequisites or exclusions is provided.

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

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

With no annotations provided, the description carries the full burden. It clearly discloses that the deletion is 'permanent' and removes data 'from the database', which is crucial behavioral context for a destructive operation. However, it does not mention potential side effects, permissions required, or error conditions.

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

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

The description is appropriately sized and front-loaded with the core action ('Delete a workflow'), followed by parameter and return details. It avoids unnecessary fluff, though the parameter section could be more integrated rather than separate bullet points.

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

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

Given the tool's complexity (destructive operation with 1 parameter), no annotations, and an output schema (implied by 'Returns' statement), the description is fairly complete. It covers the action, permanence, and return type, but could benefit from more behavioral details like confirmation prompts or error handling.

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

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

Schema description coverage is 100%, so the input schema already fully documents the 'workflow_uuid' parameter. The description repeats the parameter info but adds no additional meaning beyond what the schema provides, such as format examples or constraints, meeting the baseline for high schema coverage.

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

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

The description clearly states the specific action ('Delete') and resource ('workflow'), distinguishing it from sibling tools like 'workflow_stop' (which pauses) and 'workflow_update' (which modifies). It precisely defines what the tool does without being vague or tautological.

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

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

The description implies usage when permanent deletion is needed, but does not explicitly state when to use this tool versus alternatives like 'workflow_stop' or 'workflow_delete_data'. It provides some context but lacks explicit guidance on exclusions or 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?

No annotations are provided, so the description carries full burden. It discloses the key behavioral trait that workflow data is deleted while the record is preserved, which is crucial. However, it doesn't mention permissions needed, whether the deletion is reversible, what 'workflow data' specifically includes, or any rate limits/constraints.

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

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

The description is appropriately sized with three sentences: purpose statement, parameter documentation, and return value note. It's front-loaded with the core purpose. The Args and Returns sections are somewhat redundant with the schema but still organized efficiently.

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

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

Given one parameter with full schema coverage and an output schema (implied by 'Returns' statement), the description provides adequate context. It clearly explains the tool's purpose and key behavioral constraint. For a destructive operation, it could benefit from more safety/disclosure information since annotations are absent.

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

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

Schema description coverage is 100%, with the parameter fully documented in the schema. The description's Args section repeats the schema information exactly, adding no additional semantic value beyond what's already in the structured schema. Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: 'Delete workflow data while keeping the workflow record.' This specifies the verb (delete), resource (workflow data), and an important constraint (keeps workflow record). However, it doesn't explicitly differentiate from sibling 'workflow_delete' which presumably deletes the entire workflow including its record.

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

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

The description implies usage context through the phrase 'keeps workflow record,' suggesting this is for partial cleanup rather than full deletion. However, it doesn't explicitly state when to use this versus 'workflow_delete' or other workflow management tools, nor does it mention prerequisites or exclusions.

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

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

No annotations are provided, so the description carries full burden. It states the action ('Stop') but doesn't disclose behavioral traits like whether this is destructive (likely yes, but unconfirmed), permission requirements, side effects (e.g., halts computation, may leave partial results), or error conditions (e.g., invalid UUID, already stopped). The description adds minimal context beyond the basic action.

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

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

The description is appropriately sized and front-loaded, with the core purpose in the first sentence. The Args and Returns sections are structured but somewhat redundant with the schema. Every sentence serves a purpose, though the parameter repetition could be trimmed for efficiency.

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 (a mutation with no annotations) and the presence of an output schema (implied by 'Returns'), the description is minimally adequate. It states the action and parameter but lacks behavioral context, usage guidelines, and error handling. The output schema likely covers return values, so the description doesn't need to explain them, but overall completeness is limited.

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

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

Schema description coverage is 100%, with the parameter 'workflow_uuid' fully documented in the schema. The description repeats the parameter documentation verbatim ('UUID of the running workflow to stop'), adding no additional meaning, syntax, or format details. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't enhance parameter understanding.

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

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

The description clearly states the verb ('Stop') and resource ('a running workflow'), making the purpose immediately understandable. It distinguishes from siblings like 'workflow_delete' (which removes) and 'workflow_update' (which modifies). However, it doesn't explicitly differentiate from all sibling workflow tools beyond the core action.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., workflow must be running), exclusions (e.g., cannot stop completed workflows), or relationships with siblings like 'workflow_delete' or 'workflow_update'. The agent must infer usage from the name alone.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. While 'Update' implies mutation, the description doesn't address permission requirements, whether updates are reversible, what happens on partial updates, or error handling. The return format is mentioned but without details about what 'updated workflow information' contains.

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

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

The description is front-loaded with the core purpose but then duplicates schema documentation unnecessarily. The 'Args:' and 'Returns:' sections repeat what's already in the input and output schemas, making the description longer than needed while adding minimal value.

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

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

For a mutation tool with no annotations but 100% schema coverage and an output schema, the description provides basic functionality but lacks important context. It doesn't explain relationships to sibling tools, doesn't address mutation-specific concerns like permissions or side effects, and doesn't provide guidance on when this operation is appropriate.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description repeats the parameter documentation verbatim from the schema, adding no additional semantic context about parameter interactions, constraints, or usage patterns beyond what's already in the structured fields.

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

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

The description clearly states the verb 'Update' and resource 'workflow details', making the purpose immediately understandable. However, it doesn't distinguish this from sibling tools like 'workflow_delete' or 'retrieve_workflow' - it simply states what it does without comparative context.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'workflow_delete', 'retrieve_workflow', or 'list_workflows'. There's no mention of prerequisites, error conditions, or appropriate contexts for updating versus creating new workflows.

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