Widely

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

Annotations cover the write/safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), and the description adds genuinely new behavioral context: extra channels are billed to the wallet and the grant already permits the action. It does not explain what happens to in-flight calls or the exact failure mode, but it adds real 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?

Three short sentences with the core action front-loaded; nothing is padded. 'The grant already allows this' is slightly cryptic but earns its place as permission 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 two-parameter mutation tool with no output schema, the description supplies billing, permission, and capacity semantics, which is nearly enough. The main gap is the undocumented number_id and the absence of any success/return behavior.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies channel_count's meaning (concurrent calls) and the minimum of 2 (redundant with the schema minimum), but never explains number_id at all, leaving one of two parameters undocumented.

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: 'Set how many calls a number can take at once,' which conveys that this tool changes concurrent-call capacity for a number. It is distinguishable from siblings like check_call_rate or buy_number, though it never names or 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?

There is no guidance on when to use this tool versus alternatives such as check_call_rate or buy_number, nor any stated prerequisites beyond the cryptic 'the grant already allows this.' The agent must infer the trigger condition 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 cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), and the description adds non-obvious behavior: a human reads it, the support AI will not answer it, and any connected account may call it. It stops short of stating that repeated calls create multiple tickets or describing any throttling, so it is strong but not exhaustive.

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?

Front-loaded with the core action and trigger, then exclusions, then the follow-up call. Every sentence carries distinct routing or content information; nothing is redundant with the title or schema.

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

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

For a one-parameter write tool with no output schema, the description supplies the trigger, the audience (a person, not an AI), the access scope, the escalation path via read_support, and the negative cases. Nothing an agent needs in order to call it correctly 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 0% for the single 'text' parameter, so the description must carry the burden. 'Say what is needed and what was already tried' usefully specifies the content the string should contain, but adds no format, length, or structural guidance. Partial compensation for a one-parameter 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 and resource — 'Write into this user's Support chat' — and frames the triggering condition ('when a tool cannot finish the job'). An agent can distinguish this from search_help, submit_product_note, and read_support without opening any 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?

Gives explicit when-to-use, three explicit exclusions ('Do not use this for a price or a how-to that search_help or a quote tool can answer', 'Do not use submit_product_note for an account request'), and the follow-up step ('Then call read_support'). Alternatives are named by sibling tool, which is exactly what routing needs.

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 give the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), but the description adds real context: that money is deducted from the wallet, that the existing grant already authorizes the purchase, and that the call is not safe to blindly retry without an idempotency key (consistent with idempotentHint=false). It also discloses the return value (price charged) despite 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?

Three tight sentences, front-loaded with the action and its cost implication, with no filler. "The grant already allows this" is slightly cryptic in isolation but earns its place as permission 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 7-parameter, 0%-documented mutation tool with no output schema, the description leaves the core question unanswered: which parameters must be supplied to specify the number. Retry safety and return value are covered, but an agent still cannot construct a correct call from this definition alone.

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?

Seven parameters with 0% schema description coverage, and the description only explains idempotency_key. It never clarifies how sku_id, country, number_type, did_group_id, and stock_did_id relate to each other or which combination identifies the number being purchased — a critical gap given zero required 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?

States a specific verb+resource (buy a phone number) plus the side effect (charge the wallet), which cleanly separates it from quote_number, search_numbers, and list_did_numbers. It stops short of naming a sibling alternative for price discovery, 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?

"Pass idempotency_key so a retry does not buy a second number" is genuine invocation guidance, and "The grant already allows this" signals no extra auth step is needed. However, there is no routing guidance toward quote_number for pricing or search_numbers for discovery, so when-to-use-vs-alternatives 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 the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false), so the description carries a lighter burden. It adds one genuinely useful behavioral fact – that pricing keys off the destination rather than the caller's location – but says nothing about caching, rate freshness, or partial-input 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 tight sentences with no filler, and the core scoping fact is front-loaded. It could still work harder given the budget it saves.

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 three-parameter, zero-schema-coverage, no-output-schema pricing lookup, the description is only marginally adequate. The absence of an output schema excuses it from describing return values, but the unresolved ambiguity between country and destination is a real gap an agent will hit at call time.

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

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

Schema description coverage is 0%, so the description must compensate and it largely does not. 'Destination country or number' loosely gestures at the country/destination pair but never explains their relationship or precedence, and number_type (mobile/geographic/landline) is never mentioned at all.

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 resource (per-minute call rate) and scopes it to this account, and adds a clarifying constraint that the rate depends on destination, not origin. It does not, however, distinguish itself from closely related siblings such as get_data_rate, get_did_rate, or quote_call, leaving the agent 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?

There is no when-to-use guidance, no mention of prerequisites, and no reference to the pricing siblings (get_data_rate, get_did_rate, quote_call) that an agent must choose between. Usage is only implied by the tool name.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the risk profile is covered structurally. The description adds plan/authorization context ('Business... The grant already allows this'), which is genuinely beyond the annotations, but it is written as vague fragments and never states that hangup is irreversible or that a transfer dials an external party.

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 operative sentence is front-loaded and tight, but it is followed by two sentence fragments ('Business. The grant already allows this.') that read as noise and dilute the instruction.

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, non-idempotent call-control tool with no output schema, the description omits key operational facts: that 'destination' is required for transfer, what happens to the call on failure, and whether hangup is terminal. An agent could mis-invoke transfer by omitting destination.

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% across three parameters, so the description carries the full burden. It only echoes the four values already encoded in the 'action' enum and says nothing about 'destination', including the fact that it is conditionally required for the transfer action.

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 set (hold, resume, hang up, transfer) against a specific resource (a call in progress on this seat), so the agent knows exactly what operation class this is. It does not distinguish itself from nearby siblings like get_call, request_call, or quote_call, which would require the agent 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?

'a call that is in progress on this seat' is a real precondition that implicitly tells the agent not to use this for completed calls. However, there is no explicit when-not guidance and no named alternative (e.g., request_call for new calls), so the routing decision 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 establish this is a safe read (readOnlyHint=true, destructiveHint=false), and the description adds real context beyond them: it discloses that no sign-in is required, that signup uses a one-time code, and it constrains the agent to quote the path and confirmation word rather than inventing a name or promising a refund.

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?

Short and front-loaded with the core purpose in the first sentence, followed by the key constraints. The telegraphic second half is terse but every clause (path, confirmation word, no invented name, no refund promise) carries usable instruction.

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 instructional tool with no output schema, the description adequately conveys what the tool returns (a path and a confirmation word) and the rules for relaying it, leaving little an agent would need before calling it.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4; the schema is fully described and there is nothing for the description to clarify about inputs.

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 resource and action: the documented flow for how a customer deletes a Widely account, matching the 'steps' nature of the name. It is distinguishable from siblings like esim_install_steps or port_requirements by resource, though it never explicitly names a contrasting 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?

Usage is implied by the name and opening line (this is the tool for account-deletion guidance), and 'No sign-in' hints at the relevant scenario, but there is no explicit 'use this when the user asks how to delete their account' statement or exclusion 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 readOnlyHint, idempotentHint, and non-destructive, so the safety profile is covered. The description adds genuinely new context beyond them: 'No sign-in' (no authentication needed) and the APN handling rule, which governs interpretation 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?

Three short, front-loaded fragments with no filler; the core resource is stated first. The telegraphic style borders on under-specification, 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, the description must carry the burden of explaining what comes back; 'install path and APN' hints at the return content but gives no sense of format or completeness. For a zero-parameter read tool with full annotation coverage this is minimally adequate.

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

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

The tool takes zero parameters, which sets the baseline at 4. The stray reference to 'apn' is not an input field, so it does not create ambiguity about invocation, but it also adds nothing to 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 phrase 'eSIM install path and APN' states the resource and implies the returned content, and the title 'How to install an eSIM' reinforces it. However, it never distinguishes this from siblings like order_esim, quote_esim, or run_esim_connection_check, so the agent must 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?

There is no explicit when-to-use guidance and no named alternative. The only instruction, 'If apn is null, do not invent an APN,' is an output-handling rule rather than a condition for selecting this tool over its siblings.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds real behavior beyond that: the response carries amounts and labels, the list can legitimately be empty ('Do not invent a charge when the list is empty'), and refund promises are out of scope. It omits auth needs and rate limits, but for a read tool this is solid added context.

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

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

