APIFleet

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

Beyond the already-strong annotations, the description discloses important behavioral boundaries: no save, no credential verification, no full API validation, and no call-quality certification. It also specifies the public/no-key nature and the redaction requirement, which are critical operational details.

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, and every phrase carries useful information. The key constraint and scope are stated immediately with no filler.

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

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

The description covers scope, privacy, and non-goals well, and annotations cover the safety profile. But with no output schema and an undocumented nested config parameter, an agent still lacks guidance on the config object's expected shape and the result format.

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 for a required nested `config` object, so the description must compensate. It adds only that the config should be redacted and contain no secrets or customer data; it does not explain what fields the configuration object expects or what the seven checks inspect.

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 operation: static configuration checks on an assistant config, and clarifies the tool is public and keyless. It distinguishes itself from mutation siblings by noting no save occurs, but it does not name a direct alternative among the many assistant/config-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?

It gives a clear input constraint (send a redacted configuration with no secrets or customer data) and lists what the check does not cover. However, it does not explicitly state when to use this tool instead of siblings like update_assistant, get_assistant, or check_entitlements.

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 confirm readOnly/idempotent/non-destructive, so the description wisely spends its words elsewhere: no API key required, the values are caller-supplied blended rates rather than platform quotes, and no call is placed. It omits any note on output shape or precision, but the added context is genuinely useful.

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 short sentences, no filler, with the pricing scope front-loaded and the disclaimers trailing. Every clause earns its place.

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

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

For a simple three-parameter, read-only calculator with annotation coverage, the description is nearly sufficient; the caller understands inputs, currency, and that results are estimates. It could note the output components explicitly since there is no output schema, but this 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?

Schema description coverage is 0%, so the description must carry the load. It clarifies that provider and carrier rates are caller-supplied and denominated in USD, which adds real meaning, but it says nothing about the required `seconds` parameter or per-minute rate basis beyond what property names already suggest.

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

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

States a specific verb and resource: calculate USD platform fees plus caller-supplied provider/carrier rates. The closing 'Does not place a call' separates it from the call-creation siblings without needing to name 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?

'Public, no key' and 'an estimate, not a provider quote' imply a pre-commitment costing use case, but the description never routes to alternatives such as get_provider_matrix or get_billing_policy for authoritative rates. Usage is inferable 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 declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new context: no authentication key is required and no outbound provider call is triggered, which tells the agent this is a static metadata read.

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

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

Two short sentences with zero waste. The public/zero-cost precondition is front-loaded before the content enumeration and the negative guarantee.

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, no output schema, and simple read-only annotations, the definition is nearly complete: it lists what categories of information come back. It stops short of describing the response shape, but that is a minor gap for a static discovery endpoint.

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

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

The tool takes zero parameters, so there is nothing to document and the baseline applies. The description correctly implies a parameterless call but adds no parameter-level meaning because none exists.

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

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

States a specific verb (discover) and enumerates the resource contents: voice and carrier integrations, setup boundaries, platform pricing, and documentation. It is clearly distinct from siblings like list_provider_credentials or list_tts_voices, though it never names those alternatives explicitly.

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

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

'Public, no key' establishes a precondition, and 'No provider request or call is made' rules out one misreading, but there is no explicit when-to-use guidance versus sibling discovery tools such as list_provider_credentials or get_billing_policy. Usage context is implied (pre-setup discovery) 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 disclose that this is a non-read-only, non-destructive, non-idempotent mutation. The description adds important behavioral context beyond annotations by warning that incoming call routing changes and that carrier webhook configuration is a separate step.

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

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

Two tightly written sentences with the core action front-loaded and a useful behavioral caveat immediately after. No wasted language.

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

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

Given the rich schema and existing annotations, the description covers the key operational context: what is bound, what changes, and the separate webhook prerequisite. It does not describe the response or permission requirements, but it is largely sufficient for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents the number format, provider enum, region, and assistant_id constraints. The description reinforces that the number is a carrier number and the target is a workspace assistant, but adds no format or usage semantics beyond the structured fields.

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

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

States a specific verb and resource: 'Bind an existing carrier number to a workspace assistant.' This clearly distinguishes the operation from sibling tools such as unbind_number and list_numbers.

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

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

Provides clear context that the number must already exist and that this changes incoming call routing, plus the prerequisite to configure the carrier webhook separately. It does not explicitly name alternatives or exclusions such as when to use unbind_number, 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description's 'does not start a checkout' reinforces that no charge or funding action is triggered, which is mildly useful reassurance, but it adds nothing about permissions, freshness of balance data, or return shape.

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

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

Two short sentences, no filler, with the operation stated first and the negative side-effect disclaimer after. Every sentence earns its place.

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

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

For a no-parameter, annotation-covered read tool this is close to sufficient. The remaining gap is the undefined term 'funding path' — with no output schema, an agent cannot infer what that field or the response actually contains.

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

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

The tool takes zero parameters and the schema is fully closed (additionalProperties: false), so there is nothing parameter-related for the description to explain. Baseline 4 applies for a nullary tool.

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

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

States a specific verb (Read) and resource (workspace prepaid balance) plus a secondary concept (funding path). It is clear what the tool does, but it never distinguishes itself from the closely named siblings get_wallet, list_balance_activity, and get_billing_policy, leaving the agent to guess which 'balance' tool to pick.

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?

'Does not start a checkout or call' provides a when-not boundary, but there is no positive guidance on when to choose this over get_wallet or get_billing_policy, and no alternative is named. Usage is implied rather than directed.

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 beyond the annotations (readOnly=false, destructive=false, idempotent=false) by disclosing that the secret is returned exactly once and must be stored privately — critical one-shot behavior the agent could not infer. It omits whether specific permissions are required to mint a key.

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 short sentences, front-loaded with the action and followed by the crucial one-time-secret caveat. Nothing 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 single-param creation tool whose annotations cover the safety profile, the description covers the key risk (secret shown once, store privately). It does not address required permissions or how the returned secret is formatted, but the essentials are present.

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

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

Schema coverage is 100% and the nested 'name' property is documented as a human-readable label, so the schema carries the load. The description adds no additional meaning about the single parameter, so baseline 3 applies.

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

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

States a specific verb (Create) and resource (full workspace key), scoping the key type. It does not explicitly contrast with list_api_keys or revoke_api_key, but the create action 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?

No guidance on when to use this versus alternatives such as other key types or scope options, and no preconditions noted. The agent must infer usage entirely.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description adds genuinely non-redundant context: that persisting configuration does not trigger a call (the main behavioral ambiguity for a telephony assistant) and that the response carries revision, configuration, and attached resource identifiers. It omits auth requirements and failure 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?

Three short sentences, front-loaded with the action and immediately followed by the most decision-relevant caveat. The only inefficiency is that 'Saving configuration does not place a call' is duplicated verbatim inside the schema's data description.

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

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

With no output schema, the description does helpfully sketch the return payload, and it covers the key side-effect question. However, for a nested-object create tool it leaves gaps around required-for-functioning fields, pipeline_mode defaults, and error conditions, so it is adequate but not complete.

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

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

Schema description coverage is 100%, with every nested field of the single 'data' parameter documented, so the schema carries the parameter burden. The description adds nothing about individual fields such as pipeline_mode's realtime/cascading tradeoff or which fields are needed for a usable assistant, so the baseline 3 applies.

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

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

The description opens with a specific verb and resource ('Create a assistant'), which cleanly distinguishes it from get_assistant, update_assistant, and delete_assistant in the sibling list. It stops short of naming any sibling or scope condition, so the differentiation comes from the name alone.

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

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

There is no guidance on when to create versus update, no mention of prerequisites (e.g., that model/voice need to be chosen from a supported set), and no note on what to do if an assistant with the same name exists. 'Saving configuration does not place a call' clarifies side effects rather than usage 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 flag this as a non-read-only, open-world, non-idempotent operation; the description adds genuinely non-structured traits: the token is short-lived, WebSocket use can incur cost, and the token must never be published. It does not quantify cost or explain revocation/expiry behavior beyond 'short-lived'.

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 short sentences, each carrying a distinct payload: what it does, the cost risk, and the security constraint. Front-loaded and waste-free.

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

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

With no output schema, the description still conveys that a URL/token is returned and that it is sensitive, and it covers the cost side effect. It leaves the exact response shape and the meaning of the required 'id' resource implicit, which is a minor gap for a two-parameter creation tool.

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

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

Schema description coverage is 100%, with ttl_seconds and max_duration_seconds fully documented (including clamping ranges) in the schema. The description adds nothing about parameters, which is acceptable given the schema carries the load, but earns only the baseline.

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

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

The description opens with a specific verb and resource: 'Issue a short-lived browser voice-test URL.' An agent knows exactly what is produced and for what surface (browser voice test). It does not explicitly contrast with siblings such as create_api_key, but no sibling occupies the same niche.

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?

Clear context for when to use it (browser voice-test session) plus an operational warning that opening the WebSocket can incur usage. There are no explicit exclusions or named alternatives, so it stops short of a full when/when-not statement.

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=false, destructive=false, idempotent=false, so the safety profile is covered. The description adds the 200 KiB total knowledge quota, which is a real behavioral constraint, but that same sentence is copied verbatim from the schema's data description, and it omits what happens on a duplicate name or what the call returns.

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 short sentences, front-loaded with the purpose, with no tangential content. It loses a point because sentences two and three merely restate the nested schema description rather than adding new 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 low-complexity single-parameter create tool with full schema coverage and annotations, the description covers purpose, the quota constraint, and the separation from assistant attachment. Only the return value and duplicate-name behavior are left implicit.

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

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

