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

Beyond the annotations, the description adds meaningful behavioral details: the response carries an id and public_id, secrets are never echoed and only summarized, and webhook_auth_type is provider-specific. This helps the agent understand side effects and security aspects. No contradiction with annotations.

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

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

The description is about 150 words and well-structured, with a clear purpose statement followed by parameter explanations. Every sentence adds value; no fluff or repetition. It's slightly longer than necessary but appropriate given the parameter complexity.

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

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

The description covers the main success behavior (creation, returned id/public_id) and directs to the next step (get_voice_webhook_url). With an output schema present, it doesn't need to enumerate all return fields. It also covers all parameters and provider options, making it sufficiently complete for this mutating tool.

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

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

The schema has 0% description coverage, so the Args section in the description carries the full burden. It adds substantial meaning: lists allowed provider values (retell, twilio, vapi, elevenlabs), explains webhook_auth_type is provider-specific, describes secrets as opaque pass-through, and notes metadata is optional. This fully compensates for the missing schema descriptions.

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

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

The description clearly states the tool's action: "Connect a voice provider so its traffic flows into Okareo monitoring" and "Creates a provider integration." This is a specific verb+resource, and it distinguishes from sibling tools like update_voice_integration or rotate_voice_integration_secret by focusing on initial setup.

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 it (connecting a voice provider) and even mentions the follow-up step of using get_voice_webhook_url with the returned public_id. It doesn't explicitly state exclusions or alternatives, but the focus on creation makes the usage fairly obvious.

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

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

While annotations already indicate idempotency (idempotentHint=true), the description adds crucial behavioral nuances: saving to an existing name creates a new version, output_type for code checks is only validated client-side and not sent to the server, and the server-side vocabulary difference (output_data_type) is explained. It also notes the deprecated placeholder, providing transparency beyond what annotations offer.

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 long but exceptionally well-structured. It leads with the main purpose, then organizes parameter details in an 'Args' block with clear formatting. The extensive placeholder list and code examples are essential for a tool with this complexity, and every section carries meaningful information without 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 complexity (8 parameters, model vs code check variants, audio support, placeholder injection), the description is remarkably complete. It covers prerequisites (get_templates), versioning behavior, parameter interdependencies, code class structure, and server-side nuances. Since an output schema is present, the absence of return-value explanation 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?

Schema description coverage is 0%, but the description fully compensates by explaining each parameter in depth. It details valid values, dependencies (e.g., prompt_template required for model checks), placeholder semantics for prompt_template, and the expected Python structure for code_contents. This far exceeds the schema's bare type definitions.

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

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

The description opens with a specific verb and resource: 'Create or update a quality check by name (upsert).' It clearly distinguishes from siblings like get_check, delete_check, and generate_check by focusing on the creation/update operation. The scope (model, code, audio) is explicit.

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

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

The description provides clear context for when to use this tool and when to consult alternatives. It explicitly directs users to get_templates for worked examples before writing prompt_template or code_contents from scratch, and references get_check's 'available_versions' for versioning behavior. It does not explicitly exclude alternative tools like generate_check, but the contextual guidance is strong.

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?

Beyond the annotations (idempotentHint=true), the description discloses that caller-authored canonical sections are replaced and repeated updates never duplicate blocks. It also reveals language conflict rejection and language derivation behavior with voice, which are non-obvious behavioral traits not inferable from 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 organized with an opening summary, explicit authoring rules, voice configuration guidance, and a per-parameter breakdown. Every sentence adds value, and the structure makes scanning easy despite the length.

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

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

The description is fully complete for a complex tool: it covers all parameters, prerequisites, validation behavior, and automatic append behavior. It even mentions response disclosure (language_derived_from_voice). With an output schema available, no return description is needed.

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

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

The 'Args:' section adds rich semantics for all 8 parameters: uniqueness of name, allowed prompt_template sections, model_id default, temperature default, voice validation against the catalog, and language rules including regional variants and derivation. This goes far beyond the bare schema types and defaults.

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

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

The description opens with a clear summary: 'Define a simulated user persona that will interact with your target. Creates or updates a Driver by name (upsert).' This is a specific verb+resource statement that distinguishes the tool from siblings like get_driver, list_drivers, and list_driver_voices.

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

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

The description gives explicit usage guidance, including a 'Do NOT author Hard Rules...' warning and instructs callers to 'Call list_driver_voices first to discover valid voice and profile values.' This tells when to use a sibling tool first and what not to include, which is explicit when/when-not guidance.

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

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

Beyond the annotations (idempotentHint=true, destructiveHint=false), the description discloses critical behaviors: 'fully replace its configuration — caller must re-specify all desired fields', redaction sentinel rejection, auto-generation of sensitive fields, and the all-or-nothing rule for Twilio auth. These details significantly exceed what the annotations alone convey.

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 long but justified by the tool's complexity (22 parameters, three target types). It uses clear sectioning (type-specific parameter groups) and front-loads the core purpose and replacement warning. A few sentences, like the streaming stop/select details, are dense but necessary. Very little is wasted.

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

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

For a tool with 22 parameters, 0% schema descriptions, and a rich output schema, the description is fully complete. It covers all parameter categories, type-specific configurations, redaction handling, replacement semantics, and auth removal. The presence of an output schema means return-value documentation is unnecessary, and the description fills all other 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?

With 0% schema coverage, the description carries the full burden and excels: every one of the 22 parameters is documented with type-specific context, requiredness, defaults, examples, and nested structures (e.g., next_message_params with dot-path rules and streaming stop/select semantics). This adds enormous meaning beyond the bare schema property names.

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

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

The description opens with a specific verb+resource: 'Create or update a Target — the AI system you want to evaluate in a simulation.' It clearly distinguishes from sibling tools like get_target, list_targets, and delete_target by covering both creation and update in one operation. The title and description align perfectly.

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

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

The description provides clear usage context, including the cloning workflow ('this tool accepts the same key structure that `get_target` returns') and the replacement behavior when reusing a name. It also explains type-specific requirements (generation, custom_endpoint, voice) and how to remove auth. However, it does not explicitly state when to use an alternative tool, instead relying on the context of the cloning workflow.

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

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

Annotations only indicate it is a non-read-only, non-idempotent, non-destructive operation. The description adds useful behavioral details: it automatically determines the next version number (e.g., 'my-test-v2'), treats the original as version 1, and specifies the row structure. However, it does not disclose error behavior (e.g., if base_name does not exist) or side effects beyond creation.

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 efficiently structured: a clear one-line summary, followed by a concise explanation of version numbering and an Args list. The Args section is useful and not overly verbose. It earns its place, though the docstring format is slightly technical.

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

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

The tool is simple with two required parameters and an output schema, so the description covers the essentials: purpose, versioning behavior, and parameter semantics. However, it lacks usage guidelines relative to alternatives and does not address prerequisites or error cases, leaving some contextual 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?

With 0% schema description coverage, the description compensates by explaining both parameters: base_name is the original scenario name, and rows are data rows with 'input' and 'result' fields. This adds meaning beyond the schema's bare titles and types, though it could further clarify required field types or whether rows must contain exactly those keys.

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

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