Four short, front-loaded sentences with no filler; the resource statement leads and the guardrails follow. It is telegraphic to the point of being terse, 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, the description usefully names the return content (amounts, labels) and the empty-list case, but it leaves the 'question' parameter undefined and never positions the tool against the many wallet/account siblings. Adequate but with clear gaps for a one-parameter, schema-poor 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 0% and the description says nothing about the single 'question' parameter — no format, no examples, no note that it is optional free text. The only indirect hint ('Quote the returned amounts and labels') implies a question-answer shape but does not document the parameter 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 fragment 'Charges already on this account' identifies the resource but supplies no verb, so the agent must infer from the name that the tool explains existing charges rather than listing, disputing, or refunding them. It does not distinguish itself from sibling listers such as list_wallet_activity or list_wallet_refunds.

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 post-call output rules ('Quote the returned amounts and labels', 'Do not promise a refund') but no when-to-use guidance and no named alternative. An agent cannot tell from this text when explain_charges is preferable to get_account_balance or list_wallet_activity.

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 structurally. The description adds the read scope (what fields are returned) and a sequencing hint, which is useful but not rich behavioral context such as freshness or auth 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 sentences with no filler; the returned scope is front-loaded and the invocation hint follows. The first sentence is a bare noun list without an explicit verb, which slightly blunts the front-loading.

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 params, no output schema and full annotation coverage, the description's enumeration of returned fields is exactly the missing piece and makes the definition actionable. It could go further by distinguishing itself from the overlapping get_account_balance sibling.

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 parameter semantics to explain and the baseline is 4. The description correctly adds nothing spurious about inputs.

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 the resource and enumerates the returned scope (plan, balance, member count, live eSIMs, runnable setups), which is more informative than the title 'Read the account.' It does not differentiate from the sibling get_account_balance, which overlaps on the balance field, so it falls short of a 5.

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

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

'Call this before setting up a line' gives a concrete trigger condition for invoking the tool. However, it names no when-not condition and points to no alternative among the many read siblings (get_account_balance, get_usage, list_plans), so the routing guidance is incomplete.

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 that the value is 'live' and aggregated only, which is modest additional context but no caching, freshness timing, or formatting 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 substance ('live wallet total for this seat') and zero redundancy. The 'same headline as Home and Wallet' sentence is mildly app-referential rather than informational, keeping it just short of ideal.

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 full annotation coverage and no output schema, the description tells the agent what the value represents (seat-scoped live total, no breakdown), which is sufficient to call it correctly. Currency/format details and explicit fallback routing are the only minor omissions.

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. The description correctly implies no inputs are needed, though there is no opportunity to add parameter meaning.

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 resource and scope: the live wallet total for this seat, with an explicit exclusion of any spendable/reserved breakdown. That distinguishes it from wallet-activity and usage siblings without naming them. It stops short of a clean verb+resource phrasing, relying on UI references ('Home and Wallet') for grounding.

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 spendable or reserved breakdown' implicitly tells the agent this is not the tool for detailed balance composition, which is useful negative guidance. However, no alternative tool is named for getting the breakdown (e.g. a wallet details or usage sibling), so the routing 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=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only what data is returned, which is mildly useful given the absence of an output schema but adds no behavioral context (e.g., what happens when top-up is unset).

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 tight sentence with no filler, and it leads with the most important fact (whether auto top-up is on) before the supporting fields.

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

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

For a zero-parameter read-only getter, the description is largely sufficient and even hints at the return shape in lieu of an output schema. It could be slightly more complete by noting the relation to set_auto_topup or the default when top-up is disabled.

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 there is nothing for the description to disambiguate. Baseline of 4 applies for zero-parameter tools.

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

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

The description names the resource (auto top-up settings) and enumerates the three field values it exposes (on/off, threshold, amount), so an agent knows exactly what this getter returns. It lacks an explicit verb like 'retrieve' and never names the sibling set_auto_topup as its counterpart, so it does not fully differentiate itself from the mutator.

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, and no mention of the obvious companion tool set_auto_topup. The pairing is inferable from the name alone, but the description contributes no routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description adds only that the response surfaces identity and provider attribution, and says nothing about error behavior for an unknown call_id 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?

A single front-loaded sentence with no filler; the identity of the resource and the key returned fields come first.

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 read tool with no output schema, the description is minimally adequate but does not enumerate what 'full detail' contains (direction, duration, timestamps, status) nor how a call_id is obtained, which the absent output schema would otherwise need to compensate for.

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 one required parameter and schema description coverage is 0%, so the schema documents nothing about call_id. The description mentions 'by call_id' but adds no format, source, or example, leaving the agent to infer where the identifier comes from.

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 ('Full detail for one call by call_id') and adds scope detail about what is returned ('which identity and provider carried it'), which separates it from siblings like get_recording, get_transcript, and search_calls. It does not explicitly name those alternatives, 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 phrase 'by call_id' implies the tool is a lookup that requires an id already obtained elsewhere (e.g. from search_calls), but the description never states when to use this versus search_calls or the other per-call getters. 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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuine context beyond that: the rate is account-scoped and starts from data already used this period, plus a caveat ('Do not quote the 1 GB total as the price of data') that warns the agent against a common misinterpretation.

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 core purpose and followed by two operational caveats. No filler, though the compressed jargon ('data ladder', 'volume points') costs some clarity that extra words would have fixed.

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 carries the burden of explaining what the call yields, and it does so partly by describing the volume-points output and warning about the 1 GB total. What is still missing is the shape of the returned ladder and how it should be presented, leaving a modest gap for a rate-lookup 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%, so the baseline is 3, but the description adds meaning the schema lacks: omitting 'gb' returns the volume points rather than a single-point price. That behavioral meaning of the optional parameter is not captured in the schema itself.

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

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