Schema coverage is 100% and the single nested object documents name/source/content with limits, so the schema carries the parameter burden. The description adds no syntax, formatting, or precedence detail beyond it, so baseline 3 applies.

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

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

The description names a specific verb and resource ("Create a knowledge document"), so the operation is unambiguous against delete/get/list/update siblings. It does not explicitly contrast with update_knowledge_document, but the create semantics are clear from the verb.

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?

"Attach documents separately to use them in an assistant" implies the follow-up workflow step, which is useful guidance. However, it never names the tool that performs the attachment (e.g. set_assistant_knowledge), and gives no conditions for choosing create over update_knowledge_document when a document may already exist.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, and the description reinforces those with concrete operational detail: no automatic retry, no universal idempotency guarantee, and that billing/carrier checks apply. That retry semantics and cost side-effects are spelled out adds genuine value beyond the hints, though the failure/response behavior is not described.

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?

Four short sentences, front-loaded with the action, then the approval gate, then side effects. 'Billing/provider/carrier checks are the same as REST' is a slightly opaque cross-reference to a REST API an agent may not have, but it costs only one sentence.

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 paid, destructive, non-idempotent mutation with a nested parameter object and no output schema, the description covers the safety-critical facts: user approval required, real billing applies, no automatic retry. Only the return value and error/failure behavior are unstated, which is a minor gap given the schema is fully documented.

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

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

Schema coverage is 100% — both `data` sub-fields and `confirm` are documented in the schema, including the E.164 pattern and the 'timeout is not safe to retry blindly' note. The description adds little beyond restating the approval intent, so the baseline 3 applies.

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

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

States a specific verb and resource ('Place a real telephone call'), and the word 'real' implicitly distinguishes it from the simulation siblings (create_simulation, start_simulation_run) that also produce calls. An agent can tell what this does without opening the schema.

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

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

It gives a clear precondition ('Ask the user to approve recipient, caller number and expected usage first'), which is real usage guidance. But it never names alternatives such as apifleet_estimate_call_cost for pre-flight cost checks or create_simulation for non-billed testing, so routing between siblings is left to inference.

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=false, destructiveHint=false, idempotentHint=false and openWorldHint=false, covering the safety profile, but the description adds nothing beyond them — no note on what the created object looks like, whether IDs are required to pre-exist, or whether repeats create duplicates. With annotations covering part of the burden, this is still a bare minimum.

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?

It is short and front-loaded, but that brevity is under-specification rather than economy: the single sentence conveys no information the tool name did not already convey. Nothing is wasted because nothing is there.

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?

A create tool with a nested required object, no output schema, and a link to external docs ('Additional settings are documented in https://apifleet.dev/docs') that the description does not summarize. An agent gets no picture of the required inputs' relationships or the result of the call.

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

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

Schema description coverage is 100% and the nested fields (name, persona_id, scenario_id, assistant_id) are documented inline, so the schema carries the load and baseline 3 applies. The description adds zero interpretation on top — it does not explain that persona_id/scenario_id/assistant_id are references to previously created resources or that additionalProperties:true permits undocumented settings.

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?

"Create a simulation." is a verbatim restatement of the tool name create_simulation, adding no scope, resource detail, or distinction. It does not clarify what a simulation is, contrary to sibling create_simulation_persona / create_simulation_scenario which create the components it depends on.

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 when-to-use guidance, no prerequisites (e.g. that persona_id/scenario_id/assistant_id must come from prior create/list calls), and no routing advice versus start_simulation_run, create_simulation_persona, or start_simulation_batch. The agent must infer everything from sibling names.

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

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

The annotations already declare a non-read-only, non-idempotent, non-destructive, closed-world write, so the safety profile is covered. The description adds nothing beyond that: it does not say whether the persona is reusable across simulations, whether duplicate names are allowed, or what minimum fields are needed.

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

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

One short sentence with no filler, but its brevity comes from omission rather than economy. It is front-loaded but conveys no information an agent could not infer from the name.

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

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

For a mutation tool creating a nested resource, the description never explains what a simulation persona is used for (a simulated caller in simulations) or how it relates to create_simulation_scenario and start_simulation_run. With no output schema, the agent also gets no hint of what the create returns.

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

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

Schema description coverage is 100% and the single nested 'data' object documents name and system_prompt, so the schema carries the parameter burden. The description adds no supplementary meaning (e.g., typical system_prompt content or constraints), which fits the baseline 3.

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

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

The description restates the tool name almost verbatim: 'Create a simulation persona' for create_simulation_persona. It names a verb and resource, but adds nothing that distinguishes this tool from siblings like create_simulation, create_simulation_scenario, or create_assistant.

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

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

There is no guidance on when to use this tool versus the closely-named siblings (create_simulation, create_simulation_scenario), nor any mention of prerequisites such as needing an existing simulation to attach the persona to.

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=false, idempotentHint=false, destructiveHint=false, and openWorldHint=false, so the write/non-destructive profile is covered structurally. The description adds nothing on top of that — no statement about what gets created, whether names must be unique, or what happens on duplicate 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?

It is a single short sentence with no wasted words, but that brevity reflects under-specification rather than efficiency for a tool taking a nested open-ended `data` object. There is no front-loaded information about the resource or its role in the simulation hierarchy.

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 a nested object parameter with an open-ended `evaluations` array pointing at external documentation, and no output schema, the description should explain what a scenario is and how it relates to simulations and personas. It leaves those gaps entirely unaddressed.

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

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

Schema description coverage is 100%, and the nested `data` object documents name, instructions, and evaluations inline (plus a docs URL for extra fields), so the schema carries the load. The description adds no meaning beyond it, which lands at the baseline 3 for high-coverage schemas.

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

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

The description 'Create a simulation scenario.' merely restates the tool name and title, adding no verb nuance, scope, or resource detail beyond what the identifier already conveys. It does not distinguish this tool from siblings like create_simulation, create_simulation_persona, or update_simulation_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?

There is no guidance on when to use this versus create_simulation or create_simulation_persona, no prerequisites, and no mention of what a scenario belongs to. An agent must infer the relationship between simulations, scenarios, and personas entirely from sibling names.

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

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

Annotations only state non-read-only, non-destructive, non-idempotent, and closed-world. The description adds two facts annotations cannot: the signing secret is returned exactly once (an irreversible, capture-it-now consequence) and creation does not invoke the URL. That is meaningful behavioral context beyond structured fields, though it omits auth requirements and error conditions.

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

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

Three short sentences, front-loaded with the action and the one-time secret warning. No filler; the only redundancy is the opening 'Create a tool.' restating the name.

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

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

For a mutation tool with no output schema, the one-time signing secret disclosure is the key missing-elsewhere detail and it is present. However, it does not say what else is returned (ID), whether the secret is required later, or what failures look like, leaving gaps against a nested-object create operation.

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

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

Schema description coverage is 100% with nested field descriptions for url, name, and description, so the schema does the parameter work. The tool description adds no field-level semantics (e.g., timeout_ms bounds or method behavior), leaving this at the baseline 3.

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

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

The verb+resource is stated, but 'Create a tool' mostly restates the tool name, and a 'tool' is never positively defined (an HTTP callback registered for assistant use?). The claim that attached tools call the URL during conversations hints at the resource, yet an agent can't easily tell this apart from sibling create_webhook from the text alone.

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

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

No guidance on when to use this versus update_tool, list_tools, or create_webhook. The 'configuring a tool does not invoke its URL' sentence describes runtime behavior, not tool selection, so there is effectively no when-to-use/when-not guidance.

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

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

Annotations already mark this as a non-readonly, non-destructive, non-idempotent write, and the description adds genuinely non-obvious behavior: the signing secret is returned exactly once and cannot be re-fetched, signatures must be verified against the raw body, and deliveries may be retried. That is real value beyond the structured fields. It stops short of stating auth/permission requirements or the response shape.

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 short sentences, front-loaded with the verb and resource, each carrying distinct information (what it does, one-time secret handling, retry behavior). No filler, though the retry remark sits slightly out of priority order behind the more critical secret warning.

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

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

For a one-parameter create tool with full schema coverage and no output schema, the description covers the key gotchas an agent must relay (secret shown once, raw-body verification, retries). It does not cover whether `events` must be non-empty or whether `enabled` defaults to true, minor gaps given the schema documents them.

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

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

Schema description coverage is 100% and the single nested `data` object documents `url` and `events` inline, so the description adds nothing about parameters. The secret/raw-body sentence describes delivery behavior rather than the accepted inputs, so baseline 3 applies.

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

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

States a specific verb and resource ('Create a webhook') in the first two words, which is unambiguous against siblings like create_api_key or create_tool. It does not explicitly differentiate from update_webhook or delete_webhook, but the verb carries that distinction on its own.

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

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

There is no statement of when to use this versus update_webhook or list_webhooks, no prerequisites (e.g. that the receiver URL must be public HTTPS and reachable), and no exclusions. The note about the signing secret is operational advice, not usage guidance.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the irreversibility warning largely restates structured data. The description adds no new behavioral context such as permission requirements or what happens to dependent resources (e.g., attached tools/knowledge) when the assistant is removed.

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

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