The description clearly states the tool's function: 'Create a new version of an existing scenario with updated data.' It uses a specific verb+resource combination and distinguishes it from siblings like save_scenario by emphasizing versioning and automatic version-number determination.

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 (creating new versions with auto-incremented numbering) but does not explicitly state when to use it over alternatives like save_scenario, nor does it provide exclusions or conditions. The behavior of generating the next version number is a clear signal, but no direct usage guidance is given.

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

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

The description adds the word 'permanently', which is a behavioral trait not explicitly stated in the annotations. However, it does not disclose any other side effects, failure modes, prerequisites, or what happens to associated data. The destructiveHint annotation already signals destructiveness, so the description's contribution is minimal but present.

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

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

The description is extremely concise, consisting of a single clear sentence and an Args block. Every element is necessary and there is no wasted text. It is well-structured and front-loaded.

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

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

For a simple single-parameter destructive operation with annotations indicating destructiveness and an output schema, the description is adequate. The 'permanently' keyword signals irreversibility, and the parameter is explained. It doesn't detail return values, but the output schema likely covers that. Given the tool's simplicity, the description is nearly complete, though it could mention error conditions (e.g., check not found).

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

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

The schema has no description for the 'name' parameter (0% coverage), so the description provides the meaning by stating 'Name of the check to delete'. This clarifies the parameter's role, but it does not specify whether the name is a unique identifier, case-sensitive, or how it relates to names in other tools. The description compensates for the schema gap but only at a basic level.

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

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

The description uses a specific verb 'delete' with a specific resource 'check' and adds 'permanently' to clarify the action's scope. It clearly distinguishes this from sibling tools like get_check, list_checks, and create_or_update_check.

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 explicit guidance on when to use this tool versus alternatives. It does not mention checking existence first, using preview_delete_scenario for checks, or any when-not-to-use conditions. The usage is only implied by the verb 'delete'.

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

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

The annotation already declares destructiveHint=true. The description adds no extra behavioral context such as permanence, irreversibility, or required permissions. It simply restates the basic operation without enriching the safety profile.

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 very short and front-loaded with the main action. It avoids unnecessary verbiage, though it could have been slightly more informative without becoming 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 single parameter and the destructive annotation, the description is minimally sufficient but lacks context about error handling (e.g., what happens if the dashboard doesn't exist) or any side effects. For a destructive operation, slightly more detail would improve completeness.

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

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

The schema has zero description coverage, and the description only repeats the parameter name ('name: Name of the dashboard to delete'). It adds no additional meaning about format, uniqueness, or edge cases beyond what the schema field name already implies.

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

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

The description clearly states the action ('Delete') and the specific resource ('a dashboard') with a required parameter ('by name'). This distinguishes it from sibling delete tools that target other resources (e.g., delete_scenario, delete_generation_model).

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

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

No guidance is provided about when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or contextual conditions for deletion.

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

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

The description goes beyond the annotation's destructiveHint by detailing specific behavioral traits: it 'cascades to associated test runs and test data points' and is irreversible ('This cannot be undone'). This adds meaningful context about the destructive scope that the annotation alone does not convey.

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

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

The description is concise and front-loaded with the action. It includes two brief sentences and an Args list, all of which add value. It could be slightly tighter by merging the first two sentences, but there is no waste and the structure is clear.

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

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

For a simple delete tool with one required parameter, the description is nearly complete. It covers the action, cascading effects, irreversibility, and the parameter meaning. The presence of an output schema and annotations reduces the need to describe return values or safety flags, making this sufficiently 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?

The schema only provides the parameter name 'Name' with no description. The description's Args section supplies semantic meaning: 'Name of the registered generation model to delete.' This clarifies exactly what value is expected, fully compensating for the 0% schema description coverage.

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

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

The description clearly identifies the tool's purpose: 'Remove a registered generation model and all its related test data.' It uses a specific verb ('remove') and resource ('generation model'), and explicitly mentions the cascading scope. This distinguishes it from sibling tools like update_generation_model or get_generation_model.

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

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

The description implies the use case (deleting a model) and includes a strong caution ('This cannot be undone'), but it does not explicitly state when to use this versus alternatives, nor does it mention any prerequisites like listing models first. There are no exclusions or when-not-to-use guidance, so it is adequate but not highly instructive.

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

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

Annotations already mark destructiveHint=true, and the description enhances this by stating 'permanently delete' and 'all related test data', clarifying the scope and irreversibility. It also adds the safety practice of previewing, going beyond the structured 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 short, front-loaded with the core action, and presents usage guidance and parameter details efficiently 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 destructive tool with an output schema, the description sufficiently covers prerequisites, the destructive scope, and the recommended preview step, making it complete for its complexity.

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

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

The schema provides basic names/types, and the description adds context for scenario_id (from preview_delete_scenario) and reiterates that both are required. With 0% schema coverage, it partially compensates but could offer more detail on how to obtain or validate the name.

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

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

The description uses the specific verb 'delete' with the resource 'scenario' and adds scope ('all related test data'), clearly distinguishing it from sibling tools like preview_delete_scenario and other delete_* tools.

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

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

Explicitly instructs to use preview_delete_scenario first before confirming deletion, providing direct guidance on proper tool sequencing and when to invoke this tool.

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

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

The description adds that deletion is permanent, cascades to associated test runs and data points, and cannot be undone. This exceeds the destructiveHint annotation by detailing the scope and irreversibility, providing valuable 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 three focused sentences plus a minimal Args block. It front-loads the main action, then adds cascade and irreversibility details, with no redundant 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 simple one-parameter delete with an output schema and destructive annotation, the description covers the essential information: what is deleted, cascading behavior, and permanence. It does not mention error behavior for non-existent targets, but the annotation and low complexity make the description adequately complete.

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

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

With 0% schema description coverage, the description's Args section ('name: Name of the target to delete') provides the only explanation of the parameter, clarifying it is the target's name. However, it lacks additional constraints like uniqueness or how to obtain the name, but for a single-parameter delete tool it is sufficient.

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 'Remove a simulation target and all its related test data' with a clear verb and resource, and further clarifies permanent deletion and cascading to test runs/data points. This distinguishes it from other delete_ siblings by specifying the resource type (simulation target) and side effects.

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 what the tool does (cascading deletion of a target) but does not explicitly state when to use it versus alternatives like delete_scenario or preview_delete_scenario. No exclusions or alternative recommendations are given, so usage is implied rather than 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?

The description adds no behavioral detail beyond what the annotations already disclose (destructiveHint=true, readOnlyHint=false). It does not mention permanence, cascading effects, or potential failures, so it contributes no extra transparency.

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

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

The description is very concise and front-loaded with the core action. The Args block duplicates schema information unnecessarily, but the overall structure is efficient and easy to parse.

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

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

Given the simple one-parameter operation, the description is adequate. Annotations and output schema cover the destructiveness and return value, but the description lacks context on side effects or when deletion is appropriate. It fits the tool's low 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 schema description coverage at 0%, the description must compensate. It provides a minimal definition ('The integration's id'), which clarifies the parameter's role but adds little beyond the schema's title. This is minimally sufficient for a single simple parameter.

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'), the resource ('voice provider integration'), and the scope ('by id'). This distinguishes it from sibling tools like update_voice_integration or list_voice_integrations, which perform different operations on the same resource.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives (e.g., update_voice_integration) or any prerequisites/exclusions. It only implies usage for deletion, leaving the decision solely to the agent's intent.

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

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