The description states a specific resource (this customer's pay-as-you-go data rate) and disambiguates it from public pricing with 'Not the public shelf.' The verb is implied rather than stated, and the terms 'data ladder' and 'volume points' are jargon that is not defined, which slightly blurs the purpose.

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

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

It implicitly distinguishes the account-specific rate from public pricing ('Not the public shelf'), which is useful routing context. However, it never names an alternative sibling (e.g. quote_esim or a public rate tool) or states an explicit when/when-not condition, so an agent must infer which tool to pick.

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 useful context with 'indicative' (non-binding estimate) and 'using this account's rate checker' (account-specific pricing), but says nothing about currency, billing cadence precision, or what happens if the country is unsupported.

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 tight sentence with the resource and scope front-loaded and no filler. It is appropriately sized, though the brevity is partly why other dimensions are thin.

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 could have explained the returned price (currency, monthly cadence), and it left the number_type parameter unexplained. For a two-parameter pricing lookup this is adequate but leaves clear gaps.

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

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

Schema description coverage is 0%, so the description must carry the burden. It implicitly ties the 'country' parameter to the lookup, but number_type is wholly undocumented in both the schema and description, and no format or accepted values are given for either parameter.

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

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

States a specific verb and resource: an indicative monthly phone-number price for a country. It also distinguishes itself from the sibling rate tools (get_call_rate, get_data_rate) by naming 'phone-number price' and by scoping to 'this account's rate checker'. However it never names or contrasts with quote_number, the closest 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?

There is no when-to-use guidance and no alternatives named. Given siblings like quote_number and quote_port, an agent gets no signal on why it would choose get_did_rate over quote_number, nor any prerequisite such as needing a country first.

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 safety is covered. The description adds real behavioral context beyond that: this is a polling operation and it surfaces fail/warn items, plus an explicit caution that the agent must not claim settings were changed — useful guidance for a read-only polling 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?

Terse and front-loaded — the core action leads, followed by a behavioral note and a caution. "Coach fail and warn items" is clipped and slightly opaque, but no sentence is padding.

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 describe what the check returns; it gestures at "fail and warn items" but not the full shape or how the polling terminates. For a simple read-only single-param tool it is adequate but leaves the async/polling contract underspecified.

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% for the single required request_id, so the description carries the burden. It implicitly links the id to the check "started by run_esim_connection_check," which gives some meaning, but never states that request_id is that identifier or its format.

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 ("Poll a check") and ties it explicitly to its creator, run_esim_connection_check, so an agent can distinguish it from the sibling that starts the check. It is slightly less crisp about what the returned check content actually is, but the core purpose is unambiguous.

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

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

"Poll a check started by run_esim_connection_check" implies the usage context (call after starting a check) but does not state when not to call it or how often/when to stop polling. Usage is inferable rather than 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=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds the 'this seat's' scope and a cryptic 'Pro' note, but omits whether it requires the Pro plan, auth level, or what is returned. Credit for the scope hint, but not rich.

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

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

Two short fragments that are front-loaded, but the standalone 'Pro.' does not clearly earn its place - it is ambiguous whether it flags a plan requirement or something else, leaving the reader to guess.

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 parameterless read-only getter this is close to adequate, but with no output schema and no description of what fields come back (numbers, destinations, conditions), an agent cannot predict the response. The purpose is stated but the completeness gap remains for the return shape.

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 with 100% schema coverage, so the baseline is 4. The description has no parameters to clarify, and nothing is missing on this dimension.

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 phrase 'How this seat's numbers are forwarded' describes the resource and implies a read, which is enough to sense intent, but there is no explicit verb and no differentiation from the sibling update_forwarding or uk_divert_number. It identifies the topic but not the operation crisply.

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 and no alternative named, even though update_forwarding and uk_divert_number are obvious siblings. The 'Pro' fragment hints at a plan gate but does not tell the agent when to call this versus the update path.

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 non-open-world, so the safety profile is fully covered without description help. The description adds only what data is exposed (toggles plus low-balance threshold) and says nothing about auth requirements, format, or freshness.

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 phrase with zero waste and the key content front-loaded. It is efficient, though the terseness borders on under-specification for a tool whose description is its only prose.

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-param read tool with no output schema, the description partially compensates by naming the returned data, and annotations cover safety. It still omits the read/write relationship to set_notification_preferences and any return-shape detail, leaving it minimally viable.

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 is 4. No parameter-related gaps 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?

The description is a noun phrase ('Notification toggles and the low-balance threshold') rather than a verb+resource statement, so the agent must infer from the name that this reads those settings. The subject matter is specific enough to separate it from unrelated siblings, but it never states that it retrieves anything.

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 prerequisites, and no mention of the obvious counterpart set_notification_preferences for changing these values. The agent gets no help deciding between reading and writing notification settings.

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 line 'A port is not instant' adds a hint that the operation is long-running and results may not change between polls, which is genuine behavioral context, but it is too terse to specify polling cadence or terminal states.

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 very short sentences that are front-loaded and free of padding. The second sentence is memorable but cryptic, functioning more as a hint than information, so it only partially 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?

No output schema exists, so the description is the only place a caller could learn what 'status' means (e.g., pending/approved/rejected, carrier timings). It supplies none of that, and with a 0%-documented parameter the definition is too thin for an agent to call confidently.

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% and port_id has no description, so the description must carry the burden and does not. It never states that port_id is the identifier returned by submit_port/start_port, leaving the agent to guess where the value comes from.

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 phrase 'Where a port request stands' conveys that this retrieves the status of an existing port request, which is a recognizable verb+resource pairing against siblings like start_port/submit_port. However, it never uses a concrete verb ('retrieve', 'check status of') and does not explicitly distinguish itself from port_requirements or quote_port.

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 versus port_requirements, quote_port, start_port, or submit_port, nor any prerequisite such as 'call after submit_port to track progress'. The reader must infer the lifecycle position 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 readOnly/idempotent/non-destructive, so the bar is lower, yet the description still adds real context: authorization ('No account required') and ordering behavior ('oldest first'). It omits pagination or thread-size limits, 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 terse sentences, front-loaded with the core action and the scoping constraint; no filler or redundancy.

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

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

For a simple single-parameter read with no output schema, the description covers identity, scope, auth, and ordering. Only pagination/return-shape details are absent, which is acceptable given the trivial schema.

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

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

Schema coverage is 0% and there is one required parameter, but the description does tie conversation_id to the product-note thread it identifies. It adds no format, source, or validation detail beyond that minimal mapping.

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 one product-note thread by conversation_id.' The phrase 'Does not list other threads' scopes it against listing siblings like get_thread/search_messages, though it doesn't name the alternative directly.

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 usage (fetch a single product-note thread when you have its conversation_id) and notes the 'No account required' precondition, but gives no explicit when-to-use/when-not guidance and does not name a sibling to use for other cases.

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

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

Annotations already cover read-only, idempotent, and non-destructive semantics, so the bar is lower. The description still adds genuinely non-structured context: the link is short-lived (expires), it requires a Business plan, and it requires the recordings.read permission grant. That is meaningful operational disclosure 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 compact sentences, with the artifact (streaming link) front-loaded and the constraints in the second sentence. 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?

With one trivial parameter and no output schema, the description needn't explain return values, and it does state what is produced plus the plan and permission gates. Minor gaps remain: it does not say how short-lived the link is or what error surfaces when the plan or grant is missing, but nothing essential to correct invocation is absent.

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

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

Schema description coverage is 0% for the single call_id parameter, so the description carries the burden but says nothing about it. The parameter is self-evident (the ID of the call whose recording is wanted), which is why this is not below 3, but no format or source of the ID is given.

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 resource and outcome: a short-lived streaming link for a recorded call, which is a distinct artifact from get_call or get_transcript. It is clear and specific, though it never names the adjacent siblings (get_transcript, get_call, list_voicemails) to disambiguate which one an agent should reach for.

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 real eligibility condition (Business plan only, plus the recordings.read grant), which is more than implied usage and useful for avoiding failed calls. However, it offers no guidance on when to use this versus get_call or get_transcript, so alternative selection 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 readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond that: result ordering ('oldest first') and the existence of paging. It stops short of describing pagination termination or return shape, so it is 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?

A single sentence, front-loaded with the resource and ordering, with the paging mechanism appended. No filler or redundancy; every clause carries 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 tool with annotations covering safety and no output schema, the description supplies the ordering guarantee and the paging parameter's format. What remains missing is minor: whether conversation_id is required and how paging terminates.

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 only 33% (only 'limit' is documented), so the description must compensate. It does add the missing format detail for 'before' (ISO 8601), which is real value, but says nothing about 'conversation_id' semantics or the limit's max of 50, leaving the coverage gap only partially filled.

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

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

States the resource precisely (messages in one thread) and its scope (single thread, not global search), which distinguishes it from search_messages. The verb is only implied ('Messages in one thread' rather than 'Retrieve/List'), but the operation is unambiguous.

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

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

The phrase 'one thread' implies this is the tool for thread-scoped retrieval versus the sibling search_messages, but there is no explicit when-to-use statement, no mention of prerequisites, and no named alternative. 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 cover the safety profile (readOnly, idempotent, non-destructive), and the description adds meaningful return-state behavior: in_progress while a speak call is ongoing and no_transcript only after the call ends with no stored text. That is useful context beyond the annotations, though it does not describe the transcript format or 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?

Three short sentences with no filler, and the core distinction (stored transcript only) is front-loaded before the edge-case statuses. Every sentence adds information an 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 simple read tool with no output schema and rich safety annotations, the description covers the important behavioral states (in_progress, no_transcript) and the scope limitation. It is only incomplete on the call_id parameter's origin and format, which is a modest 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 single call_id parameter has 0% schema description coverage, so the description carries the burden of explaining it. The phrase 'a call that already has one' only faintly implies that call_id must reference a completed call with a stored transcript; it gives no format, source, or example, leaving the parameter effectively undocumented.

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 identifies the exact resource ('stored transcript text') and scopes it to a call that already has one. The line 'Does not start a new transcription' explicitly separates it from the sibling request_transcript, so an agent can distinguish the two without opening either 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 when-not condition ('Does not start a new transcription') and describes the edge-case statuses that tell the agent whether a transcript is available. It does not name the alternative tool (request_transcript) explicitly, so it stops short of fully explicit routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safety profile is covered structurally. The description adds the seat-vs-account scope distinction and flags that whole-account access is a Business capability, but says nothing about auth requirements, rate limits, or return shape beyond the metric names.

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: the metric list and scope are front-loaded, then the parameter rule follows. 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?

There is no output schema, and the description does name the data returned (data balance, call minutes), which covers the main gap. Combined with annotations covering safety and the schema covering 'days', this is nearly complete; only auth/tier gating detail is thin.

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 only 50%: 'days' is documented in the schema, but 'company' is bare. The description compensates by explaining exactly what company=true does (whole-account scope, Business tier), which is meaning the schema alone does not provide.

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 the specific resource ('eSIM data balance and call minutes') and the scope ('already on this seat'), which distinguishes it from account-wide tools like get_account_balance. The verb itself is only implied by the tool name, and no sibling is named, 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?

It gives one conditional usage rule ('Pass company=true for the whole account (Business)'), which tells the agent how to widen scope. It does not say when to prefer get_usage over get_account_balance or other read tools, so guidance is implied rather than explicit.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the response includes a transcript, and include_audio yields a 'short-lived audio link' gated to 'Pro plan and above' – useful constraints an agent would otherwise not know.

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 action and the optional audio behavior second. No wasted words.

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

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

No output schema exists, but the description states what is returned (the voicemail plus its transcript, optionally an audio link). For a low-complexity two-parameter read tool this is nearly complete; only call_id provenance is 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 0%, so the description must carry the load. It explains include_audio well (short-lived audio link, plan-gated), but call_id is only implied ('by call_id') with no clarification of its format or source. Partial compensation for the coverage gap.

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

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

States a specific verb (get) and resource (a single voicemail) and its scope ('by call_id with its transcript'). This clearly distinguishes it from the sibling list_voicemails, though it doesn't explicitly name that alternative.

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. It never says when to prefer this over get_recording, get_transcript, or get_call, nor what call_id source (e.g., search_calls) should feed it. Usage must be inferred from the name and required param 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 the write/external profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false). The description adds real value beyond that: it sends an email (external side effect), the calling grant already permits it, and plan-based seat limits apply. It stops short of explaining duplicate-invite or error 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 core action and followed by the two constraints that matter. No filler, though the 'grant already allows this' clause is slightly terse and ambiguous.

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, no-output-schema tool, the description covers the action, the external effect, the permission context, and the plan limit. Missing only edge-case behavior (duplicate invites, failure modes), which is minor 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?