Two short sentences with the core action front-loaded and the caution second; little waste. The irreversibility clause is slightly redundant with annotations but justified as a safety reminder.

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

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

For a two-parameter destructive delete with full schema coverage and annotations carrying the safety profile, the description covers what an agent needs to call it correctly. The only minor gap is side effects on dependent resources, which is not stated.

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

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

Schema coverage is 100%, so both `id` and `if_revision` are fully documented in the schema itself, establishing baseline 3. The description's 'review the identifier' adds only emphasis, no new parameter 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 states a specific verb and resource ('Delete this assistant'), making the operation immediately identifiable. It does not explicitly differentiate itself from siblings such as update_assistant or delete_tool, but the resource naming is clear enough.

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

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

Usage is implied by the verb rather than stated: there is no explicit guidance on when to delete versus archive/update, nor any prerequisites. The caution to 'review the identifier before deleting' is a safety note, not selection guidance against 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 declare destructiveHint=true and readOnlyHint=false, so the safety profile is known; the description's 'the change cannot be undone' reinforces rather than reveals. It omits what actually happens on deletion (cascading detachment from assistants, whether the ID becomes reusable) and does not mention that repeated calls are harmless, which annotations already cover via idempotentHint.

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

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

Two short sentences, front-loaded with the action, with no filler. Slightly under-specified rather than verbose, so it lands at a 4 rather than 5.

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

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

For a one-parameter destructive delete whose safety traits are already in the annotations, the description plus structured data is largely sufficient. The main omission is the post-deletion effect on assistants that reference the document, which a careful agent would want before calling.

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 a single parameter at 100% schema description coverage, the schema already explains that 'id' is a resource identifier from a prior request. The description adds only the advice to double-check that identifier, no format or sourcing detail 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?

States a specific verb and resource ('Delete this knowledge document'), making the operation unambiguous. No effort is made to distinguish it from the many sibling delete_* tools (delete_tool, delete_webhook, delete_simulation), so it stops short of a 5.

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

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

There is no guidance on when this is the right call versus alternatives such as update_knowledge_document or leaving the document unbound, and no mention of prerequisites (existence, permissions). The only procedural note — 'Review the identifier before deleting' — is a caution, not a when-to-use signal.

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 supply destructiveHint=true, idempotentHint=true and readOnlyHint=false, and the description adds genuinely new context: the deletion is permanent but the call log survives, scoping exactly what is destroyed. It stops short of covering auth requirements or recovery options, so not a 5.

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 short sentences with no filler, and the permanence warning is front-loaded ahead of the softer context. Every sentence carries information the agent needs.

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 destructive tool with no output schema and full annotation coverage, the description covers what is deleted, what persists, and the precondition check. It omits error behavior for an invalid or already-deleted id, which keeps it just under complete.

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

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

Schema description coverage is 100% for the single `id` parameter, so the baseline is 3. The description only reinforces that the identifier should be verified, without disambiguating whether `id` is a recording id versus a call id — a real ambiguity given siblings like list_calls and get_waveform.

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

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

States a specific verb and resource ("Permanently remove a call recording") and clarifies the blast radius by noting the call log remains — that distinction matters against the many other delete_* siblings. It doesn't name an alternative tool, but no sibling overlaps this resource, so a 4 is warranted.

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?

"Confirm the identifier before deleting" is a caution rather than a when-to-use rule, and no alternative or when-not condition is given. Usage is implied by the tool name (use this to remove a recording you no longer want), which lands it at minimum-viable rather than explicit 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 destructiveHint=true and idempotentHint=true, so the irreversibility claim ('the change cannot be undone') mostly restates structured data. It does add a caller-side safety step (verify the identifier first), but says nothing about cascade effects on runs/personas or what a successful response contains.

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

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

Two short sentences, front-loaded with the action and followed by the one safety-relevant warning. No filler, nothing that could be cut without losing 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 single-parameter destructive delete with annotations covering the safety profile, this is minimally adequate. It omits the practically important question of whether deleting a simulation also removes its runs, personas or scenarios, which an agent must know before invoking an irreversible operation.

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

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

Schema coverage is 100% and the id property already documents its format, pattern and provenance, so the schema carries the semantics. The description only reinforces 'review the identifier' without adding format or origin detail beyond the schema baseline.

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

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

States a specific verb (delete) and resource (simulation), which separates it from the many delete_* siblings such as delete_simulation_run and delete_simulation_persona. The demonstrative 'this simulation' is slightly off-key for a tool taking an arbitrary id, but the intent 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?

No guidance on when to delete versus when to update or archive, no prerequisites or permission notes, and no mention of the sibling delete_simulation_scenario/delete_simulation_persona that an agent might confuse it with. The only instruction is a generic caution to verify the id.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is known. The description reinforces permanence ('the change cannot be undone') and adds a pre-flight verification cue, but says nothing about cascade effects on scenarios/runs or behavior when the id does not 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?

Two short sentences, action first, caution second; nothing is wasted and the destructive nature 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?

For a single-parameter delete with full annotations and a fully described schema, the description covers the essential facts an agent needs. Only side effects (what else is removed or invalidated) are left unstated.

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

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

Schema coverage is 100% and the single id parameter is fully documented with pattern and length constraints. The description only echoes this with 'review the identifier before deleting', adding no format or sourcing detail 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?

States a specific verb (Delete) and resource (simulation persona), so an agent can immediately tell it apart from get_/update_/list_simulation_persona. There is no explicit naming of siblings, but the verb-plus-resource phrasing 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?

Usage is implied by the destructive verb, and the description adds a caution to verify the identifier first. It never states when to prefer this over delete_simulation (parent resource) or how to locate a valid id, so routing guidance is only implied.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: eligibility is limited to completed runs, and in-flight runs may be rejected. It still doesn't say whether the underlying result artifacts are destroyed or retained.

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

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

Two short sentences with zero filler; the action is front-loaded and the eligibility caveat follows immediately. Nothing could be removed without losing 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 one-parameter destructive delete with no output schema and full annotation coverage, the description supplies the essential eligibility constraint. The remaining gap is whether deleting a run cascades to related transcripts or artifacts, which an agent might reasonably want to know.

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

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

The single `id` parameter is fully documented in the schema (100% coverage) including pattern, length bounds, and provenance ("returned by a previous request"). The description adds nothing about the identifier, so the baseline 3 is appropriate — the schema does all the work.

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 gives a specific verb and resource ("Delete a completed simulation result"), which cleanly separates it from delete_simulation (the config) and from list/get/start_simulation_run siblings. It stops short of naming any sibling explicitly, so the agent must infer the run-vs-simulation distinction from the noun alone.

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

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

"Running runs may reject deletion" provides one useful precondition, effectively bounding when the call will succeed. However, it offers no routing guidance — it never says to use delete_simulation for the parent definition or which tool to use to stop an in-flight run before deleting it.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is largely covered. The description reinforces this with "the change cannot be undone," which is useful emphasis but adds little beyond the destructive hint, and it says nothing about cascade effects on linked runs or dependent resources.

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

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

Two short sentences with the action front-loaded and the irreversibility warning immediately after. Every clause earns its place; nothing is padded.

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 destructive tool with full schema coverage and annotations carrying the safety profile, this is close to sufficient. The only gap is that it doesn't clarify whether deletion cascades to dependent simulation runs or whether the resource can be recreated.

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

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

Schema coverage is 100% with a single, fully documented required parameter, so the schema does the heavy lifting. The description contributes a light but relevant directive ("review the identifier before deleting") that stresses the identifier must be correct before a destructive call.

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

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

States a specific verb and resource ("Delete this simulation scenario"), which cleanly separates it from get_simulation_scenario and update_simulation_scenario in the sibling list. It does not explicitly name those siblings, but the CRUD verb makes the distinction obvious.

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 (you delete when you want the scenario gone) and adds a caution to review the identifier first, but it offers no explicit when-to-use framing and no alternatives such as archiving or updating instead. Usage is inferable 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 declare destructiveHint=true and the irreversibility is implied there, so "the change cannot be undone" largely restates structured data rather than adding context. The description says nothing beyond that — e.g. what happens if the tool is still attached to assistants, or whether deleting an unknown id errors or no-ops (relevant given idempotentHint=true).

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

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

Two short sentences, zero waste, and the action is front-loaded ahead of the caution. Nothing extraneous is included.

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 destructive tool with full annotation coverage and a fully described schema, the essentials are present. However, a destructive delete should describe side effects (tools bound to assistants), unknown-id behavior, and any permission requirements — none of which appear here.

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

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

Schema description coverage is 100% — the id parameter already documents its format, pattern, and length — so the schema carries the load and baseline 3 applies. The description's "review the identifier" adds a disposition toward the parameter but no semantics (e.g. whether a name or id is accepted) beyond what the schema states.

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?

Specific verb+resource: "Delete this tool" makes the operation and target clear, and the required id makes the resource unambiguous in practice. The phrase "this tool" is mildly awkward (could momentarily read as the MCP tool itself rather than a tool resource), and there is no explicit differentiation from the many sibling delete_* tools, so it stops short of a 5.

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

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