Annotations show readOnlyHint=false, indicating a mutation. The description adds that AI generates the prompt/code, that the generated output is returned for review, and that scenario flags affect which runs the check works on. This goes beyond the bare annotations meaningfully, though it doesn't mention permissions or failure modes.

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 somewhat lengthy but well-structured: a clear purpose statement, then usage guidance, then a structured argument list. Every section adds necessary value, especially given the low schema coverage. It could be slightly tightened, but the length is justified by the tool's complexity.

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

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

The description thoroughly covers the tool's purpose, when to use it, all parameters, the generated output returned for review, and dependencies on scenario flags. The presence of an output schema further reduces the need to describe return structure. It also points to create_or_update_check for refinement, providing a complete 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 0%, so the description fully compensates. It explains all six parameters, including the allowed values for output_type ('pass_fail', 'score', 'analysis') and check_type ('model', 'code'), and clarifies the behavior of requires_scenario_input/result with example usage.

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

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

The description clearly states the tool generates a check from a natural language description using AI, produces a prompt template or Python code, and saves the check. It explicitly distinguishes from sibling create_or_update_check by contrasting when to use each.

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

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

It provides explicit usage guidance: use this tool when only a description exists, and use create_or_update_check directly when the exact prompt/code is known. It also suggests refining the generated output with create_or_update_check, giving clear when-to and when-not-to context.

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

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

With readOnlyHint and idempotentHint already covering safety, the description adds valuable behavioral context: the response always includes 'available_versions' and that omitting version returns the most recent. It also discloses that the configuration includes prompt template or code contents, going beyond the annotations.

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

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

The description is front-loaded with the main purpose in one sentence, followed by a compact Args block. Every sentence adds necessary context without redundant filler or repetition of schema information.

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

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

For a get-by-name endpoint with two parameters and an output schema, the description covers the optional version behavior and guarantees that all versions are returned in the response. It does not need to describe return fields because an output schema exists, and annotations handle safety semantics.

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

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

Despite 0% schema description coverage, the Args section fully documents both parameters: name identifies the check, and version is optional with pinning behavior and a clear directive to omit for the latest version. This adds meaning well beyond the bare schema types and default.

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

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

The description opens with 'Retrieve the full configuration of a check by name,' which clearly states the verb (retrieve), resource (check configuration), and scope (by name). It further distinguishes from list_checks by specifying 'including its prompt template or code contents,' making the specific use case unambiguous.

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

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

The description implies usage when you need a full check configuration (as opposed to a list), but it does not explicitly name alternatives or state when not to use it. The version guidance is useful but does not address tool selection among siblings like list_checks or get_driver.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the tool's safety profile is known. The description adds value by enumerating the exact return contents (model_input, model_result, metric_value, scenario seed data) and noting it returns a 'complete' transcript. It does not contradict 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 front-loaded: it opens with the main purpose, then gives usage context, then details the return values, and finally lists parameters in an Args block. Despite its length, every sentence serves a purpose and adds necessary detail that the schema omits.

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 simple retrieval nature, good annotations, and existing output schema, the description covers all necessary context: what it does, when to use it, how to select the target conversation, and what it returns. No additional information is needed for a competent agent.

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

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

Schema description coverage is 0%, but the description fully compensates by explaining all three parameters: test_run_id as UUID, scenario_index as a 1-based index visible in get_test_run_results, and test_id as an alternative UUID. This goes beyond the bare schema, which lacks descriptions.

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

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

The description states a specific action ('Retrieve the full conversation transcript') and a specific resource ('a single data point'). It clearly distinguishes itself from sibling tools like get_test_run_results by noting it is for drilling into a specific conversation after summary results.

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

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

The description explicitly says 'Use this after get_test_run_results to drill into a specific conversation,' providing clear context. It also explains how to identify the conversation (scenario_index or test_id) but does not explicitly mention when not to use the tool or name alternative tools for other purposes.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the 'full configuration' detail, indicating the complete payload is returned, but it does not discuss error scenarios, permissions, or other non-safety behaviors. With annotations present, this is adequate but not rich.

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

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

The main description is a single, front-loaded sentence that immediately conveys the purpose. The Args block is redundant with the schema but is brief and does not add significant clutter. Overall, it is concise and well-structured.

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

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

Given the tool's simplicity (one parameter, read-only, idempotent) and the existence of an output schema, the description is largely sufficient. It clearly states what it retrieves and how. A mention of when to prefer this over list_dashboards would improve completeness, but the core information is present.

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

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

The schema provides no parameter description (0% coverage), so the description must compensate. It does so by clarifying that the 'name' parameter is the dashboard's name, but this is only a minimal restatement of the parameter's title. It adds no detail about format, uniqueness, or validation, which is acceptable for a simple getter but does not go beyond the obvious.

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), the resource (a dashboard's full configuration), and the qualifier (by name). This distinguishes it from sibling tools like list_dashboards, which lists dashboards, and save_dashboard/delete_dashboard, which modify them.

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

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

The description gives clear context for when to use the tool: retrieve a specific dashboard's full configuration by name. It does not explicitly mention alternatives or exclusions, but the purpose is specific enough that the usage scenario is unambiguous.

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

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

The description goes well beyond the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint) by disclosing mode-specific behaviors: 'conceptual' default top_k=5, 'user_legible' default top_k=3, maximum top_k=10, and a helpful error message suggesting get_templates as a fallback. These details describe the tool's dynamic behavior and error handling, which are not inferable from annotations alone.

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 front-loaded: first sentence states purpose, followed by usage guidance, mode details, error behavior, and parameter explanations. While longer than average, every sentence adds value—no redundancy. The use of bullet points and an Args section makes it scannable and easy to parse.

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

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

Despite having multiple parameters and no schema descriptions, the description is complete for a read-only documentation query tool. It covers all parameter semantics, mode behavior, defaults, and fallback scenarios. The presence of an output schema means return-value details are not required, so the description is sufficient for an agent to correctly select and invoke the tool.

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

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