With schema description coverage at 0% and a single required 'email' parameter, the description must carry the burden; 'Email an invitation' does establish that the parameter is a target email address, but adds no format or validation guidance. Marginal compensation for the coverage gap.

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

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

States a specific verb (email an invitation) and resource (join this Widely account), so the action is unambiguous. It does not explicitly name or distinguish itself from siblings like add_number_channels or list_team, but the purpose is self-evident.

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 plan-level context ('Free and Pro stop at 8 people') and a permission note ('The grant already allows this'), which implies when the call will succeed. It does not state when to use this versus other member/team tools or what to do if the limit is reached.

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 the safety profile (readOnly, idempotent, non-destructive, closed-world). The description earns credit for disclosing that the result set includes numbers that remain inactive until identity registration completes, which is real behavioral context beyond the annotations, but it says nothing about ordering, filtering, or pagination.

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 resource and the scope edge case front-loaded. The final warning sentence is terse and serves a purpose as a hallucination guard, though it reads as slightly detached from the rest.

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 no output schema and full annotation coverage, the description covers what the list contains and the inactive-number edge case. It is adequate, though slightly more on result scope or relationship to search_numbers would close the remaining 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 there is no parameter semantics burden and the baseline is 4. The description correctly adds nothing that would be redundant with an empty schema.

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

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