The description gives no when-to-use condition, no prerequisites, and no pointer to alternatives such as get_tool (to verify) or update_tool. "Review the identifier before deleting" is a caution, not usage routing — nothing tells the agent when deletion is the right action versus editing.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the irreversibility is already known. The description reinforces this with 'the change cannot be undone' and adds a caution to review the identifier, but adds limited new behavioral 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?

Two sentences, front-loaded with the action, no wasted words. The caution and irreversibility note are appropriately placed.

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

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

For a simple single-parameter delete tool with rich annotations, the description covers purpose, irreversible nature, and a usage caution. Nothing critical for correct invocation is missing.

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

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

Schema description coverage is 100% and the single 'id' parameter is fully documented in the schema. The description mentions 'identifier' but adds no format or usage details beyond what the schema provides.

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

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

States a specific verb (Delete) and resource (this webhook), which directly differentiates it from siblings like create_webhook, update_webhook, and list_webhooks. The id parameter reinforces the target 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?

Provides a caution to review the identifier before deleting, but does not explicitly state when to use this tool versus alternatives (e.g., update_webhook or list_webhooks). Usage is implied by the destructive nature of the operation.

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

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

Annotations already declare this as read-only, idempotent, non-destructive, and closed-world, so the safety profile is fully covered. The description adds useful scoping context by saying the assistant must belong to this workspace, implying cross-workspace IDs are not valid, but says nothing about not-found behavior or response shape.

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 definition is a single front-loaded sentence with zero filler. For a simple single-resource read tool, this is appropriately sized and every word carries meaning.

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

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

The tool is simple, has rich annotations and full schema coverage, so the description is close to sufficient. It nonetheless omits sibling routing versus list_assistants and any hint about missing-resource behavior, leaving clear but minor gaps.

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

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

Schema description coverage is 100%, so the single id parameter is already fully documented by the schema. The description adds only workspace scoping and no extra detail about the identifier format or source, matching the baseline for schema-complete parameters.

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

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

The description states a specific verb (Get), resource (assistant), cardinality (one), and workspace scope, so the core operation is clear. It does not distinguish itself from the sibling list_assistants or explain when single retrieval is preferable, which keeps it below a 5.

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

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

"Get one assistant" implies the single-item lookup use case versus the list tool, but there is no explicit when-to-use guidance, no alternatives named, and no prerequisite that the id must come from a previous request. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds only the compatibility-scoping idea; it does not say what happens if the assistant has no voice settings, whether results are paginated, or how many voices typically return. Modest value added beyond structured fields.

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

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

One short sentence, front-loaded with the verb and with no filler. It is efficient, though so terse that it borders on under-specification rather than optimal 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?

There is no output schema, so the description is the only place an agent could learn what a returned voice record looks like, and it says nothing about that. For a one-parameter read tool with strong annotations, this is adequate but leaves a meaningful gap around return shape and the relationship to the sibling voice-listing tools.

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

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

Schema description coverage is 100% and the single 'id' parameter is documented generically as 'Resource identifier returned by a previous request.' The description's reference to 'this assistant configuration' is the only signal that this id is an assistant id, which is a useful but thin addition. Baseline 3 applies when the schema carries the 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 gives a specific verb ('Read') and a specific resource ('voices compatible with this assistant configuration'), which is enough to distinguish this from the broad catalog tools like list_tts_voices or list_voice_presets. It stops short of naming those siblings, and there is a small naming mismatch between the tool name ('presets') and the description ('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 phrase 'compatible with this assistant configuration' implies the use case (find voices usable for a given assistant), but it never states when to prefer this over list_voice_presets or list_tts_voices, nor any preconditions such as the assistant needing an existing voice configuration. Usage is inferable rather than specified.

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 safety (readOnly, idempotent, non-destructive, closed-world), and the description adds a genuinely useful caveat beyond them: internal exempt workspaces may differ from the public tariff, so returned values may not match published pricing. It stops short of saying whether the read is authenticated per-workspace or what happens for workspaces with no exemption.

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

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

Two short sentences, front-loaded with the action, and no filler. The second sentence earns its place by flagging the exemption discrepancy.

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?

A no-param, no-output-schema read tool still leaves the agent guessing what the returned 'policy' contains (rates, exemptions, currency, thresholds) and how to interpret it. The safety profile is well covered by annotations, but the content of the return value is not hinted at anywhere.

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?

Zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly signals the tool takes no scoping input, implying the workspace is resolved from the session context.

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?

Verb is clear ('Read') but the resource is stated as 'the actual workspace policy', which never says billing or pricing directly — the agent must infer it from the tool name and the word 'tariff'. The clarifying clause about internal exempt workspaces is helpful context, but the core purpose statement is vaguer than it should be.

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

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

Usage is only implied: fetch this when you need the workspace-specific policy rather than published tariffs. There is no explicit instruction on when to prefer this over nearby tools like get_wallet, check_entitlements, or list_tts_rates, and no prerequisites or exclusions are stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The only added behavioral context is the workspace scoping constraint ("belonging to this workspace"), which is useful but thin; nothing is said about what a miss returns.

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

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

One sentence, front-loaded with the verb and resource, with zero filler. Nothing in it could be trimmed without losing information.

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

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

The tool is simple and the schema and annotations are complete, but there is no output schema and the description says nothing about what a fetch returns (document body vs. metadata) or what happens when the id is unknown. For a retrieval tool that gap is the main remaining shortfall.

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

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

Schema coverage is 100% for the single `id` parameter, including pattern, length bounds and a description of its provenance, so the schema carries the burden. The description contributes only the workspace-scoping qualifier, which is a marginal addition 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?

States a specific verb and resource ("Get one knowledge document") and the singular "one" implicitly separates it from list_knowledge_documents and the create/update/delete siblings. It does not name those siblings explicitly, so differentiation relies on inference from the wording.

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

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

Usage is only implied: an agent infers this is the tool for fetching a single document when it already has an id. There is no statement of when to prefer this over list_knowledge_documents, nor any note on error behavior for missing or out-of-workspace ids.

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, so the safety bar is low, and the description still adds real behavioral context: the snapshot is volatile (resets with the application process) and incomplete as a record of account finances. It stops short of describing the shape or granularity of the returned metrics.

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

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

Two sentences, no filler, with the volatility warning front-loaded right after the purpose statement. Every clause carries a distinct piece of 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?

With no output schema and no parameters, the description bears full responsibility for telling an agent what actually comes back, and "metrics snapshot" does not reveal the fields, scope, or aggregation. The two caveats are useful, but the agent still cannot predict the payload before calling.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. No parameter claims are made or contradicted.

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?

"Read the authenticated workspace metrics snapshot" gives a verb and resource, but "metrics" is left undefined — it could be usage counts, latency, or spend. No sibling is named, so an agent cannot tell from the description how get_metrics differs from get_wallet, get_entitlements, or list_balance_activity.

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

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

There is no statement of when to call this versus alternatives; the closest signal is the implicit "not a complete billing ledger," which hints at billing siblings without naming any of them. The agent must infer routing from the sibling list alone.

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

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

Annotations already communicate that this is a safe, idempotent, read-only operation against a closed world. The description adds the important workspace-boundary context, but it does not describe not-found behavior, authorization expectations, or the shape of the returned simulation.

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?

It is a single, front-loaded sentence with no filler. The only minor weakness is that it may be too terse for an agent needing to distinguish this getter from adjacent simulation-related getters.

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 getter with rich annotations and complete schema coverage, the description is adequate. Still, it omits what the returned simulation represents and how it differs from related simulation resources, leaving some ambiguity in a crowded sibling set.

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

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

The input schema has full description coverage for the single id parameter and documents it as a resource identifier from a previous request. The description does not add any parameter meaning beyond that, which is appropriate but not value-adding.

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

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

The description uses a specific verb and resource ('Get one simulation') and adds a workspace-scoping constraint. It does not explicitly distinguish this tool from sibling getters such as get_simulation_run, get_simulation_persona, or get_simulation_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?

The use case is implied: retrieve a single simulation by its id. However, there is no explicit guidance on when to use this instead of list_simulations or the related simulation-run/persona/scenario getters.

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 and openWorldHint=false, so safety and repeatability are covered. The description adds only the workspace-scoping constraint, which is useful but thin; it says nothing about behavior on a missing or cross-workspace id.

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

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

A single front-loaded sentence with no waste or filler. Its terseness is appropriate in size but leaves little room for the scoping and failure details an agent would want.

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

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

For a one-parameter read with full annotation and schema coverage, the essentials are present. However, there is no output schema, so the description should say something about what a persona contains or what happens when the id is unknown, and it does neither.

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

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

Schema description coverage is 100%, and the `id` parameter is documented as a resource identifier from a previous request, so the schema carries the load. The description adds no format or sourcing detail beyond that, making the baseline 3 correct.

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

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

States a specific verb and resource ("Get one simulation persona") plus a scope constraint ("belonging to this workspace"). The singular "one" implicitly separates it from list_simulation_personas, but it never names that sibling explicitly.

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

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

No when-to-use framing, no prerequisites, and no mention of the natural alternatives (list_simulation_personas to enumerate, get_simulation_scenario for related resources). The only guidance is the implicit workspace scoping, which an agent must infer.

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, openWorldHint=false and destructiveHint=false, so safety is fully covered structurally. The description adds one piece of behavioral context beyond that — that evaluations and the linked call are only included 'when available', i.e. the response shape varies by run state — but says nothing about failure behavior for an unknown id.

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

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