The input schema provides only parameter names and types (query, mode, top_k, with top_k nullable and default null). The description compensates fully by explaining each parameter: query with concrete examples ('How do Checks and Evaluations work together?'), mode with its two possible values ('conceptual' or 'user_legible'), and top_k with its mode-specific defaults and maximum value (10). This is essential since the schema has no descriptions (0% 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: 'Query the Okareo documentation system for information about Okareo primitives and workflows.' It uses a specific verb (query) and resource (documentation system), and explicitly lists the concepts covered (Scenarios, Checks, Targets, Drivers, Evaluations, Simulations). This also distinguishes it from sibling tools like get_templates, which is mentioned as a fallback.

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

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

Explicit guidance is provided: 'Use this tool when the agent or user needs to understand how Okareo concepts work.' It also suggests a specific alternative (get_templates) in the event the documentation service is unavailable. The description clearly indicates when to use this tool and provides a fallback option, making it easy to choose among siblings.

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

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

Annotations already declare this as read-only and idempotent. The description adds that the full configuration including persona prompt is returned, which is useful context. No mention of error behavior, but given the simple read-only nature, this is acceptable and adds some value beyond annotations.

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

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

The description is compact and front-loaded with the primary purpose. The additional sentence and Args section add value without redundancy or unnecessary detail.

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

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

For a simple getter with one parameter, an output schema, and read-only annotations, the description covers the core behavior and return content. It doesn't discuss error handling, but the output schema and simplicity mitigate the gap, making the tool adequately complete.

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

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

The schema has a single required string parameter 'name' with no description. The description's Args section restates that name is the driver name, providing minimal additional meaning. It doesn't add details like uniqueness or format, but for a simple identifier it suffices given the low schema coverage.

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

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

The description clearly states the tool retrieves an existing driver persona by name, returning its full configuration including the persona prompt. This distinguishes it from sibling list_drivers, which lists drivers, and create_or_update_driver, which creates/updates.

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 fetching a previously configured driver by name. It doesn't explicitly mention alternatives or when not to use it, but the context is clear enough: use when you need a specific driver's full config. It provides no exclusion rules but the intended use case is evident.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context by listing exactly what is returned (target LLM config, tags, creation time, warnings) and explains what warnings may indicate (deprecation). No contradiction with annotations.

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

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

The description is concise and well-structured: an opening summary, a sentence on return values, and the Args breakdown. Every sentence provides necessary detail with no redundancy or filler.

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

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

For a simple read operation with one parameter and an output schema, the description is complete. It covers the purpose, return content, and parameter semantics. No additional context is needed for correct invocation.

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

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

The schema provides only a parameter name with no description (0% coverage). The description's Args section explicitly states 'name: Name of the registered generation model,' fully compensating for the schema's lack of detail. This adds clear meaning beyond the bare type.

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 action ('Read detailed information about a registered generation model') with a specific verb and resource. It distinguishes from sibling tools like list_generation_models by emphasizing detailed single-item retrieval.

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

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

The description provides clear context for when to use the tool (to read details of an existing generation model), but it does not explicitly mention alternatives or exclusion criteria. It does not say 'use list_generation_models to list all models' which would make it a 5.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds context about release provenance, staleness (`stale: true`), and the served-release-only version constraint, which are not inferable from annotations. It does not contradict 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 comprehensive but efficiently structured: overview, two modes, args, and response metadata. Each sentence adds distinct value, and the formatting makes it easy to parse. There is no redundancy or filler.

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

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

Given the tool's dual-mode complexity, the description fully covers discovery and fetch behavior, parameter semantics, release provenance, and staleness warnings. The presence of an output schema means return-value details are not required in the description, and the description still notes key response fields.

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

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

The input schema has 0% parameter descriptions, so the description fully compensates. It thoroughly explains `pillar` (discovery filter with enumerated values), `path` (fetch mode, use verbatim from discovery), and `version` (served release only, error otherwise), including an example path.

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

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

The description opens with a specific verb+resource: 'Serve REPS agent-evaluation baseline material' and defines REPS, clearly distinguishing it from sibling tools that manage individual scenarios or checks. It precisely states that the tool serves baseline files from tagged releases.

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

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

It explicitly explains two modes (discovery vs fetch), provides a rule to always discover before fetching, and describes when to use the `pillar` filter and `version` parameter. It also notes that any version other than the served tag returns an error naming available versions, giving clear expected behavior.

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

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

The annotations already declare the tool safe (readOnlyHint=true, idempotentHint=true, destructiveHint=false). The description adds useful behavioral details: scenario_id takes precedence over name, and it returns all input/result data rows. It doesn't contradict 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 front-loaded with a one-sentence summary, followed by a structured Args block. There is slight redundancy between the first two sentences, but overall it's concise and well-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 simple read-only tool, the description covers the lookup method, return content, and parameter precedence. The output schema handles return structure. However, it doesn't specify behavior when no arguments are provided or when a scenario is not found, which is a minor gap.

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

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

With 0% schema description coverage, the description's Args section is the only source of parameter meaning. It clearly explains both 'name' and 'scenario_id', including the precedence rule, fully compensating for the empty schema.

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

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

The description uses a specific verb ('Read') and identifies the resource ('a scenario's metadata and all data rows'), which clearly distinguishes it from sibling tools like list_scenarios or get_check. The purpose is unambiguous.

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

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

The description provides clear context: use this tool to read a scenario's metadata and data rows, with lookup by name or ID. It doesn't explicitly name alternatives or state when not to use it, but the read-only nature and specific resource make the use case clear.

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

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

Goes well beyond the readOnly/idempotent annotations by revealing specific behavioral details: sensitive fields appear as '***REDACTED***' and must be replaced before create_or_update_target, the max_parallel_requests field matches the UI label 'max concurrency', and the response shape remains stable for generation/voice targets. These are valuable insights not derivable from annotations alone.

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 statement, followed by detailed but relevant caveats and an Args section. Every sentence adds value and the length is justified by the multi-target-type nuances and redaction behavior.

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

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

Covers all target types, special handling for custom_endpoint, redacted fields, field naming mapping, and stability guarantees. With an output schema present, the description does not need to list return fields. It is highly complete for a read-only getter tool.

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

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

The input schema has no property description (0% coverage), so the description compensates by stating 'name: Name of the target to retrieve.' This adds straightforward meaning to the single required parameter. Though minimal, it is sufficient for a simple string parameter.

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

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

The description clearly states the tool's function with a specific verb+resource: 'Check the current configuration of a test target' and 'Retrieves a Target by name.' It distinguishes itself from sibling tools like list_targets by indicating single-target retrieval by name and explicitly mentions support for all target types.

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

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

The description implies when to use the tool (when needing a single target's configuration) and provides context for different target types, but it does not explicitly contrast with list_targets or state exclusions. The intended use is clear enough from the phrasing and sibling tool names.

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

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

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds valuable behavioral context: templates are served as static content with no network calls, always available even in air-gapped environments. It also explains the differing behavior when the parameter is omitted vs provided, which is not captured by annotations.

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

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

The description is well-structured with an introductory sentence, a note on static availability, a bulleted list of templates, and an Args block. Despite being long, it is concise because every line adds necessary information. It is front-loaded with the primary purpose and does not contain fluff.

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

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

The tool has a single optional parameter and an output schema. The description explains what the output will be in both modes (listing or full content) and lists all valid template names. Given the output schema exists, no further return-value detail is needed. The description is complete for the tool's simplicity.

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

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

The input schema provides zero description coverage for template_name (just a title and type). The tool description compensates fully by documenting the parameter, listing all valid values, and explaining the behavior when omitted. This is exemplary parameter documentation.

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

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

The description clearly states the tool's function: 'Retrieve prompt templates for common Okareo patterns.' It uses a specific verb (retrieve) and resource (prompt templates), and the list of available templates further distinguishes this tool from any sibling tool. No ambiguity about what the 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 usage guidance: omit template_name to get a listing, or provide it to get full template content. It also explains the static, offline nature of the content. However, it does not explicitly compare to alternative tools or state when not to use it, though no sibling tool serves the same 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?

Annotations already provide readOnly, idempotent, and non-destructive hints. The description adds valuable behavioral context beyond annotations: transcripts are excluded by default for conciseness, test_run_id takes precedence over name, and name returns the most recent match. It does not contradict 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 with a summary paragraph and an Args list. It is somewhat lengthy but every sentence adds useful detail. The front-loaded purpose and logical flow make it easy to scan. Slight redundancy exists between the prose and Args list, but it aids 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?

The tool has an output schema, so return values are covered. The description explains lookup methods, alternative tool for transcripts, pagination, and default behavior. It is complete for a read-only query tool with 5 parameters; no crucial information is missing.

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

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

The schema has 0% description coverage, so the description carries full burden. The Args section provides detailed semantics for all 5 parameters: precedence of test_run_id, behavior of name, effect of include_transcripts, and pagination semantics of limit/offset. This far exceeds 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 loads results of a specific test run, with specific lookup methods (by UUID or name) and what it returns (aggregate metrics and per-row check scores). It distinguishes itself from sibling tools like get_conversation_transcript and list_test_runs.

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

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

The description explicitly tells when to use this tool vs alternatives: 'Use get_conversation_transcript to inspect a single conversation's transcript without loading all of them.' It also explains when to use include_transcripts and pagination, giving clear 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds that the result includes 'status,' which is useful, but doesn't cover other behavioral aspects like pagination, error handling, or auth requirements. Given the strong annotation coverage, the additional context is sufficient but not rich.

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

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

The description is brief and front-loaded with the core purpose in the first sentence. The Args section is minimal and directly tied to the schema parameter. Every sentence earns its place without redundancy or fluff. This is an example of efficient, well-structured documentation.

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

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

For a simple get-by-id tool with one parameter, strong annotations (read-only, idempotent), and an output schema, the description covers the necessary context: what to pass and that it returns status. The only missing element is explicit behavior for non-existent ids (e.g., not-found error), but given the tool's simplicity and existing structured metadata, this is adequate.

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

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

The schema provides only the parameter name and type (integration_id: string) with no description. The tool description compensates by explaining the parameter's origin and meaning: 'The integration's id (from list_voice_integrations).' This adds valuable semantic context beyond the schema, telling the agent where to obtain the id and implying it should reference a valid existing integration.

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 action: 'Retrieve a voice provider integration by id, including its status.' It uses a specific verb (retrieve), identifies the resource (voice provider integration), and differentiates from siblings like list_voice_integrations by specifying lookup by id. This leaves no ambiguity about what the 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 the tool: 'by id' and the parameter hint 'from list_voice_integrations' implies a prerequisite workflow—first list integrations to obtain the id, then retrieve details. It doesn't explicitly name alternatives or exclusions, but the usage context is clear enough for the intended 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint:false. The description adds useful context beyond these annotations, such as the purpose of the URL (reaching Okareo monitoring) and the conditional necessity of public_id for certain providers. It doesn't describe return format or error behavior, but annotations cover safety/read-only 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 concise and well-structured: a clear purpose sentence, a usage directive, and a neatly formatted Args list. Every sentence adds value without unnecessary verbosity.

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

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

Given the tool's low complexity, an output schema is present, and annotations are rich, the description adequately covers purpose, usage, and parameter semantics. It leaves no critical gaps for an agent to invoke the tool correctly.

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

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

The input schema has no descriptions (0% coverage), but the description's Args section comprehensively explains each parameter: provider lists valid enum values, and public_id is defined with its source and when it is required. This fully compensates for the schema's lack of detail.

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

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

The description uses a specific verb ('Get') and resource ('inbound webhook endpoint for a voice provider'), clearly distinguishing it from sibling integration tools like connect_voice_integration or get_voice_integration. It also states the intended use of the returned URL, further clarifying its purpose.

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

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

The description clearly explains when to use the tool (to obtain a webhook URL for a voice provider) and what to do with the result (paste it into the provider's console). It notes provider-specific requirements for public_id, which is important context. However, it does not explicitly mention when not to use this tool or name alternative 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?

Even with annotations present (readOnlyHint=false, openWorldHint=true), the description adds substantial behavioral context: turns become evaluable data points, monitors run automatically, validation is per-conversation (not all-or-nothing), rejected list is returned, and transcript precedence when both transcript and audio are provided. This goes beyond what annotations reveal.

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

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

The description is structured effectively: a clear opening sentence, a usage paragraph, a validation behavior sentence, and a well-organized Args list. Every sentence carries essential information for correct invocation, and the length is justified by the complexity of the conversation object structure. No fluff or redundancy.

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

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

Given the tool's complexity (nested conversation objects, multiple optional fields, integration with monitors, validation semantics) and the presence of an output schema, the description covers all necessary aspects: purpose, use cases, parameter details, validation behavior, and tag/mut_id matching. It leaves no significant ambiguity for an agent to invoke the tool correctly.

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

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

Schema description coverage is 0%, but the description fully compensates with a detailed Args section. It explains the conversations array's required fields (call_id, at least one of transcript/audio/recording_url/recording_bytes_b64), optional fields, and the exact semantics of project_id and mut_id, including the default and tagging behavior. This is exemplary compensation for missing 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 opens with a specific verb+resource+purpose: 'Submit completed voice conversations to Okareo for monitoring.' It clearly distinguishes this from sibling tools like run_simulation and run_test by focusing on production voice traffic ingestion. The scope is unambiguous.

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

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

The description provides explicit context: 'Use this to feed production voice traffic (Retell, Twilio, VAPI, ElevenLabs, or a custom source) into Okareo monitoring.' It also clarifies behavior like per-conversation validation and mut_id omission for pure monitoring. However, it does not explicitly name alternatives or when-not-to-use conditions, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful context by stating the data source (Okareo registry) and the shape of entries (name, display name, provider). This goes beyond the basic safety profile and explains how the output should be consumed.

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

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

The description is three sentences, front-loaded with the core purpose, and every sentence earns its place. It avoids fluff and directly states what, why, and how to use the result. Excellent conciseness.

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

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

For a zero-parameter listing tool with strong annotations and an output schema, the description is complete. It covers the registry source, the purpose (registration), and the result fields. No additional behavioral or usage context is needed.

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

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

The tool has zero parameters, so the input schema is trivial. Per rubric, a baseline of 4 is appropriate. The description adds no parameter details (none exist), but it does explain the output usage, which is the only semantically relevant information needed.

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

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

The description clearly states the tool's function: 'Browse available LLMs from the Okareo registry' and 'Returns all LLMs that can be used when registering a generation model.' It distinguishes this from sibling tools like list_generation_models by explicitly tying it to the registry and the register_generation_model 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?

Provides explicit guidance: 'Use a model_name from this list when calling register_generation_model.' This tells the agent exactly when to use this tool. It doesn't discuss when not to use it or contrast with alternatives, but the usage context is clear.

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

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

Beyond the read-only and idempotent annotations, the description reveals key behavioral details: grouping by `__category:<Category>` tags, handling of uncategorized checks, duplicate entries for multi-category checks, the meaning of output_data_type values ('bool', 'int') and their mapping to output_type, and version behavior controlled by all_versions. This adds significant value beyond the structured 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 long but well-structured with clear paragraphs and an Args section. The first sentence captures the core purpose. Each subsequent sentence adds necessary context about grouping, output semantics, and parameters. It is appropriately verbose for the tool's complexity.

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

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

With an output schema present, the description doesn't need to detail return fields, but it still explains the `checks_by_category` organization, uncategorized fallback, and output_data_type semantics. It also covers edge cases like multi-category checks and version history. The tool is fully specified for an agent.

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

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

The input schema has no property descriptions, so the description carries the full burden. The Args section thoroughly explains `limit` (default, semantics of 0, application before grouping) and `all_versions` (latest vs full history, version annotation). This exceeds 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 opens with 'List available quality checks, grouped by category', clearly identifying the action (list) and resource (quality checks). It distinguishes itself from sibling tools focused on creating, updating, or deleting checks.

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 guidance on how to choose checks: 'Select checks from the category matching your task AND modality' and explains that voice-specific categories apply to voice simulations. It also directs the user to use check names with run_test, establishing the tool's role in the evaluation workflow. While it doesn't explicitly contrast with sibling tools, the context is sufficient.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds useful behavioral context about the limit parameter, specifically that 0 means no limit, which is not in the schema and informs the agent of a special behavior.

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

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

The description is two sentences and front-loaded with the action. The Args block is compact and directly relevant. No wasted words.

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

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

For a simple list tool with one parameter, the description covers purpose and parameter behavior. The output schema covers return structure, so no need to describe it. It could mention pagination or ordering, but that isn't required for straightforward listing.

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 only provides the parameter type and default (20), while the description explains that limit is the maximum number of dashboards to return and that 0 disables the limit. This adds meaningful semantics 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 verb 'List' and the resource 'analytics dashboards in your Okareo project.' It distinguishes from siblings like get_dashboard (which fetches a single dashboard) and other list_* tools.

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

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

The usage is implied by the name and description: use to list dashboards. However, there is no explicit guidance on when to prefer this over get_dashboard or other list tools, nor any mention of 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?

Annotations already indicate a safe read-only, idempotent operation. The description adds value by disclosing exactly what is returned (names, IDs, model, temperature) and that it returns all drivers, which goes beyond the minimal annotation information.

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

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

The description is two short sentences, front-loaded with 'See what driver personas are available' and immediately followed by the return fields. No wasted words.

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

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

For a simple list tool with no parameters, an output schema, and a clear description of the returned data, this is fully complete. The output schema handles detailed return shape, and the description provides the semantic content.

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

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

The tool has zero parameters, so there is nothing to explain. The description correctly avoids any parameter details, and the baseline for zero-parameter tools is 4.

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

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

The description clearly states the tool lists all driver personas with specific fields (names, IDs, model, temperature). This distinguishes it from related tools like get_driver (single driver) and list_driver_voices (voices only).

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

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

The context is clear: use this when you need an overview of all available drivers. It does not explicitly mention alternatives or exclusions, but the simplicity and scope ('all Drivers') make the use case obvious without extra guidance.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, so the description need not repeat these. It adds valuable context about the data semantics (e.g., `language` derivation and conflict rule, `accent` matching requirement) and clarifies the limitation of `voice_instructions`, going beyond the structured 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 longer than typical, but it earns its length with structured bullet points and front-loaded purpose/usage statements. Every sentence adds meaningful guidance, and the format aids readability despite the density.

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

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

Given the tool has no parameters and an output schema exists, the description is fully complete for an agent to invoke it correctly. It covers the key concepts (voices, profiles, languages), selection criteria, and integration with create_or_update_driver, leaving no critical gaps.

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

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

The tool has zero parameters, so the baseline is 4. The description compensates by thoroughly explaining the output fields (language, accent, gender) and their intended use, which is more relevant than parameter docs for this read-only list operation.

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

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

The description opens with a specific verb+resource+scope: 'Discover the voices, voice profiles, and languages available for configuring voice-capable drivers.' It clearly distinguishes the tool from sibling list tools by focusing on voice configuration and explicitly references create_or_update_driver, making its purpose unambiguous.

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

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

Provides explicit when-to-use guidance: 'Call this before create_or_update_driver when building a voice agent simulation, so you can pass valid `voice`, `voice_profile`, and `language` values.' It also offers selection guidelines and a direct exclusion ('writing accent instructions into `voice_instructions` does NOT change the TTS voice'), effectively preventing misuse.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, establishing a safe read operation. The description adds scope ('registered', 'project') and return fields, providing modest extra context beyond annotations.

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

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

The description is three short sentences, front-loaded with the action and resource. Every sentence contributes value: the action, the returned data, and the intended use case.

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

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

With no parameters and an output schema present, the description sufficiently covers the purpose and return content. The mention of 'registered models in the project' clarifies scope, and the use case adds practical 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?

The tool has zero parameters, and schema coverage is trivially 100%. The description does not need to explain parameters; the baseline for 0 params is 4, and no additional param information is required.

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

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

The description clearly states the tool lists all registered generation models, specifying returned fields (names, IDs, target LLM configurations, creation timestamps). This distinguishes it from siblings like get_generation_model (single model) and list_available_llms (available LLMs).

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

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

The description provides a clear use case: 'Use this to see what generation models are available for testing.' It does not explicitly mention alternatives or when not to use this tool, but the context is sufficient.

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

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

Annotations already declare this as read-only, idempotent, and non-destructive. The description adds meaningful behavioral context beyond annotations, such as 'most recent first' ordering and the semantics of the limit parameter (default 20, 0 returns all). No contradictions exist.

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

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

The description is concise and well-structured: main behavior and ordering in the first sentence, returned fields in the second, usage guidance in the third, and a clean Args section. Every sentence adds value, and the format is easy to parse.

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

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

The description fully covers the single optional parameter and the tool's purpose. With an output schema present, it doesn't need to detail return structure. It could mention the project context more explicitly, but the description is sufficiently complete for a list tool.

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

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

The schema only provides type and default for the limit parameter, but the description fully explains its meaning: 'Maximum number of scenarios to return (default 20). Set to 0 to return all scenarios.' This goes well beyond the schema's minimal 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 lists scenarios in the project, most recent first, and enumerates the returned fields (names, IDs, tags, row counts, creation dates). This specific verb+resource combination distinguishes it from siblings like get_scenario or save_scenario.

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

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

It provides a clear context: 'Use this to discover existing scenarios before running a test.' While it doesn't explicitly mention alternatives or when-not-to-use, the guidance is sufficient for a list operation, and no other sibling offers the same discovery functionality.

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

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

The description adds behavioral details beyond annotations, including sorting order ('sorted by most recent first'), default limit of 10, the cap at 5 for detailed mode, and the distinction between summary and detailed outputs. These are not conveyed by the readOnly/idempotent annotations, making the description valuable.

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 summary, a usage workflow paragraph, and a labeled Args section. It is relatively detailed but each sentence serves a purpose, and the use of a code block for parameters improves readability.

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 presence of an output schema (which covers return structure), the description covers the tool's purpose, all parameters, behavioral constraints, and its place in the workflow with sibling tools. It is complete enough for an agent to select and invoke the tool correctly without additional information.

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

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

The input schema has no parameter descriptions (0% coverage), but the description thoroughly explains each parameter: target_name and scenario_name as optional filters, limit with its default and 0-to-return-all behavior, and detail_level with its two allowed values and the 5-cap implication. This fully compensates for the schema's lack of documentation.

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

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

The description clearly states the tool's function with a specific verb and resource ('List past simulation runs in the project'), and details what is returned (names, IDs, timestamps, status, sorted most recent first). It differentiates from sibling tools like get_test_run_results and get_conversation_transcript by outlining the intended workflow.

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

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

It provides explicit guidance on when to use this tool versus downstream tools, instructing to use get_test_run_results with the returned test_run_id and get_conversation_transcript with scenario_index. It also explains when to switch detail_level based on whether model_metrics are needed. This contextualizes usage within the broader API workflow.

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

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

Annotations already cover read-only and non-destructive nature. Description adds that it returns only voice and custom_endpoint types created via create_or_update_target, and excludes generation models—useful scope context that complements the annotations.

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

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

Description is short, front-loaded with the main purpose, and every sentence provides value 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 simple list operation with an output schema, the description covers the essential scope, exclusions, and fallback for related entities. No gaps identified.

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

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

No parameters, so schema is empty. Description adds meaning by clarifying the implicit selection criteria (types and origin), exceeding the baseline for zero-parameter tools.

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

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

Clearly states the tool lists all simulation targets, distinguishing from generation models by naming the alternative list_generation_models. The verb 'browse' is less specific than 'list' but resource and scope are explicit.

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

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

Explicitly instructs to use list_generation_models for generation models, providing a clear when-not-to-use and an alternative. Also scopes to the current project.

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

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

Annotations already declare readOnly/idempotent/destructive hints, and the description adds meaningful context: the is_current marker and the OAuth-only constraint, going beyond annotations.

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

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

Three sentences, each providing distinct value: scope, active marker, and authentication requirement. No fluff, well 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?

Given the output schema exists and the tool has no parameters, the description fully covers behavior, including edge cases like non-OAuth sessions.

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

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

The tool has zero parameters, so the description need not explain semantics. The description implicitly confirms no inputs are needed.

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

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

The description states a specific verb ('List') and resource ('every Okareo organization you have access to'), and distinguishes itself from siblings like switch_tenant by focusing on listing rather than switching.

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

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

Explicitly states when the tool is available (OAuth-authenticated sessions) and what happens on Bearer-API-key sessions, giving clear usage context and an alternative behavior.

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

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

Annotations already declare readOnly, idempotent, non-destructive; description adds default limit=10, limit=0 returns all, and that results are sorted by most recent. Also clarifies that simulation_only filters to MULTI_TURN type.

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

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

The description is organized with a clear opening sentence, followed by return values, defaults, filters, and a pointer to an alternative tool. The Args section is structured and each line adds value. No wordiness.

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

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

With a rich output schema present, the description need not detail return types, but it already summarizes return fields. It covers filters, defaults, and the recommended next step for transcripts. Sufficient for an agent to use correctly.

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

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

Schema has zero field descriptions, but the description documents every parameter (model_name, scenario_name, limit, simulation_only) with defaults and purpose, fully compensating. The simulation_only explanation gives extra context on what MULTI_TURN simulation runs are.

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

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

States it lists past test runs, specifies returned fields (names, IDs, timestamps, status, summary scores) and sort order. Clearly differentiates from get_test_run_results by directing users there for transcripts.

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

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

Explicitly directs users to get_test_run_results for simulation run details, implying this tool is for summary listing. Explains filtering options with examples of when simulation_only is useful.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. Description adds the limit semantics (default 20, 0 for no limit), which is useful but does not disclose other behaviors like pagination or ordering.

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

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

Description is short, front-loaded with a clear sentence, and an organized Args section. No redundant 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 single-parameter, read-only list tool with an output schema, the description covers the core purpose and parameter semantics. The scoped context and limit behavior are sufficient.

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 explicitly explains the limit parameter, including the default value and the special meaning of 0 (no limit), which goes beyond the schema's default. This compensates for the low schema coverage, even though there is only one parameter.

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

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

Description clearly states the action (list), resource (voice provider integrations), and scope (in Okareo project), distinguishing it from sibling tools such as get_voice_integration and connect_voice_integration.

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 explicit guidance on when to use versus alternatives, such as get_voice_integration for a single integration. Usage is implied by the list operation, but no exclusions or use-case contexts 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond the annotations: it discloses that the tool shows scenario details and the count of related test runs, and that scenario_id takes precedence over name. This goes beyond what annotations provide, though it could mention edge cases like missing both parameters.

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

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

The description is concise and well-structured, with the main purpose stated in the first sentence and an explicitly labeled Args block. Every sentence contributes meaningful information without fluff or redundancy. The front-loaded design aids quick comprehension.

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

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

Given the tool's simplicity, the presence of an output schema (which covers return values), and the strong annotations, the description is complete for an agent to select and invoke the tool correctly. It covers the tool's purpose, the follow-up action, and the parameter nuances, making it fully adequate for the task.

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

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

The schema provides no descriptions for the two optional parameters (0% coverage), so the description carries this burden. It explains the meaning of 'name' and 'scenario_id' and the precedence relationship, which is essential for correct usage. However, it does not explicitly state that at least one parameter should be provided, leaving a minor ambiguity.

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: 'Preview what will be deleted before removing a scenario.' It specifies the action (preview) and the resource (scenario deletion), and it distinguishes itself from the sibling tool delete_scenario by explicitly naming the confirmation workflow. It also details what will be shown: scenario details and the count of related test runs.

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

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

The description provides explicit usage guidance: 'Use delete_scenario to confirm deletion after reviewing.' This tells the agent when to use this tool versus the alternative, making the workflow clear. The contextual hint that this is a pre-deletion review step is sufficient 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?

Annotations already mark it as read-only and idempotent. The description adds useful behavioral context: the API requires a time window and defaults to LAST_30_DAYS, and include_metadata returns available cubes/dimensions/measures. This goes beyond the annotations without contradicting them.

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

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

The description is lengthy but every sentence adds value, especially given the 7 parameters. The structured Args list improves scannability. Slight verbosity in the intro sentence could be trimmed, but it's well-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 tool with 7 parameters and an output schema, the description covers all necessary context: defaults, constraints, allowed values, and metadata option. The output schema exists, so return-value details are not required. No gaps identified.

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

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

Schema description coverage is 0%, but the Args section fully documents each parameter: valid measure names, dimension examples, cube options, filter object format, time_range enum, time_dimensions structure with granularity, and include_metadata behavior. This is exceptional compensation for 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 opens with a specific verb and resource: 'Query Okareo's product analytics to understand evaluation trends.' It clearly differentiates from sibling tools like get_check or list_test_runs by focusing on aggregation and trend analysis. The example question reinforces the purpose.

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

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

It gives a concrete use case ('how is my evaluation quality trending') and notes the time-window requirement. It doesn't explicitly name alternative tools, but the context makes when to use this tool clear. Sibling names are mostly CRUD operations, so the differentiation is implicit.

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

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

Discloses that it does not re-execute the original simulation and does not change original run results, adding valuable context beyond the annotations. It does not mention idempotency or other side effects, but the output schema covers return behavior, and the annotation openWorldHint already signals possible side effects.

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

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

The description is concise, front-loaded with the main purpose, and includes a structured Args list. Every sentence adds value, making it easy to scan and understand quickly.

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

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

With an output schema present, the description does not need to explain return values. Prerequisites, use cases, and parameter semantics are all clearly covered, so the tool can be invoked correctly without further information.

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

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

Schema has zero parameter descriptions, yet the description fully explains both parameters: test_run_id is a UUID/name of a completed run, and checks is an optional list with clear behavior when omitted. This completely compensates for the schema gap.

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

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

Description clearly states it re-scores a completed test run without re-executing the model/simulation, distinguishing it from run_test and get_test_run_results. The verb 're-score' plus the qualifier 'without re-executing' provides precise scope and uniqueness.

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

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

Explicitly notes it is useful after a check definition changed or to score against additional checks, giving clear when-to-use context. However, it does not explicitly name alternative tools or state when not to use this tool, so it stops short of full guidance.

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

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

Annotations indicate idempotentHint=true, which is helpful, and the description adds that this 'creates a generation model (Model Under Test)' pointing to a specific LLM. It clarifies the registration semantics (registering creates an instance) and the relationship to testing, which goes beyond the annotations. It doesn't mention persistence or side effects, but the idempotentHint covers re-registration safety.

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

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

The description is concise and well-structured. It front-loads the core purpose, provides usage guidance, and ends with parameter explanations. Every sentence earns its place, and the formatting with Args clearly separates parameter descriptions.

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

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

Given the tool's moderate complexity, the description fully covers what an agent needs: the purpose, the required parameters, how to discover valid model_name values, and how the result is used. The presence of an output schema means the description doesn't need to explain return values. The sibling context (list_available_llms, run_test) is addressed.

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

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

Schema coverage is 0%, so the description carries the full burden. It explains 'name' as 'a human-readable name' and 'model_name' as 'the LLM from the registry (from list_available_llms)', which adds meaning beyond the raw schema types. It could provide more detail on name uniqueness, but the description effectively maps parameters to their semantics.

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

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

The description clearly states the tool's purpose: 'Register a generation model for testing by selecting an LLM from the registry.' It uses specific verbs ('register', 'creates') and identifies the resource ('generation model') and distinguishes it from sibling tools like list_generation_models or update_generation_model. The example LLM ('azure/gpt-4o-mini') further clarifies the intended use.

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

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

The description explicitly tells users to use 'list_available_llms' to see available LLMs and mentions that the registered model can be used with 'run_test'. This provides clear when-to-use context and names alternatives/prerequisites, which is excellent guidance for an AI agent.

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

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

Annotations already disclose readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the description doesn't need to repeat those. However, it adds no additional behavioral context, such as whether the order is fully replaced or how unlisted dashboards are handled. The description provides no new behavioral insight beyond the annotations.

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

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

The description is concise: a single sentence stating the purpose followed by a brief parameter definition. It is front-loaded and avoids unnecessary wording. The only minor issue is the embedded 'Args:' block format, but it remains efficient and easy to parse.

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

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

For a simple reorder operation with one parameter and an output schema, the description provides the core information needed. However, it omits edge-case behavior, such as whether all dashboards must be included or how partial lists are handled. The tool is straightforward, but the description could be more complete with a note on ordering semantics.

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

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

With schema description coverage at 0%, the description compensates by explicitly defining the parameter: 'ordered_names: Dashboard names in the desired order.' This adds meaningful context beyond the schema's bare 'array of strings' type. It clearly explains what the parameter represents and how to use it.

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

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

The description clearly states the tool's action: 'Set the display order of dashboards.' This uses a specific verb and resource, distinguishing it from sibling tools like list_dashboards, save_dashboard, or delete_dashboard. The purpose is immediately clear and unambiguous.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives. It only states the action without explaining prerequisites (e.g., dashboards must exist) or how it relates to other dashboard operations. The usage context is heavily implied rather than stated.

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

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

Annotations already indicate destructive and non-read-only behavior. The description adds valuable context by stating 'The response returns only a secret summary, never raw secret values,' which goes beyond the annotations and informs the agent about the response behavior.

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

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

The description is concise: one main sentence plus an inline parameter list. Every word earns its place, and the main action is front-loaded.

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

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

Given the tool has only two parameters, a nested object, and an output schema, the description covers the essential intent and the notable response behavior. It could mention prerequisites or side effects of rotation, but the existing annotations and the explicit note on response summaries make it fairly 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?

With 0% schema description coverage, the description provides basic meaning for both parameters: integration_id is 'the integration's id' and secrets are 'the new provider secret values.' This is helpful but lacks detail on format, required structure, or constraints for the nested secrets object.

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: 'Rotate a voice provider integration's secrets.' The verb 'rotate' is specific and distinct from sibling tools like connect, update, get, or delete, making the tool's purpose unambiguous.

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

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

The description implies usage for rotating secrets but gives no explicit guidance on when to use this tool versus alternatives like update_voice_integration. There is no mention of exclusions or when-not-to-use conditions, though the specific action is self-evident.

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

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

Annotations indicate readOnlyHint=false and openWorldHint=true, and the description adds substantial behavioral context: asynchronous execution ('Returns promptly so the call never times out... run continues to completion on its own'), status values ('finished' vs 'running'), and the failure mode for custom_endpoint targets ('exception raised during the run FAILS the run'). It also discloses default check substitution and field-level validation before backend calls, with no contradiction to 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 front-loads a clear one-sentence summary and is well-structured with sections and an Args list, making it easy to scan. However, it is quite long, and the voice augmentation section provides field-level detail that overlaps with the instruction to call get_templates for the full reference, introducing some redundancy that could be trimmed.

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 (14 parameters, async behavior, voice augmentation constraints), the description is remarkably complete. It covers all parameters, return statuses, the polling workflow, failure modes, and check handling. The presence of an output schema means return values need not be repeated, and the description provides all necessary context for successful 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 0%, so the description carries the full burden, and it does thoroughly. The Args section explains every parameter beyond schema types, e.g., 'repeats: Number of times to run each scenario row', 'silence_timeout_ms: Do NOT set... should be 10000 ms', and the augmentation block is fully detailed with required/optional fields and numeric ranges. This far exceeds minimal compensation for the schema gap.

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

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

The description opens with 'Run a multi-turn conversation evaluation of your AI agent,' a specific verb+resource+modality that clearly states the tool's purpose. It distinguishes from siblings by emphasizing multi-turn conversation evaluation and pointing to follow-up tools like get_test_run_results and get_conversation_transcript, setting it apart from run_test and other simulation-related tools.

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

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

The description provides explicit when-to-use and when-not-to-use guidance: silence_timeout_ms should not be changed unless requested, augmentation is rejected for non-voice targets, and checks are sourced from list_checks. It also directs users to get_templates for examples and get_test_run_results for polling, clearly naming alternatives and context for use.

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