The description identifies the resource (this account's phone numbers) and adds a distinguishing scope detail: inactive numbers pending identity registration. However, the verb 'list' is only implied by the noun phrase rather than stated, and it doesn't explicitly differentiate itself from siblings like search_numbers or list_identities.

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 search_numbers or list_identities, no prerequisites, and no exclusions. 'Do not invent a number' is a hallucination guard rather than usage direction about tool selection.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety bar is met. The description adds genuinely new behavioral context: the result set is seat-scoped and each entry carries its supplying provider and capabilities, which is useful for a tool with 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?

Two sentences, no filler: the returned content first, the call-first directive second. The enumeration of resource types is load-bearing rather than padding.

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-required-param read-only list tool with no output schema, the description covers what comes back and when to call it. It could still clarify whether results span multiple seats or how shared numbers appear, but nothing essential 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 coverage is 100% and the single optional parameter (include_shared) is documented in the schema, so the baseline of 3 applies. The description adds nothing about when to set include_shared or what shared numbers mean.

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 the concrete resources it returns (phone numbers, caller IDs, SIMs, PBX extensions, eSIMs) scoped to 'this Widely seat', plus the enrichment (provider, capabilities). That is far more specific than a bare 'list identities', though it does not explicitly separate itself from near-siblings such as list_did_numbers or search_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?

'Call this first to learn which identities the user has' gives a clear sequencing directive for when to reach for this tool. It stops short of naming alternatives or stating exclusions, so it is context without routing.

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 a safe, idempotent read in a closed world, so the safety profile is covered. The description adds real behavioral context beyond the annotations: results are 'masked', and it explicitly 'never returns a processor id', which tells the agent what data is deliberately withheld. This is meaningful disclosure for a tool with 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?

Two short, front-loaded sentences with zero filler. The return shape comes first and the exclusion constraint follows, both earning 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?

With no output schema and no parameters, the description has to convey what is returned, and it does: masked cards/bank methods with brand, last4, and default flags, plus the processor-id exclusion. Annotations carry the safety profile. It is nearly complete, only missing any hint of ordering or scoping of the list.

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 of 4 applies. The description does not need to compensate for any missing 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 names a specific resource (saved cards and bank methods) and enumerates the returned fields (brand, last4, default), so an agent knows exactly what this returns. The verb is only implied by the name 'list_payment_methods', and no sibling (e.g. topup_with_saved_method) is named for differentiation. Clear purpose, but lacks sibling routing.

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 prerequisites, and no mention of alternatives. Sibling topup_with_saved_method clearly relates to saved methods, yet the description does not explain the relationship or when to reach for this list versus that one.

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 nothing on top — no mention of pagination, result size, scope of 'this account', or what a PBX/shared number actually is.

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 fragments, one of which ('Business.') is pure noise that occupies space without informing. Brevity here reflects under-specification rather than efficient structure.

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

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

For a simple parameterless list tool with no output schema, the description should at minimum state that it returns the account's shared numbers and phone menus. Instead it repeats the title, leaving an agent unsure of the return shape and the distinction from sibling list_* 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. No parameter-level information is missing.

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 text 'Shared numbers and phone menus on this account' is a restatement of the title and never states a verb — it does not say it lists or returns anything. It also fails to distinguish itself from close siblings such as list_phone_system or list_did_numbers, which an agent must choose between.

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 prerequisites, and no mention of alternatives. The dangling fragment 'Business.' conveys nothing actionable and does not hint at the scenario that selects this tool over list_phone_system.

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 a domain behavior ('a queue rings only members who are signed in and available'), which is useful context but describes queue semantics rather than this tool's own 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 compact sentences with no filler, front-loaded with the covered categories. The noun-list style is terse and slightly fragmentary, but every clause carries 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 must carry the load of conveying what comes back. It enumerates the covered categories, which helps, but does not indicate the return shape or structure, leaving the agent to guess at the response 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 tool takes zero parameters, so the baseline is 4; there is nothing for the description to clarify, and schema coverage is nominal at 100% with an empty property set.

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 enumerates the resources the phone system comprises (numbers/answerers, receptionists, menus, queues, hours), which hints at what the tool surfaces, but it never states an explicit verb like 'returns' or 'lists the configuration'. It also fails to distinguish it from overlapping siblings such as list_did_numbers and list_pbx.

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 and no mention of alternatives, even though siblings like list_did_numbers and list_pbx cover subsets of the same domain. The agent is left to infer when this broad view is preferable to the narrower list 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 readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered structurally. The description adds genuinely non-structured context: no authentication is required, and it explicitly reassures that no plan state is mutated. It doesn't cover rate limits or response shape, but that is minor here.

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 terse fragments with no filler, and the most decision-relevant fact (what prices are returned) is front-loaded. Slightly clipped telegraphic style costs it a point versus a fully formed but still lean 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 zero-required-parameter, read-only listing tool with full schema coverage and no output schema, the description covers the data returned, the access requirement, and the non-mutating guarantee. It could note the price period/format expectations more explicitly, but nothing essential 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 currency parameter is fully documented in the schema (allowed values plus default EUR). The description adds no currency syntax, formatting, or default behavior beyond what the schema already provides, 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 states the resource (Free, Pro, and Business plan prices) and the nature of the data (monthly list prices), which is more specific than the title 'List plans'. It also implicitly separates itself from the mutation sibling upgrade_plan by saying it does not change the plan, though it never names that 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?

'No sign-in' and 'Does not change the plan' give usable context about prerequisites and scope, implying this is a safe lookup rather than a modification. However, it never explicitly says when to reach for this versus upgrade_plan or quote_* pricing tools, leaving selection 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=true, idempotentHint=true, destructiveHint=false and a closed-world scope, so the safety profile is fully covered. The description adds one genuinely useful behavioral detail — that pending email invites are included alongside active people — but says nothing about ordering, pagination, or result 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?

It is maximally short and front-loaded with zero filler, which is good, but it is a sentence fragment rather than a complete specification, leaving it under-described for the amount of budget available.

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 listing tool with full annotation coverage and no output schema, the description conveys the essential content of the result. It is adequate, though a brief mention of team member vs invite fields would make it complete.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify and the baseline of 4 applies. No parameter-level semantics are needed or missing.

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 name and title supply the verb ('list') and resource ('team'), but the description itself is a bare noun phrase with no verb. It does add scoping value by specifying that the result includes both people on the account and pending email invites, which distinguishes it from list_identities and search_contacts, but the purpose is only implied 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 when-to-use or when-not-to-use guidance and no named alternative. An agent must infer that this is the roster-listing call versus list_identities or invite_member purely from the noun phrase.

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 value by disclosing the returned content ('transcript text when available'), but says nothing about pagination, ordering, or output caps beyond 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?

A single well-formed sentence that front-loads the resource and scope and then lists the payload. No filler, though it is terse enough that a little more routing guidance could have been added without bloat.

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 small, zero-required-parameter read tool with a 100%-documented schema and full safety annotations, the description covers what the agent needs. With no output schema, the inline field list (caller, time, duration, transcript) usefully substitutes, though it omits result ordering.

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% – both 'days' (default 30) and 'limit' are fully documented in the schema with bounds. The description adds no parameter meaning beyond that, 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 resource (voicemails), scope (on this seat), and recency ('Recent'), and even previews the returned fields. It is clearly distinguishable from the singular sibling get_voicemail, though it does not name it 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?

Usage is only implied: 'Recent' plus the schema default of 30 days tells the agent this is a browsing tool, but there is no explicit guidance on when to choose this over get_voicemail or search_calls, nor any stated prerequisites or exclusions.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds domain constraints (never quote call/SMS content, never promise a refund, use the customer label not a raw code), which is useful beyond the annotations but says nothing about return shape, ordering, or pagination.

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?

Short and front-loaded: the core content list leads, followed by three terse prohibitions. Every sentence carries weight, though the prohibitions are policy rather than tool usage.

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 read-only list tool with no output schema and 0% parameter documentation leaves return format and paging behavior unexplained. The description covers domain policy but omits the operational detail an agent needs to page through wallet activity correctly.

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

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

Schema description coverage is 0% and the description does not mention limit or offset at all, so the pagination parameters are undocumented in both places. Standard names help slightly, but the description fails to compensate for a total coverage gap.

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

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

States a specific resource ('Wallet ledger') and enumerates its contents (top-ups, product debits, holds), so an agent knows exactly what is returned. It does not explicitly distinguish itself from the close sibling list_wallet_refunds, which keeps it 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 guidance present is about how to phrase answers to a customer (use customer labels, don't promise refunds), not about when to call this tool or how it differs from refund_wallet_topup or list_wallet_refunds. No preconditions or alternative-selection rules 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description usefully adds the eligibility criteria that define the result set, but says nothing about return shape or ordering, and its second sentence is an odd conversational instruction rather than a behavioral trait of the tool itself.

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 with the eligibility filter front-loaded and no wasted words. The second sentence is a slightly awkward non-sequitur about what to tell the user, but it is short and does carry a policy 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?

With no parameters and no output schema, the description carries the burden of explaining what comes back, and it does so by enumerating the eligibility conditions that define the list. Only minor gaps remain (result ordering/size, explicit pointer to refund_wallet_topup as the follow-up 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No parameter-level confusion is introduced.

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 resource (first-eSIM wallet top-ups eligible for refund to card) and defines the eligibility predicate (never installed, inside the window), which is enough to separate it from list_wallet_activity and refund_wallet_topup. The verb is only implied through the tool name rather than stated, 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 sentence 'Before offering one, say the balance can still make Widely calls over another SIM or any Wi-Fi' implies this is a discovery step that precedes refund_wallet_topup, but it frames that as a conversational policy rather than stating when to call this tool versus the alternatives. Usage is inferable but not explicit.

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

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

Annotations already declare readOnly=false, destructive=false, openWorld=true and a non-idempotent hint. The description adds meaningful context beyond them: per-GB billing with no data package, that permissions are already granted, that provisioning is deferred, and that an idempotency key neutralizes retry risk. It stops short of stating what account state changes or what the immediate 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?

Short, front-loaded with the purpose, and every sentence carries a distinct fact (billing model, permission state, install timing, retry safety). Some fragments ("The grant already allows this") are terse to the point of being cryptic, but there is no filler.

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

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

For a 2-parameter mutation tool with no output schema, the description covers the important consequences (cost model, deferred install, retry semantics) but says nothing about what is returned or how to obtain the resulting profile, leaving the agent to discover that elsewhere.

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

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

Schema coverage is 0%, so the description must carry the parameters, and it does well for idempotency_key (retry safety). country is left completely unexplained beyond its name, and it is the only required field, so the compensation is partial.

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

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

States a specific verb and resource ("Create an eSIM profile"), which clearly separates it from siblings like quote_esim, esim_install_steps, and get_esim_connection_check. It does not name an alternative explicitly, but the resource 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?

It gives one concrete usage rule (pass idempotency_key so retries don't double-order) and a timing hint ("Install happens later"), which implicitly points toward esim_install_steps. However, it never says when to call this versus quote_esim first, nor any prerequisites such as needing a payment method or available balance.

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 important operational context beyond that: no sign-in is required, returned documents should be quoted, and the agent must not state that the port was submitted.

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 and front-loaded, with each sentence providing a distinct instruction. The first sentence is somewhat redundant with the title, but the overall brevity avoids waste.

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

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

For a no-parameter, read-only tool, the description covers key behavioral constraints and implies returned documents exist. However, it does not clarify what those documents contain or how this tool relates to siblings like quote_port, start_port, and submit_port, leaving some contextual gaps.

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

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

The tool has zero parameters, so the baseline score is 4. There is no parameter information for the description to add or omit, and the empty schema is self-explanatory.

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

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

The description opens with 'What a number port needs,' which essentially restates the tool name and title rather than specifying a verb and resource clearly. It doesn't distinguish itself from siblings such as quote_port, get_port, start_port, or submit_port beyond the vague notion of requirements.

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

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

No guidance is given about when to use this tool versus alternatives like quote_port, get_port, or submit_port. The instructions are behavioral constraints, not selection criteria, leaving the agent to infer the appropriate context.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, not open-world), so the bar is lower. The description nonetheless adds two real behavioral facts not in the annotations: no authentication is required, and the call is not actually placed, so the agent knows this is a side-effect-free quote.

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 core purpose, then two tightly scoped clarifying constraints. No filler.

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

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

For a 4-parameter, zero-required read-only tool with no output schema, the definition covers purpose and side-effect status but leaves number_type undocumented and gives no hint of what a quote response contains (price, currency, validity). Adequate but with visible 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 coverage is 50%: currency and destination are documented in the schema, while country and number_type are bare. The description maps loosely onto destination/country but adds no format, units, or accepted-value detail. Baseline 3 applies given the schema does half 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?

States a specific verb+resource: returns a rate-checker price for a call, with the scope clarified as 'to a number or country'. It does not, however, distinguish itself from the sibling check_call_rate, which sounds like the same capability.

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 sign-in' and 'Does not place the call' imply a pre-purchase, read-only pricing lookup, which is useful implied guidance. But there is no explicit when-to-use statement and no routing versus check_call_rate or quote_number.

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 (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lowered. The description still adds genuinely useful behavior: 'No sign-in' (no authentication needed), and the billing granularity 'billed in 0.1 GiB steps' with the gb result framed as an 'estimate' not a final charge. It does not say whether the quote expires or how currency conversion is handled, so it is 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?

Four short clauses, front-loaded with the core purpose ('pay as you go price per GB') before the qualifiers. Zero filler, though the telegraphic fragments ('There is no data package.') read as notes rather than prose and could be marginally clearer.

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 carries the burden of explaining the return, and it does so loosely — an estimated price resulting from the gb input, billed in 0.1 GiB steps. Combined with annotations covering safety and the schema covering auth-free input, an agent has enough to invoke it correctly, though the exact response shape is only implied.

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 67% (gb and currency are documented; country is not, though its meaning is obvious). The description compensates by adding semantics the schema lacks: gb is optional and produces an estimate rounded/billed in 0.1 GiB increments, which matters for interpreting the result. Currency defaulting is left to the schema, which already documents it.

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

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

The description names a specific verb+resource: a rate-checker that returns pay-as-you-go price per GB for eSIM data. It distinguishes itself from package-based siblings by stating 'There is no data package.' It does not explicitly contrast with quote_call, quote_number, quote_port or get_data_rate, but the resource 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 rather than stated: the 'pay as you go ... no data package' framing tells the agent this is for ad-hoc rate checks, and 'No sign-in' implies no auth prerequisite. However, it never names an alternative (e.g. order_esim for actual purchase, get_data_rate for rate lookup) or states when this quote is the right call versus those siblings.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description still adds real value beyond that: it discloses the no-authentication requirement and confirms the tool is non-mutating ('Does not buy'), which the annotations alone don't convey in plain terms.

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, front-loaded sentences with zero filler: what it returns, the auth condition, and the non-purchase guarantee. 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?

With no output schema, the description usefully names what comes back (monthly price, calls-included flag) and the no-sign-in condition. It falls short on the low-coverage inputs — country and number_type semantics are left unexplained for a tool whose whole job is per-country pricing.

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 only 33%: currency has a description but country (required) and number_type are bare strings with no enum or format hints. The description adds no parameter meaning at all, so the required country field and the number_type options remain undefined for the agent.

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

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

States a specific verb (quote/rate-check) and resource (a number), plus what the result covers: monthly price and whether calls are included. It also explicitly separates itself from buy_number with 'Does not buy' and from the other quote_* siblings by naming '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?

'Does not buy' implies this is the pre-purchase check and 'No sign-in' signals it can be called without auth, which is useful routing context. However, it never explicitly says when to prefer this over quote_call/quote_esim or how it relates to list_did_numbers/search_numbers.

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 readOnly, idempotent, and non-destructive, so the bar is lower. The description still adds auth context ('No sign-in') and reinforces the no-side-effect nature ('Does not start the port'), plus a timing note ('The move is not instant'). It does not explain rate limits or the shape of the quote, but the additions are genuine value 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?

Four short clauses, purpose front-loaded, no filler. 'The move is not instant' is a little ambiguous (the port vs. the quote) but earns its place as a timing caveat.

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 should say what the quote returns (price, currency, validity), but it does not. Combined with 25% parameter coverage and zero required parameters, key information for calling the tool correctly 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 only 25% — just 'currency' is documented — and the description adds no meaning for number, country, or number_type. With three undocumented parameters and no compensation in the description, an agent cannot tell what format 'number' or 'country' expect. This falls short of 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?

States a specific verb (rate-check/quote) and resource (moving an existing number to Widely), and explicitly distinguishes itself from the port-execution siblings with 'Does not start the port.' The phrasing 'Rate-checker price' is slightly jargon-y, but an agent can tell it apart from start_port and submit_port.

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 the port' and 'No sign-in' give implied usage context (a no-auth, non-executing pre-check), but the description never names the alternative to use for actually initiating a port, nor when to prefer this over quote_number, quote_call, or port_requirements. 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 cover readOnly/idempotent/non-destructive, and the description adds genuinely new context: the access requirement ('any connected account') and the deterministic ordering ('oldest first'). It does not mention pagination or result shape, but for a read-only tool that is a minor gap.

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

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

Three short sentences that front-load the resource, then scope, then access. Every clause carries information 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?

For a simple read-only list tool with full schema coverage and no output schema, the description covers resource, ordering, access and scope. Only pagination behavior is left unstated, which is a minor 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 coverage is 100% for the single 'limit' parameter, so the schema documents it fully. The description adds only an ordering detail ('oldest first') that does not enrich the limit semantics themselves, 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 resource (the user's Support chat messages) with an explicit ordering rule (oldest first) and a scoping exclusion ('Does not read any other chat'). This separates it from transcript/thread/search tools by scope, though it never names a specific sibling alternative.

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?

'Any connected account can call this' is an auth note rather than a when-to-use rule, and the exclusion of other chats only implicitly routes the agent elsewhere. No explicit conditions or named alternatives, so usage remains inferred.

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=true, so the description only needs to add context. It adds the user-communication requirement but omits the meaningful risk implied by idempotentHint=false (a second call likely issues a second refund) and never states what happens when the top-up is ineligible. The phrase 'The grant already allows this' is vague and reads like an unexplained authorization aside.

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

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

Three sentences, purpose front-loaded, no filler. 'The grant already allows this' is the one sentence that does not clearly earn its place because its referent is undefined.

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 mutation with no output schema, the description covers purpose, parameter source and a user-facing prerequisite. It leaves eligibility criteria, non-idempotent double-refund risk, and post-call outcome unexplained, which matters for a money-moving tool.

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

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

With 0% schema description coverage, the description carries the burden and does tell the agent where the value comes from: 'Pass transaction_id from list_wallet_refunds.' That provenance is real meaning beyond the bare string type, though it gives no format or validation detail.

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

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

States a specific verb and resource with scope qualifiers ('Refund an eligible first-eSIM wallet top-up to the card'), which narrows it well beyond the generic top-up siblings like topup_with_saved_method. It does not name a sibling alternative explicitly, 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?

Gives a concrete pre-call action ('tell the user the balance can still make Widely calls over another SIM or any Wi-Fi') and routes the agent to list_wallet_refunds for the required identifier. It never defines what makes a top-up 'eligible' or says when not to call it, so the when-not side is missing.

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 cover the safety profile (not read-only, open-world, non-idempotent, non-destructive), and the description adds real context beyond them: the ring-user-first sequence, the fallback that the destination is not called if no phone answers, that the call appears as outgoing, that the assistant is absent, and that no in-app confirmation is requested. It still omits cost/rate implications and failure behavior beyond the no-answer case, which the sibling set (check_call_rate, quote_call) suggests matter.

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 core flow is front-loaded in the first two sentences and every sentence carries a distinct fact (outgoing flag, assistant absence, plan requirement, no confirmation, fallback). The telegraphic fragments are efficient, though slightly staccato for a definition of this length.

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

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

For a call-initiation tool with no output schema and no required parameters, the description covers the flow, prerequisites, side effects, and one failure path adequately. It leaves gaps around what happens on partial failure, cost, and why destination is optional despite being the target 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 coverage is 100%, so both parameters are already documented in the schema; the baseline is 3. The description references the destination and the user's phones but adds no format, sourcing, or identity/grant detail 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 action (ring the user's phones, then bridge the destination into the same call) and gives a clear mental model of the two-leg flow. It distinguishes itself implicitly from quote_call/control_call/get_call by describing an initiation flow, but it never names a sibling or states what it is not, so differentiation is left to inference.

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

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

The only usage condition given is the 'Pro plan' prerequisite. There is no guidance on when to pick this over quote_call (pricing), control_call (managing an active call), or request_speak, and no exclusions are stated. An agent must guess the routing.

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

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

Beyond the annotations, it discloses genuinely useful traits: it returns immediately with a call_id, it does not request in-app confirmation, an empty transcript signals an in-progress call, and it describes the connect_user side effects. This is substantive context the annotations (openWorldHint, idempotentHint=false) do not provide.

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 purpose is front-loaded, but the body is choppy and fragmented ('Business.' / 'The user is not rung.') and repeats the no-confirmation idea twice ('Does not ask for confirmation in the app' and 'Do not ask the user'). Workflow steps are interleaved with parameter guidance rather than grouped.

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 four-parameter mutation with no output schema, the description does the important work of explaining that it returns a call_id immediately and how to retrieve results via get_call/get_transcript, which an agent would otherwise have to guess. The remaining gap is the undocumented destination and identity_id parameters.

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 only 50%: task and connect_user are documented in the schema, while destination and identity_id are bare strings. The description adds behavioral meaning for connect_user ('ask the person to hold, then ring the user's phones into the same call') but says nothing about the format or role of destination/identity_id, so it only partly compensates.

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 conveys that this initiates an outbound call where an AI assistant performs a task, but the opening 'Widely calls the number' is garbled and reads as a translation artifact. It never distinguishes itself from close siblings like request_call or control_call, so an agent must infer the difference.

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 useful post-call workflow (poll get_call until has_transcript is true, then read summary, then get_transcript for dialogue) and an explicit exclusion ('Do not ask the user'). However, it offers no guidance on when to pick this over the sibling request_call, which is the more pressing routing question.

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 is a non-read-only, non-idempotent, non-destructive write (readOnlyHint=false, idempotentHint=false), so the safety profile is covered. The description adds genuinely useful context beyond them - the Pro plan requirement, the permission note, and the 'no text yet' precondition - but omits whether the job is async, what it costs, or what it produces.

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?

Appropriately short and the main action is front-loaded, but the fragments 'Pro.' and 'The grant already allows this.' are telegraphic and read as internal shorthand rather than clear guidance, costing clarity without saving much space.

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 purpose, tier, and permission, which is reasonable for a one-parameter action tool with no output schema. However, with zero schema coverage on call_id and no statement of return behavior (synchronous result vs. queued job), an agent still lacks enough to invoke it confidently.

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% and the description never mentions call_id. An agent cannot tell from either source what identifier call_id expects (a call id from search_calls, get_call, or elsewhere) or its format, so the single parameter is effectively undocumented.

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+resource ('transcribe a recorded call') and adds a discriminating scope qualifier ('that has no text yet') that separates it from get_transcript, which retrieves an existing one. It does not name get_transcript explicitly, but the scope is clear enough to route correctly.

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 for when to use it: the call must be recorded and must not already have text. It also states two preconditions ('Pro', 'the grant already allows this'), but never names the alternative (get_transcript) for the case where a transcript already exists, so exclusions are left implicit.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world behavior, and the description adds genuinely new behavioral context: this tool initiates an asynchronous check whose result is retrieved by a separate tool using a request_id, plus a conditional retry path. It also guards against fabricating an APN, which is useful operational guidance 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?

Four short sentences, action-first, with the failure branch and the follow-up call placed after the primary instruction. The 'Do not invent an APN' line is terse and earns its place as a hallucination guard, though the flow could be ordered slightly more tightly.

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 a decent job of describing the async result flow and the no_install_yet outcome, but it never defines the inputs the agent must supply (sim_id, device_id) or what a successful result contains. Adequate for the happy path, incomplete for actually invoking the tool correctly.

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

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

Schema description coverage is 0% and the description never explains what sim_id or device_id mean, whether either is required (0 required), or how to obtain them. The only identifier it mentions, request_id, is not even a parameter of this tool, so it does not compensate for the coverage gap.

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

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

The description states a specific verb and resource — 'Ask this user's Widely app to check the eSIM' — and clarifies that this is the trigger step whose result is later fetched via get_esim_connection_check. It clearly separates the initiating tool from the retrieval sibling, though it does not distinguish itself from other eSIM tools such as esim_install_steps or order_esim.

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 real conditional guidance: if the result is no_install_yet, tell the user to install the Widely app and call this again, then call get_esim_connection_check with request_id. That is clear context for the main flow, but no explicit exclusions or comparison against the other eSIM-related siblings (quote_esim, esim_install_steps) is offered.

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 genuine behavioral context beyond that: results are collapsed to one row per call (legs merged) and the row signals transcript/recording availability. It stops short of noting that results are seat-scoped in time or capped by limit.

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: purpose and filters first, return shape second. No filler and nothing repeated from the schema or annotations.

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 usefully enumerates the returned fields (direction, duration, outcome, identity, transcript/recording presence), which is exactly what an agent needs to consume results. Remaining gaps are minor: paging behavior and the meaning of the limit cap are left to the schema.

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

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

Schema coverage is 70%, so most parameters are already documented, and the description only echoes four of the ten filters (date range, direction, contact, number). It says nothing about days, limit, the transcript query mode, line, missed_only, or the inclusive/exclusive since/until semantics, so it adds little 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 ('Find calls') scoped to 'this Widely seat', and the phrase 'one row per call (legs collapsed)' makes clear this is a list/search operation rather than the single-call sibling get_call. The four filter axes (date range, direction, contact name, number) further pin down what it does.

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

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

The description implies usage by listing filter dimensions but never states when to reach for this versus get_call, search_messages, or get_transcript, and gives no guidance on paging via limit or on the transcript-word 'query' mode. Usage 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 cover the safety profile (readOnly, idempotent, non-destructive, not open-world). The description adds two useful facts beyond them: results are scoped to the caller's own seat, and the response carries names plus numbers. It still says nothing about the limit parameter's behavior or result ordering.

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

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

Two short sentences, purpose first, downstream use 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 simple read-only lookup with no output schema, the description covers what it does, its scope, and the shape of the return. Only the unexplained limit/cap behavior keeps it from being fully complete.

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

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

Schema coverage is 0%, so the description must carry the load. "By name" usefully clarifies that the required query parameter is a name match rather than a generic string, but the limit parameter (1-25) is left entirely unexplained in both schema and description.

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

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

States a specific verb (find/search) and resource (saved contacts) with scope ("on this seat") and match key ("by name"). This implicitly separates it from siblings like search_numbers and search_calls, but it never names an alternative, 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?

"Returns names and numbers so other tools can be called by number" gives a real reason to use it (resolving a contact to a dialable number), which is more than nothing. However there is no statement of when not to use it or which sibling to prefer when the target isn't a saved contact.

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

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

Annotations already cover read-only/idempotent/non-destructive, so the bar is lower. The description adds real context beyond them: 'No sign-in' (no authentication required) and 'Does not quote a price' (a hard scope boundary). It stops short of saying how results are returned or how fresh they are.

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 scope before exclusions. Every clause carries information; nothing is padding.

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

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

For a read-only help lookup with full annotation coverage and no output schema, the description supplies scope, auth requirement, and the key exclusion. The remaining gap is input-format guidance for 'query', which is thin for a 0%-coverage parameter.

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% for the single required 'query' parameter, so the description carries the full burden. The phrase 'for a question' hints that the input is natural language rather than keywords, but there is no guidance on phrasing, length, or accepted topics.

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 concrete verb+resource scope: public product facts and in-app menu names. It immediately distinguishes itself from the pricing siblings it names (list_plans, quote_*), so an agent can route without opening a 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?

Explicitly excludes pricing and names five alternative tools to use for a price, which is strong when-not guidance. It does not, however, position itself against the other knowledge-style siblings (ask_support, read_support, get_product_note), leaving that comparison implicit.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds real behavioral value by disclosing the return shape (message text with sender and thread) and the exclusion of support/assistant threads — a filtering behavior no annotation conveys.

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 waste, and the primary capability is front-loaded ahead of the scope carve-out. 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 4-parameter read-only search with no output schema, the description covers sources, scope exclusions, and return contents. It stops short of noting the default 30-day window or result limits, which are only in the schema.

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

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

Schema coverage is 75% and the description adds no parameter detail beyond it — it does not explain how query, days, or limit interact, nor what conversation_id scopes. Baseline 3 applies when the schema documents most of the surface.

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 (search) and resource (messages), names the three channel sources (Widely, SMS, WhatsApp), and immediately bounds scope by excluding support and assistant threads. An agent can distinguish this from search_calls, search_contacts, and get_thread from the description alone.

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

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

The exclusion of support and assistant threads gives a clear when-not boundary, which is genuinely useful context. However, it never names an alternative for keyword+date retrieval (e.g. get_thread for a single conversation, read_support for support content), so routing on the positive side 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 readOnly/idempotent/non-destructive, so the bar is lower. The description adds genuinely new context: the monthly price is the rate-checker list price, no sign-in is required, and the call does not purchase. These pricing and auth disclosures go beyond what annotations convey.

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

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

Four terse sentences with the resource and scope front-loaded, each contributing a distinct fact (scope, pricing semantics, auth, non-mutating). 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?

With no output schema, the description still conveys what is returned (available numbers) plus pricing and safety context, leaving only return format/pagination unaddressed. Adequate for a simple search 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 coverage is 75% and country, currency, and number_type all carry descriptions, so the schema does the heavy lifting. The description only restates that country is required and city optional, adding no format or syntax detail 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 resource (available phone numbers) scoped to a country and optional city, and the 'Does not buy' clause implicitly separates it from buy_number. The purpose reads clearly without opening the schema, though it never names the sibling it is distinguishing itself from.

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 buy' provides a negative boundary that keeps an agent off the purchase path, and 'No sign-in' signals it is usable pre-auth. However, no positive when-to-use guidance or explicit alternative (e.g. buy_number, quote_number) is named, so routing 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, openWorldHint=true, idempotentHint=false, and destructiveHint=false, so the safety profile is covered structurally. The description adds the plan requirement, the grant/authorization note, and the immediate-send behavior ('The first call sends the message'), but that last clause is cryptic and arguably in tension with idempotentHint=false, and no delivery outcome or rate-limit behavior is 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?

It is short and front-loads the core action, which is good. But the remaining telegraphic fragments ('Pro plan.', 'The grant already allows this.') are low-density and ambiguous rather than fully earning 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 non-idempotent, open-world send operation with no output schema, an agent would benefit from knowing what a successful call returns (message id, delivery status) and whether a confirmation step exists. The description only hints at immediate send, leaving these gaps 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%, so 'to', 'text', and 'identity_id' are already fully documented in the schema. The description adds no syntax, format, or constraint detail beyond that, 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 ('Send an SMS or Widely message'), which an agent can act on directly. It does not, however, name or differentiate itself from siblings like request_speak, search_messages, or request_call, so routing relies on the reader's own inference.

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

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

'Pro plan' and 'The grant already allows this' convey availability and authorization prerequisites, which is genuine context. But there is no explicit when-to-use, when-not-to-use, or alternative (e.g. request_speak for voice), leaving usage largely 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?

The annotations already declare this as a non-read-only, non-destructive, non-idempotent mutation, so the safety profile is covered. The description adds one useful piece of context beyond them - that the call is authorized by the existing grant - but says nothing about reversibility, side effects, or whether omitted fields are preserved.

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 the fields it affects, with zero filler. It is slightly under-specified rather than bloated.

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 four-parameter mutation tool with no output schema and no parameter documentation in either the schema or the description. The description should at minimum explain payment_method_id and the interaction between enabled, threshold, and amount, none of which is covered.

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

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

Schema description coverage is 0%, so the description carries the full burden. It names only three concepts (on/off, threshold, amount) and leaves payment_method_id completely unexplained, including whether it is required when enabling top-up.

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 ('turn on/off') and resource (auto top-up) and enumerates the settable fields (threshold, amount). It implicitly distinguishes itself from the read-side sibling get_auto_topup, though it never names it.

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 versus get_auto_topup, nor any stated precondition beyond 'the grant already allows this'. The agent must infer the context 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 the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false), so the bar is lower. The description does add one genuinely useful behavioral fact beyond the annotations: 'The grant already allows this', which tells the agent no extra authorization step is needed. It says nothing, though, about how a partial 'types' map is merged, whether omitted toggles are preserved, or how idempotentHint=false manifests for a set-style 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?

Two short, front-loaded sentences with no padding, and the primary action leads. The second sentence is terse to the point of being slightly cryptic but still earns its place as an authorization note.

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

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

For a mutation tool with a nested-object parameter, zero required params, and no output schema, the description omits critical calling detail: which notification type keys are valid, what unit the threshold uses, and how partial updates behave. An agent could invoke it but would be guessing at the payload shape.

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 50%: 'types' is documented as a partial map, but low_balance_threshold has no schema description. The description names both parameters in prose ('notification toggles', 'low-balance threshold'), which at least confirms the mapping, but adds no units, currency, or valid notification-type keys for the nested object.

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

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

States a specific verb ('Update') plus both resources it mutates: notification toggles and the low-balance threshold. It does not, however, distinguish itself from the sibling read counterpart get_notification_preferences, so the agent must infer the read/write split from names 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 when-to-use guidance, no prerequisites beyond the passing remark about the grant, and no reference to alternatives such as get_notification_preferences. Usage is only inferable from the tool name.

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 the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false). The description adds genuinely non-structured context: the Business plan gate for certain targets and the note that the grant already permits the action, which addresses permissions. It could still say whether existing routing is overwritten, but it clearly exceeds the annotation baseline.

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 tight sentences lead with the core action and then layer constraints; there is no filler. The telegraphic style is slightly terse but every clause carries 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 mutation tool with no output schema and 8 zero-documented parameters, the description supplies plan gating and auth context but leaves the identifier parameters and overwrite semantics unaddressed. Adequate but not complete for the tool's complexity.

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

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

Schema description coverage is 0% across 8 parameters with none required. The description names the target values and explains closed_target, but number, number_id, target_id, auto_record, time_group_id, and closed_target_id remain undocumented anywhere. It compensates for only a fraction of the gap.

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

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

The description states a specific verb ("Point a number at") and enumerates the destination resources (ring_me, personal_assistant, receptionist, menu, queue, voicemail, busy, decline), so the agent understands the routing operation clearly. It does not, however, distinguish itself from closely related siblings like update_forwarding or uk_divert_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?

It notes that closed_target applies against opening hours and that shared line/receptionist/menu/queue destinations require the Business plan, which is useful conditional context. It stops short of saying when to prefer this tool over the forwarding/divert siblings, leaving alternatives 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, and idempotentHint=false, so the mutation/non-destructive profile is covered. The description adds two useful facts beyond the schema: the port is asynchronous ('not instant') and authorization is already granted. It does not describe what happens on failure, what is returned, or any partial-state 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 with the action front-loaded. No filler, though the third sentence ('The port is not instant.') could be folded in while the missing parameter and sibling guidance is far more valuable.

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?

This is a mutating, non-idempotent tool with five undocumented parameters, no output schema, and no required-field information. The description covers only purpose, auth, and async timing, leaving the agent without enough to invoke it correctly relative to its true complexity.

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

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

All five parameters (number, country, numbers, number_type, current_carrier_name) have 0% schema description coverage, so the description carries the full burden and largely fails it. Only a vague allusion to 'an existing number' and 'the details in this chat' is given, with no mapping to number vs numbers, format, or which fields are required.

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

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

States a specific verb and resource: starting a port (moving an existing number to Widely). The action is easy to identify, but the description never distinguishes it from close siblings like quote_port, submit_port, port_requirements, or get_port, which all concern the same porting workflow.

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

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

The only contextual note is 'The grant already allows this,' which is an authorization reassurance rather than when-to-use guidance. There is no statement of when to call start_port versus quote_port (get a price first) or submit_port, leaving the agent to guess the ordering of the porting flow.

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

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

Adds real behavioral context beyond the annotations: it may charge the wallet when a fee applies (financial side effect), the operation is asynchronous ('not instant'), and the caller's grant already authorizes it. Annotations cover the mutation/idempotency profile, so this is a solid complement, though it says nothing about how to track the request's progress.

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, front-loaded sentences with no filler; the carrier action and cost effect come first. The middle sentence ('The grant already allows this') is slightly cryptic but still earns its place as an authorization note.

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

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

For a money-charging, non-idempotent mutation there is no output schema and the description omits the port_id source, how to check submission status, and how it relates to start_port/quote_port. Adequate but with clear gaps an agent would need to resolve elsewhere.

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 required parameter 'port_id' has 0% schema description coverage and the description never explains it — e.g. where the id comes from (get_port, start_port) or its format. With only one parameter and no coverage, the description should compensate and does not.

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: sending a port request to the carrier, with the wallet-charging side effect. However, it offers no differentiation from the sibling 'start_port' (or 'quote_port'/'port_requirements'), which an agent could easily confuse with this tool.

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

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

There is no explicit when-to-use guidance and no named alternative. With siblings like start_port, quote_port, and port_requirements in the same family, the description should route the agent but instead leaves the choice to inference. Only the timing note ('not instant') hints at context.

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

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

Annotations cover the safety profile (non-read-only, non-destructive, open-world, non-idempotent), and the description adds real value on top: no account required, reply_url push semantics, a returned conversation_id, and how to continue a thread. It does not say what happens on duplicate submissions or invalid reply_url, but the mutation's operational shape is well disclosed.

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?

Five short sentences, all front-loaded: what it does, auth posture, the reply_url mechanism, the return value, and the exclusion. No sentence is filler and the most important facts come first.

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-output-schema mutation with annotations present, the description is nearly complete: it covers auth, return value, threading, and a scope exclusion. The remaining gap is the semantics of the kind/title fields, which an agent would have to infer from the enum.

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 only 40%, so the description must compensate. It explains reply_url (https push target) and conversation_id (thread continuation) meaningfully, but says nothing about kind, text, or title beyond the enum already in the schema, leaving three parameters undocumented.

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+resource: submitting feedback (missing capability, complaint, use case) to Widely. It implicitly separates itself from the read-side sibling get_product_note, though it never names it directly.

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 explicit when-to-use ('missing capability, a complaint, or a use case') and one clear when-not ('A cost or setup question does not use this'), which routes the agent toward ask_support. It stops short of naming that alternative, so the routing is implied rather than explicit.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the mutation/safety profile is covered. The description adds real value on top by disclosing that the existing grant already authorizes the call and by defining the empty-string teardown path. It stops short of saying whether a repeat call replaces or merges the prior subscription.

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, each carrying distinct information, with the core action and the teardown behavior front-loaded. No filler.

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

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

For a two-parameter subscription tool with no output schema and annotations covering the safety profile, the description supplies everything needed to call it correctly. Only the replace-vs-merge behavior on repeated calls is 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 both parameters already document their omit/empty semantics and the enum event names, so the description largely restates the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb (set/subscribe) and resource (https webhook URL for this seat) and enumerates the exact event names involved. No sibling tool in the list deals with event subscriptions, so an agent can place it unambiguously.

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 clear conditional guidance for the two modes: pass events to select a subset, omit events to receive all, pass an empty webhook_url to stop. It does not name alternatives, but no sibling overlaps, so the missing exclusion is immaterial.

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, and openWorld=true, so the mutation/safety profile is covered. The description adds a permission note ('The grant already allows this'), which is useful but cryptic, and it does not disclose failure behavior, idempotency implications, or what result a charge produces.

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 tight sentences with the core action front-loaded ahead of the fallback-parameter rule. Minimal waste, though 'The grant already allows this' is vague enough to be borderline filler.

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

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

For a simple two-parameter payment tool whose annotations carry the safety profile, the description covers the essential flow (charge saved card, default payment method). The main gap is the undefined 'amount' semantics, but overall it is complete enough to invoke correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It explains payment_method_id's default-resolution behavior via list_payment_methods, but leaves 'amount' entirely undefined (no currency, units, or limits). Half the parameter semantics are covered, so it only partially compensates for the coverage gap.

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

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

States a specific verb and resource: 'Charge a saved card to top up this wallet.' This clearly distinguishes it from sibling wallet tools like refund_wallet_topup or set_auto_topup. It does not explicitly name an alternative, but the 'saved card' scope makes the operation unambiguous.

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

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

The description implies usage (topping up a wallet with an existing card) and gives one concrete instruction: omit payment_method_id to use the default. However, it never states when to prefer this over alternatives such as set_auto_topup or manual top-up flows, leaving the agent to infer the context.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description still adds real value beyond them: 'No sign-in' discloses that no authentication is needed, 'shared' signals a single canonical value for all users, and 'Do not invent another' guards against hallucinated substitutes.

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 fragments, all front-loaded, each earning its place: what is returned, the auth condition, and two output-handling rules. There is no filler or restatement of the title.

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 tool with no output schema, the description covers the essentials: what value is returned (destination plus dial code) and how the agent must handle it. It stops short of describing the exact return shape or whether the value can change, which is the only remaining gap.

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