One short, front-loaded sentence with no filler, and the conditional 'when available' is a meaningful qualifier rather than padding. It is perhaps too terse for what the tool actually returns, but nothing 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 single-param read with full annotation coverage, the description is nearly sufficient, and the mention of evaluations and linked call partially compensates for the absent output schema. It still leaves open whether those fields are omitted or null when unavailable and what happens on a missing/invalid id.

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

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

There is a single parameter with 100% schema description coverage (pattern, length bounds, and 'Resource identifier returned by a previous request'), so the schema carries the semantics. The description adds nothing about the id beyond implying it identifies a run; baseline 3 applies.

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

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

States a specific verb (Read) and resource (a run), and adds that the payload includes evaluations and a linked call, which is more than the name alone conveys. However, it never says 'simulation run' explicitly nor distinguishes itself from siblings like get_simulation or list_simulation_runs, so an agent must infer the relationship.

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 on when to use this versus list_simulation_runs (discovery) or get_simulation (parent resource), and no prerequisites such as the run needing to be finished before evaluations exist. The conditional 'when available' hints at state dependence but does not explain it.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds the workspace-bound scoping constraint (records outside the workspace are presumably not reachable) but says nothing about behavior on a missing or foreign id.

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

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

One sentence, front-loaded with the verb and resource, with no filler. It is terse to the point of being slightly thin, but nothing in it 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 simple read-by-id tool with full parameter documentation and complete annotations, the essentials are covered. However, there is no output schema and the description does not say what a 'simulation scenario' contains or what a not-found response looks like, leaving a modest gap for an agent deciding what to do with the result.

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

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

Schema description coverage is 100%, and the single 'id' parameter is documented with its format constraints (pattern, length) and origin ('returned by a previous request'). The description adds no syntax or lookup guidance beyond the schema, so the baseline of 3 applies.

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

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

The description names a specific verb ('Get'), a specific resource ('one simulation scenario') and a scope ('belonging to this workspace'), which is enough to separate it from list_simulation_scenarios and get_simulation. It stops short of naming those siblings explicitly, so the differentiation is inferred rather than stated.

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

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

There is no guidance on when to call this rather than list_simulation_scenarios or get_simulation. The only contextual cue is the workspace scoping, from which an agent must infer that this is the by-id single-record fetch.

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 and openWorldHint=false, so safety and repeat-safety are covered. The description adds the useful constraint that the tool must belong to 'this workspace', but says nothing about auth requirements, error/not-found behavior, or cross-workspace access.

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

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

One short sentence with no filler, and the resource identity is front-loaded. It is efficient, though arguably trimmed to the point where the singular-vs-list distinction is only implicit.

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-resource read with complete annotations and a fully described schema, the description is enough to call it correctly. The remaining gaps are minor: no output-schema expectations stated, and no note on what happens when the id is not found or belongs to another workspace.

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

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

Schema description coverage is 100% and the single 'id' parameter is fully documented with type, pattern and length bounds, so baseline 3 applies. The description adds no meaning beyond the schema, but nothing is left undocumented either.

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

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

States a specific verb ('Get') and resource ('one tool'), and the word 'one' plus the workspace scoping distinguishes it from the sibling list_tools. It never names the sibling, so differentiation is implied rather than 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 singular 'one tool' implies retrieval by identifier rather than enumeration, which quietly contrasts with list_tools, but there is no explicit 'use this when / use X instead' guidance, no statement of prerequisites, and no mention of behavior when the id is unknown.

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, closed-world and non-destructive, so the safety profile is covered. The description adds that the payload includes validation ranges, which is useful context, but says nothing about behavior when provider is omitted (all providers vs. a default) or the shape of the response.

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

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

One front-loaded sentence with no filler. It is efficient, though its terseness contributes to the gaps noted elsewhere rather than being a model of expressive brevity.

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, zero-required-parameter tool with annotations covering safety, the description is close to adequate. It still omits the omitted-provider default and what the caller gets back, and there is no output schema to fill that 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?

Schema description coverage is 100%, so the single 'provider' parameter is already documented (albeit thinly) as optional. The description does not clarify whether omitting it returns every supported provider's settings, which is the main semantic question an agent would have.

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?

Specific verb + resource: 'Read supported provider voice settings and validation ranges.' The mention of settings and validation ranges separates it from sibling list_tts_voices / list_tts_rates / get_assistant_voice_presets, though those siblings are never named.

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

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

There is no guidance on when to call this rather than the adjacent TTS tools (list_tts_voices, list_tts_rates, get_assistant_voice_presets). The agent must infer usage purely from the noun phrase 'settings and validation ranges'.

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=false, so the safety profile is covered; the description adds the useful disclosure that the response includes policy and runtime enforcement state, not just balances. The units convention (microusd = integer millionths of USD) is genuinely valuable behavioral context absent from any structured field.

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

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

Two sentences, zero waste, front-loaded with what is read, and the unit convention follows immediately. Every sentence earns its place.

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

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

With no output schema and no parameters, the description carries the burden of describing return contents, and it does enumerate the key fields including policy and runtime enforcement. It stops short of stating account/scope assumptions or whether the wallet is per-organization, which would fully close the gap.

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

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

The tool takes zero parameters, so the baseline is 4 and there is nothing to document. The description instead spends its second sentence on output-unit semantics, which is a sensible use of space given the absent 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?

States a specific verb (Read) and a specific resource (prepaid wallet funds) plus the exact data returned: available, reserved and total funds, policy, funding availability and runtime enforcement. It is distinguishable from siblings like list_payments or list_balance_activity, though it never names or contrasts with get_billing_policy, which overlaps conceptually.

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

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

Usage is only implied: an agent can infer this is the balance-checking tool, but there is no explicit when-to-use statement and no routing against near-neighbours such as get_billing_policy, check_entitlements or list_balance_activity. Nothing is misleading, but the agent must infer the choice.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only a hint at what is returned ('waveform metadata', 'audio channels') and says nothing about behavior for missing/expired recordings or the size/shape of the payload, which matters since there is no output schema.

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

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

A single front-loaded sentence with no filler or repetition. It is efficient, though its brevity comes at the cost of the missing usage and return-shape context noted elsewhere.

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

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

The tool is simple (one required parameter) and annotations cover safety, but with no output schema the description should say more about what 'waveform metadata' actually contains (sample counts, peaks, duration, channel list). As written it names the return surface without describing it.

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

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

Schema description coverage is 100%, so the single 'id' parameter is already documented with pattern, length bounds and provenance. The description adds nothing beyond the schema – notably it never states that the id is a recording id, leaving the agent to infer the identifier's domain from the tool 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 pairs a specific verb ('Read') with a concrete resource ('recording waveform metadata and available audio channels'), which is more informative than a bare 'get'. It does not, however, distinguish itself from the other get_*/list_* siblings (e.g. get_metrics, list_calls) or clarify that this is scoped to recordings.

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

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

Usage is only implied by the resource name – an agent can infer 'call this when you need waveform metadata for a recording'. There is no explicit when-to-use, no prerequisites, and no mention of alternatives such as list_calls or other recording-related tools.

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

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

Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior. The description adds a meaningful behavioral constraint beyond annotations: full API-key values cannot be retrieved, only metadata. It does not mention pagination or return fields, but for a zero-parameter list this is a useful additional disclosure.

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

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

Two short sentences, front-loaded with the operation and immediately followed by the key limitation. Every sentence earns its place.

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

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

For a zero-parameter list tool with rich annotations and no output schema, the description is nearly complete. The only minor gap is not describing what metadata fields are returned or whether pagination applies.

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

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

There are no parameters, so the baseline is 4. The description does not need to compensate for schema gaps and correctly does not invent parameter 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 states a specific verb and resource: list this workspace's API-key metadata. It is distinguishable from create_api_key and revoke_api_key by resource and operation, though it does not explicitly route to or exclude any sibling.

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 does not state when to use this tool versus alternatives, nor does it mention prerequisites such as workspace permissions. Usage is only implied by the list operation itself.

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, non-destructive and closed-world, so the safety profile is fully covered. The description adds only the workspace scoping detail; it says nothing about result ordering, completeness, or whether all assistants are returned.

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

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

A single front-loaded sentence with no filler. It is efficient, though so terse that brevity shades into under-specification rather than crispness.

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

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

No output schema exists, so the description is the only place to learn what a listing returns, and it says nothing about result shape or volume. For a trivial no-param list tool this is adequate but leaves a real 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?

Zero parameters and 100% schema coverage, so there is nothing for the description to disambiguate. Baseline for a no-param tool applies.

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

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

Specific verb (List) and resource (assistants) with an explicit scope (authenticated workspace). It is clearly distinguishable from get_assistant and create_assistant, though sibling differentiation is implicit rather than stated.

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

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

The description gives no when-to-use guidance and never mentions alternatives such as get_assistant for a single assistant. The only context is the workspace scoping phrase, leaving the choice between list and get entirely to inference.

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, and closed-world, so the safety profile is fully covered. The description adds a business rule ('Funding is credited only after verified payment processing'), which explains why some entries may appear pending, but says nothing about result ordering, cursoring direction, or page-completeness 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?

Two short sentences with no filler, and the core purpose is front-loaded. The second sentence is a slight non sequitur to the tool's mechanics but carries genuine domain context.

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

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

For a simple two-param read tool with full schema coverage and annotations, the definition is adequate, and the mention of a returned pagination cursor partially compensates for the absent output schema. However, the ordering of entries and how the returned cursor maps to the `before` parameter remain unstated.

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

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

Schema description coverage is 100%, so both `limit` (default 50) and `before` (ledger identifier) are already documented in the schema. The description adds no syntax, ordering, or cursor-chaining detail, so baseline 3 is correct.

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

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

The description names a specific verb ('Read') and resource ('balance activity') and notes it also returns a pagination cursor, so an agent can tell this is a ledger-listing tool. It does not differentiate from related siblings like get_wallet or list_payments, leaving ambiguity about which source to consult for balance vs. payment history.

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

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

There is no explicit when-to-use guidance and no mention of alternatives such as list_payments or get_wallet. The agent must infer the choice from tool names alone.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real value beyond that: the shape of each row (transcript, analysis, costs, recording links) and the operational caveat that recordings need separate authentication, which an agent cannot learn from the schema.

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

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

Two tight sentences, front-loaded with the core capability and followed by the payload/auth caveat; no filler. The phrasing 'Read call logs, summary statistics and pagination' is slightly elliptical (pagination is a mechanic, not something read), costing a point.

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 13 optional params and no output schema, the description does the important work of describing row contents and the recording-auth caveat. It does not state default scope (are all calls in the account returned when no filters are given?) or whether summary statistics are always returned, which leaves a modest gap for a tool of this breadth.

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 92%, so all 13 filters are already documented with defaults (page 1, limit 200/1000, sort started_at) and the order enum. The description only gestures at pagination and adds no filter-combination or date-format semantics, which is the baseline-3 case.

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

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

States a specific verb and resource (read call logs) plus what else comes back (summary statistics, pagination), so an agent can tell it is the bulk call-listing endpoint. It does not explicitly differentiate itself from neighbours like get_metrics or list_simulation_runs, and the mention of 'summary statistics' slightly blurs the boundary with get_metrics.

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 never says when to use this tool versus alternatives, nor when not to (e.g. use get_metrics for aggregate reporting, or that filters can be freely combined). Usage has to be inferred from the parameter list alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered. The description adds only the 'authenticated workspace' scoping phrase and says nothing about pagination, ordering, or what fields come back, so it contributes very little beyond the structured data.

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

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

One short, front-loaded sentence with no filler, so it is efficient. However, the brevity stems from under-specification rather than tight writing: there is no qualifying detail after the core statement.

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

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

For a no-parameter list tool with no output schema, the description should tell the agent what the result set looks like (identifiers, titles, pagination). It provides none of that, leaving the agent unable to anticipate the response shape or whether results are truncated.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly avoids inventing parameters that do not exist.

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

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

It states a verb and a resource ('List knowledge'), but 'knowledge' is ambiguous compared with the actual sibling resources (knowledge documents) and the description gives no scope beyond the workspace. An agent can infer it enumerates knowledge documents in the current workspace, but nothing distinguishes it from get_knowledge_document or set_assistant_knowledge.

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

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

There is no statement of when to use this tool versus get_knowledge_document, list_assistants, or set_assistant_knowledge, and no prerequisites or exclusions. The agent must infer usage from the name alone.

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

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

The annotations already declare this as a read-only, idempotent, non-destructive, closed-world operation. The description adds a useful scope clarification that it does not purchase numbers, but it does not add details about permissions, pagination, or return 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 short sentences, front-loads the operation, and uses the second sentence to prevent a plausible confusion with buying numbers. It is appropriately sized with no wasted text.

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

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

For a no-parameter read-only list tool with rich annotations and no output schema, the description provides enough context to call it correctly. The main scope ambiguity, purchasing versus listing bindings, is explicitly 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?

The tool has zero parameters, so parameter semantics are not a substantial burden. The description adds no parameter meaning, which is appropriate for a no-parameter 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 uses a specific verb and resource ('List number bindings'), making the operation clear. It also distinguishes the tool from purchasing a phone number, though it does not explicitly contrast with the closer sibling actions bind_number and unbind_number.

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

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

Usage is implied by 'List number bindings,' and the negative statement rules out buying numbers. However, it does not explicitly say when to use this versus bind_number, unbind_number, or other listing tools.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds two useful facts beyond that — included statuses (confirmed and pending) and environment scoping (live/test) — but stays silent on result volume, pagination behavior, and whether all records are returned.

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

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

One front-loaded sentence with no filler; the status and environment qualifiers both earn their place.

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

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

For a zero-parameter list tool with no output schema, the agent gets no sense of what a payment record contains or how much data returns. It covers status and environment but leaves the return shape entirely undocumented.

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

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

With zero parameters and full schema coverage, there is nothing for the description to disambiguate. It correctly avoids inventing filter semantics, though the absence of any parameters also means there's no way to narrow results and the description could note that.

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

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

Names a specific verb ('Read') and resource ('confirmed and pending workspace payment records'), with scope qualifiers for status and environment. It doesn't explicitly contrast with nearby siblings like list_balance_activity or get_wallet, so an agent must infer the boundary, but the purpose itself 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?

Implicitly positions itself as the read path for payment data, but never states when to call it versus list_balance_activity or get_wallet, nor any preconditions. No explicit exclusions are 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?

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuinely new context: the response is metadata only and never exposes secret values, which tells an agent it is safe to surface results to a user. It stops short of noting any permission requirements or output shape.

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

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

Two short sentences, zero filler, with the core purpose front-loaded and the security caveat immediately after. Every sentence earns its place.

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

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

With no parameters, no output schema and full annotation coverage, the description carries little burden. It discloses the one thing an agent can't infer from structured fields — that secrets are never returned — though it could say slightly more about what 'metadata' includes (provider names, status, timestamps).

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

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

The tool takes no parameters, so the baseline is 4. Nothing in the schema needs compensating for, and the description correctly avoids inventing filtering options that don't exist.

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

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

States a specific verb and resource: lists configured provider credentials, which is clearly distinct from sibling list_api_keys or list_numbers. It does not explicitly name an alternative, but the resource is unambiguous enough that an agent can place it without opening the schema.

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

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

Usage is implied by the verb — call it when you need to see which providers are configured — but there is no explicit when-to-use, no exclusions, and no reference to alternatives such as list_api_keys for related credential inspection. For a zero-parameter read tool this is acceptable but thin.

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 and openWorldHint=false, so the safety profile is fully covered structurally. The description contributes only the workspace scoping detail; it says nothing about pagination, ordering, or whether the list is complete or truncated.

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

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

A single sentence with no filler, and the scope constraint ('authenticated workspace') is front-loaded rather than buried. Nothing could be removed without losing 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?

With zero parameters, no output schema, and annotations fully covering the read-only/idempotent profile, little else is required of the description. The only untold behavior an agent might want — pagination or result limits — is minor given the tool's simplicity.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain and the description cannot be faulted for omitting any. Baseline 4 applies here.

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

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

States a specific verb ('List') and resource ('simulation personas') scoped to the authenticated workspace, which lets an agent distinguish it from get_simulation_persona (single fetch) and list_simulations / list_simulation_scenarios (different resources). It stops short of explicitly naming those siblings, so differentiation relies on the agent reading the names.

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

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

Usage is only implied by the verb 'List' and the workspace scope; there is no explicit 'use this when...' or exclusion of alternatives such as get_simulation_persona for a single persona. For a zero-parameter enumeration tool the implied usage is reasonably unambiguous, but no guidance is actually written.

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=false, so the safety profile is covered. The description adds only a lightweight workflow hint and the mention of pagination, without describing ordering, default page size, or what happens when filters are omitted.

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

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

A single front-loaded sentence with no filler. The phrasing 'List simulation runs and pagination' is slightly awkward, but nothing 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?

With no output schema and six optional filters, the description should say more about returned fields or result ordering. It is adequate to pick the tool but thin for interpreting a filtered, paginated result set.

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

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

Schema coverage is 83%, so the schema already documents most parameters (page, limit, and the three identifier fields). The description does not clarify the status enum, filter combination semantics, or that all filters are optional, adding little beyond structured data.

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 verb 'List' + resource 'simulation runs' is specific, and it explicitly notes pagination support. It stops short of naming siblings such as get_simulation_run (single run) or list_simulations (parent resource), so the distinction must be inferred.

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?

'Inspect status before starting another run' gives one concrete usage moment and implicitly links to start_simulation_run. However, it offers no guidance on the other five filter parameters or when to prefer get_simulation_run or list_simulations instead.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is fully covered. The only added context is 'authenticated workspace' scoping; nothing is said about pagination, ordering, or result volume. With annotations carrying the safety profile, a 3 is appropriate.

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

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

One short, front-loaded sentence with no filler. It is efficient but under-specifies rather than being genuinely dense with useful information.

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

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

For a simple read-only list tool with full annotation coverage, this is minimally adequate. However, with no output schema the agent gets no hint about what a simulation record looks like or how to tell whether results are scoped or complete.

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

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

Schema description coverage is 100% and there is a single optional parameter, so the schema does the heavy lifting and baseline 3 applies. The description does not explain that assistant_id acts as a filter or what happens when it is omitted.

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

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

States a specific verb and resource ('List simulations') and adds a workspace scope, so the agent knows exactly what entity is returned. It does not differentiate itself from adjacent tools like get_simulation or list_simulation_runs, but the list-vs-get distinction is implicit.

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

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

There is no guidance on when to use this versus list_simulation_runs, list_simulation_personas, or get_simulation for a single lookup. It also never tells the agent that the optional assistant_id parameter can narrow results, which is the main decision point for calling it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds the useful scoping detail that results are limited to the authenticated workspace, which tells the agent it cannot query across tenants. It does not disclose whether results are paginated, ordered, or capped, which are the remaining behavioral unknowns for a list operation.

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

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

A single front-loaded sentence with no filler, hedging, or restatement of the tool name. Every element (verb, resource, scope) earns its place.

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

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

For a zero-parameter, read-only list tool with an output schema absent but a trivially predictable return shape, the description plus annotations cover what an agent needs in order to call it correctly. The only omission is result pagination or ordering behavior, a minor gap at this complexity level.

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

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

The tool takes zero parameters, so the schema carries no semantics an agent could miss and the baseline is 4. The description correctly indicates the only implicit filter, workspace membership, rather than suggesting any arguments the agent might try to pass.

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 gives a specific verb (List) and a specific resource (simulation scenarios) scoped to the authenticated workspace, which cleanly separates it from create/update/delete_simulation_scenario and get_simulation_scenario. It stops short of distinguishing it from nearby list siblings such as list_simulation_runs, list_simulation_personas, and list_simulations, relying on the resource name alone to do that work.

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 intent (enumerate scenarios) is implied clearly by the verb plus the sibling set, which contains the singular get_ variant for fetching one item. However, there is no explicit guidance on when to prefer this over get_simulation_scenario or list_simulations, and no mention of exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description's only added context is workspace scoping ('in the authenticated workspace'), with no mention of pagination, ordering, or result size.

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

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

A single front-loaded sentence with no filler; the scope constraint follows immediately after the verb and resource.

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 read with complete annotations, the description is nearly sufficient; only the absence of an output schema leaves the shape of the returned tool list unspecified. Given how simple the call is, nothing an agent needs in order to invoke it is missing.

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

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

The tool takes zero parameters, so per the baseline the description carries no parameter burden and needs no compensation. There is nothing for the description to explain beyond the resource itself.

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

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

The description gives a clear verb (List) plus resource (http tools) scoped to the authenticated workspace, so an agent knows it enumerates HTTP tool definitions rather than executing them. It does not differentiate from near siblings such as list_webhooks or list_assistants, which the reader must infer from the noun 'http 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?

There is no when-to-use guidance, no stated alternative, and no exclusion — the agent must infer that this is the discovery step before get_tool/update_tool/delete_tool. Nothing tells the agent when not to call it.

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

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

The annotations already say readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a genuine data caveat that the annotations cannot convey: these values are reference rates, not invoiced or total call prices, which is the context an agent needs to avoid presenting them as a bill.

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

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

Two short sentences, front-loaded with what is read and followed by the caveat. Nothing repeats the tool name and no sentence could be deleted without losing a useful constraint.

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

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

For a no-parameter, read-only list, the necessary safety and usage context is present, and the caveat about interpretation covers the main risk of misuse. It does not describe the shape of the returned rate list, and there is no output schema, so that is a small remaining gap, but an agent can still call it correctly.

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

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

There are zero parameters and the schema coverage is 100%, so nothing needs documenting. A 4 (the baseline for a no-parameter tool) fits; the description has nothing to add in this dimension, so it neither overstates nor weakens anything.

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

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

The description states a specific verb and resource: reading configured voice-cost reference rates. That is more precise than the name alone, which could be confused with list_tts_voices or get_tts_settings, but it never explicitly names those siblings, so the agent has to infer the boundary.

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?

"These are not an invoice or a complete call price" implies an alternative such as apifleet_estimate_call_cost for real cost, but it never says so outright. There is no explicit when-to-use or when-not-to-use statement, so the guidance is implied rather than stated.

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

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

Adds real behavioral context beyond the annotations: it discloses that credentials are resolved server-side (no client auth needed) and that a catalog failure yields an empty list plus an error that should not be read as 'provider has no voices.' That failure-mode warning is exactly the kind of non-obvious detail the annotations do not carry.

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

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

Two sentences, both load-bearing, with the credential behavior front-loaded and the failure caveat second. Nothing is padded.

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

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

With no output schema, the description should explain the shape of a successful response, but it only covers the failure case (empty list plus error). An agent does not learn what fields a voice entry exposes (id, name, locale) or whether the list is paginated, which matters for passing an identifier into downstream TTS configuration.

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

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

Schema description coverage is 100% for the single optional 'provider' parameter, so the schema already carries the semantics. The description only restates the notion of a provider catalog and adds no accepted value examples or default behavior (e.g. what happens when provider is omitted).

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

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

States a specific verb (Read) and resource (a provider voice catalog), plus how auth is sourced (server-side credentials). It does not distinguish itself from the nearby siblings list_voice_presets and get_assistant_voice_presets, so an agent must infer the difference between a provider catalog and presets.

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

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

Usage is only implied: fetch the catalog for a provider. There is no explicit when-to-use, no mention of when to prefer list_voice_presets or get_tts_settings instead, and no statement about whether the provider argument is required in practice.

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 openWorldHint, so the safety profile is covered. The description adds a useful caveat that provider catalog requests may reach a vendor, which reinforces external side effects, but it does not describe return shape or latency/auth implications beyond that.

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

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

Two short sentences with the primary action front-loaded and a secondary caveat appended. There is no filler or repetition.

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

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

For a simple read-only list operation with full schema coverage and clear annotations, the description is functionally adequate. However, in a crowded sibling set containing get_assistant_voice_presets, list_tts_voices, and related TTS tools, the lack of differentiation leaves a meaningful selection 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?

Schema description coverage is 100%, so the three optional parameters are already documented as model, provider, and realtime_provider. The description does not add meaning or filtering behavior beyond what the schema provides, making baseline 3 appropriate.

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

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

States a specific verb and resource: reading configured runnable voice presets. It is clear what the tool returns at a high level, but it does not explicitly distinguish itself from similar siblings such as get_assistant_voice_presets or list_tts_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 no guidance on when to use this tool versus the many related voice/preset/TTS tools. The caveat about provider catalog requests reaching a vendor is behavioral context, not usage guidance, and there are no exclusions or alternatives named.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered. The description adds useful scoping context (results are limited to the authenticated workspace), but says nothing about pagination, result ordering, or volume.

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

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

A single short sentence with the resource and scope front-loaded and no wasted words. It is appropriately sized for a zero-parameter list tool, though it leaves no room for behavioral detail.

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

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

With no input parameters, no output schema, and full annotation coverage, the definition is nearly complete. However, since no output schema exists, the description could have stated what each webhook record contains or whether results are paginated.

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

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

The tool takes zero parameters, so the baseline is 4. There is no parameter information the description needs to supply, and nothing it could add.

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

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

States a specific verb and resource ('List webhooks') plus scoping ('in the authenticated workspace'). It is clearly distinguishable from siblings such as create_webhook, update_webhook, and delete_webhook, though the description does not explicitly call those out.

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

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

There is no explicit when-to-use or when-not-to-use guidance and no referenced alternative. The name and the phrase 'authenticated workspace' imply the read/list context, but this is inference rather than stated 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 destructiveHint=true and idempotentHint=true, so the bar is lower. The description still adds real value annotations cannot: that revocation takes effect immediately and that revoking the in-use key disconnects this MCP client on its next request, a self-destructive consequence worth flagging.

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

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

Two tight sentences with the primary action front-loaded and the risk warning second. No filler or restatement of the tool name.

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 one-parameter tool with full schema coverage and no output schema, the description covers effect timing and the notable self-revocation hazard. It could state explicitly that revocation is irreversible/permanent, but the immediate+destructive framing gets close.

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?

One parameter with 100% schema description coverage, so the schema already explains the id field and its constraints. The description adds no format or sourcing detail beyond that, so baseline 3 applies.

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

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

States a specific verb (revoke) and resource (workspace API key) with a timing qualifier (immediately). An agent can distinguish it from create_api_key and list_api_keys without opening schemas, though it doesn't explicitly note that no delete_api_key sibling exists.

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

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

Usage is implied by the destructive nature of revocation, but there is no explicit when-to-use/when-not guidance and no pointer to list_api_keys for obtaining the id. The agent must infer the 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?

The annotations already state that this is not read-only, is idempotent, and is not destructive. The description adds important behavioral context by stating that the operation replaces all attachments and that every document must belong to the workspace. It does not explain permissions or response behavior, but it adds meaningful replacement semantics 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?

Two short sentences, front-loaded with the core action and followed by the key constraint. There is no wasted wording.

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

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

For a two-parameter mutation with full schema coverage and meaningful annotations, the description provides the essential replacement semantics and the workspace constraint. It does not describe return values or permission requirements, but it is largely complete for correct invocation.

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

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

Schema coverage is 100%, so the parameter definitions already carry most of the burden. The description adds a semantic validation rule not present in the schema: all supplied knowledge documents must belong to the workspace. That gives useful extra meaning for the nested knowledge_ids list.

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 a specific verb and resource: replace all attached knowledge documents. It also adds the workspace ownership constraint. It does not explicitly distinguish this from sibling tools such as set_assistant_tools, but the resource is specific enough to identify the operation.

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

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

The phrase 'Replace all' implies the use case is complete replacement rather than incremental attachment, but the description does not explicitly say when to use this versus related tools or when not to use it. Usage is therefore implied rather than fully guided.

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

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

Annotations declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the mutation/idempotency profile is already known. The description adds genuinely non-obvious behavior: this is a full replacement, not a merge, and an empty list removes all attachments — a real data-loss path an agent must know before calling. The 'owned by this workspace' constraint on tool_ids is also behavior, not schema. Minor tension with destructiveHint=false in that clearing the list removes existing attachments, but the operation is reversible and idempotent, so this is not a contradiction.

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

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

Two short sentences with zero filler. The replace-all semantics lead and the detach edge case follows, so the most consequential fact 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?

For a 2-parameter setter with no output schema and available annotations, the description covers the essential risk (full replacement, empty detaches) plus the workspace-ownership precondition. It could say more about what happens to tool_ids that are not workspace-owned (error vs. ignored), which is the one remaining ambiguity.

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

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

Schema coverage is 100% and the schema already documents tool_ids as a 'complete replacement list; an empty list removes every attachment.' The description's statement about empty tool_ids therefore restates the schema rather than adding new semantics, so baseline 3 applies.

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

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

States a specific verb and resource: replace the assistant's attached HTTP tools with workspace-owned tools. The 'HTTP tools owned by this workspace' scope is precise and separates it from knowledge attachment (set_assistant_knowledge), though it never names that sibling explicitly.

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

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

Implies the use case (setting the full attachment set) and gives one clear edge-case rule: an empty tool_ids detaches everything. It gives no explicit when-not-to-use guidance or pointer to alternatives such as set_assistant_knowledge for knowledge attachments.

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 destructive=true, idempotent=false, openWorld=true, so the safety profile is known. The description adds genuinely new context beyond that: the batch nature, the cost implication of multiple test runs, and the need for prior approval. It stops short of describing what happens if part of the batch fails or whether queued runs can be cancelled.

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

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

Two short sentences with the operation stated first and the risk warning second. Nothing is redundant or buried.

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

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

With no output schema, an agent still does not know what a successful call returns (batch identifier, list of run IDs) or how to track progress, which matters for a queued multi-run operation. The critical cost and confirmation risks are covered, but the result contract is not.

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

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

Schema coverage is 100% and the confirm parameter already carries an explicit 'set true only after the user approves this paid action' note, so the schema does the heavy lifting. The description's 'approve the batch first' reinforces confirm but adds no syntax or meaning beyond it, so the baseline of 3 applies.

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

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

States a specific verb and resource: queue every simulation belonging to one assistant, which implicitly contrasts with the single-run sibling start_simulation_run. It is clear enough to distinguish from siblings, but it never names the batch-vs-single alternative explicitly.

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

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

'Approve the batch first' implies the confirmation prerequisite, and 'can incur multiple test runs' warns of the scale of the action. However, there is no explicit when-not guidance, no statement of what preconditions must exist (e.g., simulations already created for that assistant), and no named alternative for launching a single run.

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?

Adds real context beyond the annotations: the run is asynchronous, models and speech incur usage, approval is required, and the returned identifier must be polled without re-enqueuing while running. That meaningfully supplements the destructive/openWorld/non-idempotent hints, though it doesn't say what happens to an in-flight run if the call is repeated.

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 short sentences, front-loaded with the action and then the cost/approval/polling constraints. Nothing is redundant and every sentence carries an operational fact.

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

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

Covers the async lifecycle and cost/approval model, which is what an agent needs to invoke a 3-parameter paid job. It does not name the polling tool or clarify the relationship to the batch-start sibling, which keeps it short of a 5.

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

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

Schema description coverage is 100%, with confirm and id already documented in the schema, so the baseline is 3. The description reinforces the approval semantics of confirm but adds no new syntax or format detail for the nested data options.

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

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

States a clear verb and object: 'Queue an asynchronous test', which tells an agent this starts an async execution rather than creating a definition. It never names the 'simulation run' or distinguishes itself from siblings like start_simulation_batch, so 4 rather than 5.

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

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

Gives procedural guidance ('Approve the run first', 'poll the returned identifier', 'do not enqueue again while it is running') but does not say when to choose this over start_simulation_batch or create_simulation. Usage is implied by context, not by explicit 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 flag destructiveHint=true and idempotentHint=true, so safety profile is covered. The description adds genuinely useful context beyond that: the carrier number survives the operation, which is the key side-effect an agent must know before invoking a destructive tool.

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

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

Two terse sentences with zero waste. The primary action is front-loaded and the critical caveat follows immediately.

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

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

For a one-param destructive tool with strong annotations and a complete schema, the description covers the essential ambiguity (removal vs. cancellation). Only minor gaps remain, such as what happens if no binding exists or what the response confirms, though the idempotent hint partially covers the former.

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

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

The single 'number' parameter is fully documented in the schema (100% coverage) including the E.164 pattern and leading '+'. The description adds nothing about the parameter, so baseline 3 applies since the schema carries the burden.

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

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

States a specific verb and resource ('Remove the routing binding') and immediately delineates scope with 'does not release or cancel the carrier number.' This distinguishes it from number-lifecycle operations, though it doesn't explicitly name the sibling bind_number that would be its natural counterpart.

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 negative clause implies the use case (detach routing while retaining the number), but the description never states when to choose this over alternatives like bind_number or a number-release flow. Usage is inferable 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?

Annotations already declare readOnly=false and destructive=false; the description adds the meaningful behavioral fact that this is a partial update where omitted fields are preserved. It says nothing about permissions, revision conflicts, or side effects, and the useful note that saving config does not place a call lives only in the schema, not the description.

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

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

Two short sentences, front-loaded with the action and followed by the one non-obvious rule. No filler.

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

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

Adequate for a mutation tool with rich schema coverage and annotations, but thin on context an agent would want: no mention of the related set_assistant_tools/set_assistant_knowledge siblings that own other assistant configuration, and no note on permissions or what the update returns.

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

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

Schema description coverage is 100% and all three parameters (id, data, if_revision) are documented in-schema, including the If-Match/409 reload behavior. The description adds only the general patch semantic, which is baseline-appropriate given the schema does the heavy lifting.

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

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

States a specific verb and resource ("Update selected assistant fields") and immediately clarifies patch semantics with "Omitted fields retain their values." It is clearly distinct from create_assistant/delete_assistant, though it never names those siblings explicitly.

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

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

The partial-update statement implies this is the tool for modifying an existing assistant rather than replacing it, which is useful implicit guidance. However, there is no explicit when-to-use framing, no mention of prerequisites (the assistant must exist), and no routing to related siblings like set_assistant_tools or set_assistant_knowledge.

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 that this is a non-read-only, non-idempotent, non-destructive mutation. The description adds useful behavioral detail: omitted fields retain their values, so it is a partial update rather than a full replacement. However, it does not mention permissions, whether name changes can collide, or other side effects, so it adds only moderate 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 two short sentences and is front-loaded with the action and resource. The second sentence adds the key partial-update rule without unnecessary repetition.

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

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

The schema is rich, including nested field descriptions, size limits, and a documentation link, and annotations cover the mutation safety profile. The description adds the essential partial-update semantics. It does not explain return behavior, but no output schema exists, so this is a minor gap rather than a blocking omission.

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

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

Schema description coverage is 100%, so both the id and nested data fields are already documented in the schema. The description does not add field-level meaning beyond the schema; its main contribution is the general partial-update rule. A baseline 3 is appropriate when the schema carries the 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 states a specific verb and resource: update a knowledge document. It also clarifies the partial-update behavior with 'selected fields' and omitted fields retaining values. It does not explicitly distinguish the tool from siblings such as create_knowledge_document or set_assistant_knowledge, so it stops short of a 5.

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

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

The description implies when to use the tool by describing partial updates, but it does not explicitly say when to choose it over alternatives such as create_knowledge_document, get_knowledge_document, or delete_knowledge_document. The usage context is inferable but not spelled out.

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=false, destructiveHint=false, openWorldHint=false and idempotentHint=false, so the safety profile is covered. The description adds genuinely useful PATCH semantics beyond the annotations, but says nothing about what happens to the undocumented 'additionalProperties' settings, error behavior on an unknown id, or permission requirements.

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

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

Two terse sentences with zero waste; the core operation is front-loaded and the patch caveat follows immediately. Nothing to trim.

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

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

For a mutation tool with a nested, open additionalProperties object and only two sentences of prose, the definition is adequate but thin: it does not mention the external docs link that the schema references, nor whether additional settings are merged or replaced. Annotations cover mutability, but the interaction with the extensible 'data' object is left unexplained.

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

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

Schema coverage is 100% and the nested 'data' object documents name, persona_id, scenario_id and assistant_id, so the schema carries the parameter burden. The description only says 'selected simulation fields' without naming any of them, adding no meaning beyond the schema — baseline 3 applies.

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

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

States a specific verb ('Update') and resource ('simulation fields') plus the key patch semantic that omitted fields retain their values. The resource is clearly distinguishable from the persona/scenario/run siblings by name, though the description never explicitly contrasts with 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?

'Omitted fields retain their values' implicitly tells the agent this is a partial update and that only changed fields need to be sent. However there is no explicit when-to-use vs. create_simulation or update_simulation_persona/scenario, and no mention of prerequisites such as the simulation existing or being in an editable state.

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