Widely

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

Annotations cover idempotency and non-destructiveness, and the description adds real value on top: it discloses the mode-dependent behavior (summary returned when confirm is absent vs. acceptance recorded when true), the contents of the dry-run response, and the cross-tool gating requirement. The 'Safe to repeat' note reinforces rather than contradicts idempotentHint=true.

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

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

Front-loads purpose and the gating requirement, then walks the flow in sequence with no filler sentences. Slightly long compound sentences keep it from a 5, but every sentence 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?

There is no output schema, and the description compensates by describing what the non-confirm call returns (terms summary, full-terms link, prior acceptance status). For a one-parameter boolean tool this is fully self-contained.

Complex tools with many parameters or behaviors need more documentation. 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 parameter is already documented with the same intent ('true only after the user has agreed'). The description restates that semantics in flow context but adds no new syntax or format detail, so the baseline of 3 applies.

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

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

States a specific verb ('accept') and resource ('Errands terms') and immediately explains its role as a gate: 'needed before any AI call or errand can dial.' This distinguishes it from the many errand/call siblings without the agent needing to open 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?

Gives an explicit two-phase protocol: call without confirm to fetch the summary, show it to the user, then call again with confirm=true only after clear agreement. The precondition (must be accepted before AI calls/errands) is spelled out, leaving nothing 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, destructiveHint=false and idempotentHint=true; the description reinforces this with 'does not close or delete anything' and adds useful context the annotations cannot convey: no authentication is required and unused credit is refunded on closure. It stops short of describing response shape or limits, but for a static info tool that is minor.

Agents need to know what a tool does to the 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 plus the 'Information only' and 'does not close or delete anything' guardrails, all front-loaded. Every clause either defines the return content or prevents a misinvocation; 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?

With no parameters, no output schema, and a purely informational role, the description adequately covers what the agent gets back and what it must not expect. Return format (list vs prose) is not stated, 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.

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 schema and annotations carry the whole calling contract. Baseline 4 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 and the exact content returned: the ways to stop charges without closing the account, enumerated as cancel membership, stop renewing, remove a saved card. It also carves out what it does not do (closure/deletion) and routes that to Widely Support, which separates it from action-oriented siblings like cancel_call_task or list_payment_methods.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 clear usage frame ('Information only', 'No sign-in') and an explicit exclusion: account closure and deletion are handled by Widely Support, not by any tool. It does not name a specific sibling to use for the actual stop-charge actions, so an agent must infer which tool to call next, keeping it below 5.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, so the mutation profile is covered. The description adds genuine business context not in the structured fields: the two-channel baseline and the fact that single extra channels are no longer sold, which constrains the operation to keep-or-lower. However, it never says what happens to in-progress conversations when the count is reduced, which is the key destructive risk the annotation flags.

Agents need to know what a tool does to the 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 no filler. The final clause is a bit convoluted ('Single extra channels are no longer sold, so this keeps or lowers an existing count') but it carries the most decision-relevant 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?

A two-parameter mutation with annotations covering safety and no output schema, so the bar is moderate. The description still leaves open the two things an agent most needs: whether the count can be raised via this tool, and what service impact lowering it has on live calls.

Complex tools with many parameters or behaviors need more documentation. 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 partially does: 'The number includes 2' clarifies that channel_count is the resulting total (matching minimum 2), not an increment — an important disambiguation given the 'add_' name. number_id is not addressed at all, and no format or validation detail is offered.

Input schemas describe structure but not intent. Descriptions should explain 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: 'Sets how many simultaneous conversations a number can take.' An agent can tell this mutates a channel-count setting rather than buying a number or setting routing. It does not name siblings, and the verb 'Sets' sits awkwardly against the tool name 'add_number_channels', which sows a little doubt about whether the value is a total or an increment.

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

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

'Single extra channels are no longer sold, so this keeps or lowers an existing count' implies a when-to-use boundary (retain or reduce, not grow), but it is phrased obliquely and never names what to call instead for adding capacity (e.g., buy_number/order_service). 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?

Adds substantial context beyond annotations: the reply is asynchronous and human, the Support team is notified, and the user must call read_support afterward. The annotation profile already covers write/open-world/non-idempotent safety, and the description usefully explains the real-world consequence.

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

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

Four short sentences, front-loaded with the action and outcome, then the follow-up instruction and content guidance. Every sentence contributes operational information without repetition.

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

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

For a one-parameter, non-complex tool with no output schema, the description provides the essential action, side effect, async follow-up, permission note, and parameter intent. Nothing critical is missing for correct invocation.

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

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

Schema description coverage is 0%, so the description must carry the meaning of text. It does so by saying text should contain what is needed and what was already tried, which is useful content guidance beyond the bare string 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: writes a message into the user's Widely Support chat and notifies the Support team. It also distinguishes the follow-up path by naming read_support, so the agent can separate this from the reply-reading 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?

Explains the interaction flow clearly: send the question here, then use read_support for the human reply. It also guides what to put in text, though it does not explicitly compare against alternatives like search_help or send_message.

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

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

Annotations declare readOnlyHint=false and idempotentHint=false, and the description usefully adds that this spends real wallet balance and returns the charged price. It also explains the opt-in idempotency escape hatch, clarifying why the tool is flagged non-idempotent. It stops short of saying whether a failed or repeated purchase can be refunded/reversed or what happens on partial failure.

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

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

Three short sentences with zero filler: what it does, what it returns, and the idempotency caveat. The wallet-charge consequence is front-loaded.

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

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

For a money-spending mutation with no output schema, the description does name the return value (price charged), which is the key missing piece. It is not complete about parameter selection among the 7 zero-documented fields, but the critical behavioral facts for calling it safely are present.

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

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

Schema description coverage is 0% across 7 parameters, so the description carries the full burden — yet it explains only idempotency_key, and does so well. The six remaining parameters (sku_id, country, number_type, did_group_id, stock_did_id, includes_origin_calls) get no semantics at all, and the mutual exclusivity of the identifier fields is left entirely to guesswork.

Input schemas describe structure but not intent. Descriptions should explain 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 ('Purchases a phone number') plus the consequential side effect ('charges the wallet'), which separates it in spirit from the quote_number sibling. It never names quote_number or search_numbers, so the agent must infer the distinction rather than being told.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 / when-not-to-use guidance and no mention that quote_number should be called first to price the purchase or that search_numbers/list_did_numbers supplies the did_group_id/stock_did_id values. With 7 optional parameters and nothing required, the description also gives no hint about which identifier combination selects a purchase.

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

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

Annotations declare destructiveHint=true and idempotentHint=false, so the safety profile is already covered. The description adds real context the annotations do not: the meaning of each mode (graceful wraps up before hanging up vs immediate hang-up) and the edge case that a task which has not dialled is cancelled without a call. It stops short of stating what happens on a second cancel or an invalid task_id.

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

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

Three short sentences, no filler, with the core action and each mode's consequence front-loaded. Every sentence earns its place, including the non-dialled edge case.

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

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

With no output schema, return behaviour is not the description's responsibility, and annotations already cover the destructive/idempotency profile. What remains uncovered is minimal: error behaviour for an unknown or already-cancelled task, and whether graceful mode waits for completion.

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

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

Schema description coverage is 0%, so the description carries the burden — and it does for the non-obvious parameter, explaining both 'graceful' and 'immediate' enum values, which the schema lists without meaning. task_id itself is left undefined, but its semantics are self-evident from the tool name.

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

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

Opens with a specific verb+resource ('Stops an Errands task'), which cleanly separates it from the create/get/list/quote call-task siblings. It does not name a sibling for disambiguation, but the action is unambiguous.

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

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

Usage is implied by the verb — an agent can infer this is the way to abort a running task — but there is no explicit when-to-use vs when-not framing, no statement about prerequisites, and no pointer to get_call_task/list_call_tasks for checking status 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 destructiveHint=true, readOnlyHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the eligibility constraint ('Business plan') and scope ('in-progress conversation'), but does not disclose side effects such as what hangup terminates or that transfer is irreversible.

Agents need to know what a tool does to the 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 front-loaded, no wasted wording. The 'Business plan.' fragment is abrupt but still carries eligibility information 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 destructive control tool with no output schema, the description covers the action set and plan requirement, and annotations cover safety. The key gap is the undocumented destination parameter and the lack of any note on call state transitions or failure 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 carries the full burden. It enumerates the action values (hold/resume/hangup/transfer) which maps to the enum, but never explains call_id or the destination parameter, nor that destination is effectively 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?

The description names a clear verb set (holds, resumes, hangs up, transfers) applied to a specific resource (an in-progress conversation on this seat). This makes it easy to distinguish from read siblings like get_call and search_calls, though it never explicitly contrasts 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?

Usage context is only implied: the tool operates on an already 'in-progress' call and is gated by 'Business plan'. There is no explicit when-to-use vs alternatives or exclusion guidance, so the agent must infer that request_call/get_call are the non-control 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=false, openWorld=true, idempotent=false, and destructive=false, and the description adds substantial operational context: price from the rate sheet, schedule_at waiting behavior, no global calling-hours window, refusal rules, terms/plan prerequisites, and aggregated validation errors. This gives the agent meaningful behavioral expectations beyond the structured annotations without contradicting them.

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

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

The purpose is front-loaded and the overall length is reasonable for a 29-parameter tool. However, the prose is telegraphic and includes ambiguous fragments such as 'Business plan.' that weaken structure and clarity.

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

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

Given the 29 parameters, no output schema, and high schema coverage, the description covers prerequisites, scheduling behavior, refusals, validation behavior, and template guidance well. It still omits what a successful creation returns, such as a task identifier, and does not explicitly route to closely related tools.

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

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

Schema description coverage is 90%, so the schema already documents most of the 29 parameters in detail. The description adds useful scheduling context around schedule_at and time_window and advises filling all possible fields, but it does not meaningfully explain most parameter semantics beyond what the schema already provides.

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

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

The description opens with 'Places or schedules an Errands call from a brief,' giving a specific verb, resource, and Errands scope. It is clear what the tool creates, but it does not explicitly distinguish this action from siblings such as quote_call_task, request_call, or control_call.

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

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

It provides prerequisites and refusal cases ('current Errands terms', 'Business plan', emergency/premium and marketing calls refused) and directs the agent to describe_errand_template for field guidance. However, it never states when to choose this tool over related siblings like quote_call_task or request_call, so usage is mostly implied.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the safety profile is covered by structured data. The description adds a genuine scoping fact (routing is untouched) but doesn't say what is actually severed or how to restore it (re-attach via upsert_hours), nor whether the schedule record survives.

Agents need to know what a tool does to the 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 positive scope comes first and the negative scope second. Every sentence earns its place.

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

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

With one required param, no output schema and covered annotations, the description is close to sufficient, but the mismatch between the 'receptionist' framing and the ivr_config_id parameter is an unresolved gap for a destructive operation, as is the absence of any recovery/re-attach note.

Complex tools with many parameters or behaviors need more documentation. 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 ivr_config_id. The tool is framed around a 'receptionist', yet the required parameter is an IVR config ID, and neither schema nor description explains what that ID identifies or where to obtain it, leaving ambiguity an agent cannot resolve.

Input schemas describe structure but not intent. Descriptions should explain 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: stopping one receptionist from using its opening-hours schedule, which also clarifies that the tool detaches rather than deletes the hours data itself (contrary to the 'delete_' name). It partially differentiates from siblings by explicitly excluding DID routing changes, which contrasts with set_number_routing/update_forwarding, though it doesn't reference the upsert_receptionist_* family.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 useful exclusion ('does not change DID open/closed routing'), implying this tool is for schedule detachment only. However, it never names an alternative tool or states when an agent should prefer this over e.g. upsert_hours, so usage must be 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 destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the safety profile is covered structurally. The description adds useful scope clarification ('one' item, not a whole category), but says nothing about irreversibility, confirmation requirements, or what happens on a repeat call despite idempotentHint=false.

Agents need to know what a tool does to the 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 the verb and resource first. The long category enumeration is the only cost, and it does carry information an agent needs to know what can be deleted.

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

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

For a destructive tool with no output schema and zero parameter documentation, the description should cover at least irreversibility, the role of ivr_config_id, and the error behavior implied by idempotentHint=false. None of that is present.

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

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

Schema description coverage is 0% and both required parameters (id, ivr_config_id) are completely undocumented. The description implies 'id' identifies a single knowledge entry, but never explains what ivr_config_id is or how the pair scopes the delete, leaving the schema's burden unmet.

Input schemas describe structure but not intent. Descriptions should explain 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 (deletes) and a specific resource (one categorized knowledge item), and enumerates the knowledge categories it operates on, which makes the target unambiguous. It does not explicitly distinguish itself from the sibling upsert_receptionist_knowledge, but the create/update vs. delete split is obvious from the verb.

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

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

There is no statement of when to use this tool versus upsert_receptionist_knowledge or get_receptionist_facts, nor any prerequisite or safety guidance for a destructive operation. The only implicit cue is the word 'Deletes'.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds only the word 'one' (single-item scope); it says nothing about permanence, whether the parent receptionist config is affected, or required authorization, which are the remaining behavioral facts an agent would want.

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

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

One short, front-loaded sentence with zero padding. It is terse rather than bloated, so conciseness itself is fine; the problem is omission, not verbosity.

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

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

For a destructive, non-idempotent delete with two undocumented required parameters and no output schema, the description omits everything an agent needs beyond the basic action: what gets removed, whether the deletion is reversible, and what the two identifiers refer to.

Complex tools with many parameters or behaviors need more documentation. 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 mentions neither parameter. The agent must infer that 'id' identifies the location and 'ivr_config_id' scopes it to a receptionist, with no clarification of format, hierarchy, or whether the config id must match an existing parent.

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

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

The description gives a specific verb and resource ('Deletes one structured location from a receptionist'), which is enough to distinguish it from the adjacent delete_receptionist_hours and delete_receptionist_knowledge siblings. It stops short of naming those siblings or stating scope limits explicitly, so it is clear but not fully differentiated.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of the upsert_receptionist_location counterpart or of when deletion is appropriate versus updating the location. The agent is left to infer usage entirely.

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

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

Annotations already declare readOnlyHint, idempotentHint, so 'Read-only' in the description is redundant. The description does add useful behavioral content (what is returned: required/optional fields, shapes, allowed values, rules, examples), but it also describes a refusal path tied to assistant_name/save_as_default, parameters this tool cannot accept, which is misleading behavior disclosure.

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

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

The first sentence is well front-loaded and precise. The remaining sentences drift into assistant-naming and default-saving rules that belong to a different tool, so several sentences do not earn their place in this definition.

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

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

There is no output schema, so the description carries the burden of previewing the return value; it does list the categories returned (fields, rules, examples) but gives no sense of structure, size, or format. It is adequate for a zero-parameter read-only documentation tool, but the embedded non-existent-parameter guidance muddies the picture.

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

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

The schema has zero parameters with additionalProperties=false, so there is no real parameter surface to document. The description instead discusses assistant_name and save_as_default as if they were options of this call, which conflicts with the empty, closed schema and could lead an agent to pass arguments that will be rejected. Nothing of value is added about actual 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?

States a specific verb and resource (returns the Errands brief fields, rules, and worked examples) and even enumerates the categories of content returned, so the agent knows exactly what this tool yields. It does not, however, distinguish itself from the many other describe/get siblings beyond naming set_assistant_name in passing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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: the agent is expected to infer that this is the way to learn the Errands brief before building one. The one explicit when-to-use statement ('set it with set_assistant_name') concerns a parameter that does not exist on this tool, so it does not give usable routing guidance for describe_errand_template itself.

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

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

Adds context beyond the annotations: 'No sign-in' (no auth required) and 'An empty list means nothing is listed yet' (empty-result semantics) are genuinely useful disclosures. Annotations already cover read-only/idempotent/openWorld, so these extras push it above 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 compact sentences, front-loaded with the core purpose, then the useful 'empty list' and 'separate product' notes. Minimal waste.

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

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

With no output schema and only read-only annotations, the description adequately covers auth ('no sign-in'), empty results, scope, and product boundaries. Slightly missing on what the returned offer objects contain or how capabilities filter vs. filter-by-capability interact.

Complex tools with many parameters or behaviors need more documentation. 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 83%, so the schema already documents country, capability, form_factor, number_line, and capabilities. The description largely restates the same values (eSIM, physical SIM, voice, SMS, kosher line) without adding syntax or default behavior. 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+resource ('Find a home mobile service Widely can provide for a country') and clarifies the scope includes eSIM/physical SIM, voice, SMS, etc. It distinguishes itself from the travel-data product but does not explicitly differentiate from closer siblings like quote_service or list_plans.

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

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

Implied usage (discover what services exist for a country) with one exclusion ('Travel data for a trip is a separate Widely product'), but no explicit statement of when to prefer this over quote_service, quote_esim, or list_plans.

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=false, destructiveHint=false, idempotentHint=true, openWorldHint=true), and the description adds a genuinely useful behavioral fact: it charges the shared wallet the monthly fee. However, the remaining sentence ('A direct Widely connection runs it immediately') is opaque and the description says nothing about failure modes, prerequisites, or what state changes on the number.

Agents need to know what a tool does to the 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 padding, and the core capability leads. But the last sentence is cryptic rather than informative, so brevity comes partly from under-explanation rather than tight writing.

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

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

For a billed, state-changing tool with zero parameter documentation and no output schema, the description omits what the call returns, how monitor_ids affects behavior, and what happens when activation fails or is already active. Only the billing fact is covered; the rest is left to guesswork.

Complex tools with many parameters or behaviors need more documentation. 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 three parameters (did_id, ivr_config_id, monitor_ids) carry no documented meaning anywhere. The description gestures at a 'number this account owns' but never maps it to did_id, never explains ivr_config_id or monitor_ids, and gives no format or selection guidance to 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 the effect concretely: answering WhatsApp for a number the account owns via that number's AI receptionist, which an agent can read as 'turn on the WhatsApp AI receptionist'. It never distinguishes itself from the sibling update_whatsapp_ai (or add_number_channels), so the agent is left to infer whether this creates, enables, or modifies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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, when-not-to-use, or alternative named among the many siblings. The only implicit scoping is 'a number this account owns', which hints at a prerequisite but is not framed as guidance, and nothing tells the agent when to prefer update_whatsapp_ai instead.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: the APN can be null when the profile has none, and no authentication is required — neither of which appears in 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?

Three short sentences, front-loaded with the two return values and immediately followed by the null edge case and the auth note. 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 must carry the return contract, and it does — install path, APN, and the null case. The only gap is guidance on how this relates to the other eSIM-related 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 the baseline is 4. There is nothing about arguments for the description to clarify or omit.

Input schemas describe structure but not intent. Descriptions should explain 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 — returns the eSIM install path and APN — which is clearly distinct from siblings like quote_esim or get_esim_connection_check. It does not name an alternative, 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?

There is no indication of when to use this tool versus quote_esim, get_esim_connection_check, or run_esim_connection_check. 'No sign-in' hints at accessibility but gives no selection criteria or prerequisites.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds a genuinely useful behavioral fact beyond the annotations: an empty list means no matching charge, which tells the agent to treat emptiness as 'no match' rather than an error. It still omits pagination, result caps, and how results are derived.

Agents need to know what a tool does to the 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: the purpose is front-loaded and the empty-result edge case follows second. Nothing is padded or redundant.

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

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

For a one-parameter, read-only tool with no output schema, the description covers purpose and the empty-result case, which is the minimum viable set. It leaves the central mechanic unexplained, namely how the free-text 'question' is interpreted and what a returned charge record looks like.

Complex tools with many parameters or behaviors need more documentation. 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 parameter, 'question', with 0% schema description coverage, and the description says nothing about it at all. For a tool literally named 'explain_charges', the agent gets no hint that a natural-language question drives the lookup, nor what happens when it is omitted (the parameter is not required).

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

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

The description states a concrete verb and resource with a scope qualifier: it 'returns charges already on this account, with amounts and labels.' That distinguishes retrospective charge lookup from prospective pricing siblings like quote_call/quote_number. It does not, however, contrast itself with list_wallet_activity or the other wallet/balance readers, so sibling differentiation is only partial.

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

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

There is no explicit when-to-use or when-not-to-use guidance. The phrase 'already on this account' weakly implies the tool is for past charges rather than future quotes, but the agent must infer that from the sibling names, and nothing tells it to prefer this over 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 readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds genuinely new context: the balance is 'live' and matches the Home/Wallet headline, and 'which setups this seat can run' signals seat-scoped permissions rather than account-wide visibility.

Agents need to know what a tool does to the 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 that front-loads the action and then lists the returned values with no filler. Every clause corresponds to a distinct piece of output an agent would care about.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 return-value burden and does so by enumerating the fields. Minor gaps remain around freshness of the counts and whether the balance is formatted or raw, but nothing needed 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly does not waste words on 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?

States a specific verb and enumerates the exact payload: plan, live wallet balance, seat count, live eSIM count, and runnable setups. That is far more specific than a generic 'get account' and separates it from siblings like get_usage, get_auto_topup, and list_plans, though it never names an alternative explicitly.

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

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

Usage is only implied: the field list suggests a broad account snapshot and the 'same headline as Home and Wallet' note hints it is the summary view. There is no explicit 'use this when…' or 'for detailed wallet history use list_wallet_activity' 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 readOnlyHint, idempotentHint, and destructiveHint=false, so safety behavior is covered structurally. The description adds value by disclosing the shape of what comes back (state flag plus threshold and amount), which matters because there is no output schema.

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

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

A single short sentence that front-loads the return semantics with zero filler. Every clause ('whether it is on', 'the threshold and amount') earns its place.

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

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

For a no-parameter getter, the description covers the essentials and compensates for the missing output schema by naming the returned fields. Complete enough to call correctly, though it could note the read/set pairing for full routing confidence.

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

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

The tool takes zero parameters, so the baseline is 4 and there is nothing extra for the description to document. It correctly implies no inputs are needed.

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

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

States a specific verb ('Returns') and resource ('auto top-up'), plus the exact fields returned (on/off, threshold, amount), so an agent immediately knows this is a read of top-up configuration. It does not explicitly name the write counterpart set_auto_topup, so it falls short of full sibling differentiation.

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

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

The verb 'Returns' implies a read-only lookup, which implicitly contrasts with the sibling set_auto_topup, but the description never states when to prefer this tool or that it is the read companion to set_auto_topup. 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 declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds content the annotations cannot: that the response is the full detail for one call and includes the carrying identity and provider — meaningful because there is no output schema.

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

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

A single well-formed sentence with the action front-loaded and no filler. It is efficient, though it is lean enough that a short second clause on ID origin or return shape would not have hurt.

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

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

For a one-parameter read tool whose annotations already carry the full safety profile, this is close to sufficient: it says what comes back and that the call is located by ID. The residual gap is guidance on where the call_id comes from and how it compares to search_calls.

Complex tools with many parameters or behaviors need more documentation. 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 parameter, so the description must carry the burden. It names call_id and frames it as the record identifier, but adds no format, source, or validity guidance beyond what the raw schema type already shows.

Input schemas describe structure but not intent. Descriptions should explain 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 ('Returns full detail for one phone call') and scopes it to a single record via call_id, which implicitly separates it from the sibling search_calls. It never names a sibling, so the differentiation is inferred rather than stated.

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

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

'Identified by call_id' implies the agent must already hold an ID (e.g. from search_calls) before calling, which is reasonable implied usage. However, there is no explicit when-to-use statement, no exclusion against list-style siblings, and no note on what to do if the ID is unknown.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds the useful fact that the response bundles status, quote, facts, and events, but says nothing about auth scope, failure modes, or behavior for unknown task_ids.

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

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

One sentence, front-loaded with the verb and resource, with the returned fields inline. 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?

No output schema exists, so the description carries the burden of describing the return payload, and it does so in a compact enumeration. For a simple single-parameter read tool this is nearly sufficient; only the task_id semantics and error behavior are missing.

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

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

The single task_id parameter has 0% schema description coverage, and the description does not state its format, origin (e.g., from create_call_task or list_call_tasks), or any constraint. With one undocumented parameter the description fails to 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?

States a specific verb ('Returns') and resource ('one Errands task') and enumerates what comes back (status, quote, collected facts, recent events). The word 'one' distinguishes it from the sibling list_call_tasks, though no sibling is named explicitly.

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

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

No guidance on when to use this retrieval versus list_call_tasks or the quote_call_task / cancel_call_task siblings, and no prerequisites such as where a task_id comes from. Usage must be inferred entirely from the 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 (readOnly, idempotent, non-destructive, closed-world), so the bar is lower; the description adds genuinely useful behavior by disclosing that the ladder starts from data already used this period (a proration/continuation semantic) and that this is the account rate, not the public shelf. It does not mention return shape beyond the volume-points case, but 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, front-loaded with what is returned, then the scoping caveat, then the parameter behavior. No filler; every sentence 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 two-parameter read-only lookup with no output schema, the description covers what is returned, the scope of the rate, and the effect of omitting gb. Only the shape of the returned ladder points is left implicit, which is a small 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?

Schema coverage is 100%, so the baseline is 3, but the description earns an extra point by explaining the consequence of omitting gb ('returns the volume points') — something the schema's 'Omit when they have not said' does not state. That is real meaning added beyond the structured field.

Input schemas describe structure but not intent. Descriptions should explain 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 — returns the customer's pay-as-you-go data ladder — and draws a real conceptual boundary against the 'public shelf' rate, which is the distinction an agent needs to avoid confusing it with the quote_* / get_did_rate siblings. It stops short of naming an actual sibling tool, so it is clear but not fully differentiated.

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

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

Usage is implied: fetch this when you need the account-specific rate rather than a public quote. The description supplies the gb-omission rule, which is a calling condition, but it never states when to prefer this over quote_number/quote_esim/get_did_rate, nor any prerequisites. Minimum-viable guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorldHint=false, so the safety profile is covered. The description adds two useful facts beyond the annotations: the price is 'indicative' (an estimate, not a firm quote) and is derived from 'this account's' rate checker, making it account-specific. It still says nothing about currency, billing cadence, or failure modes.

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

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

A single front-loaded sentence with no filler or repetition. It is efficiently sized, though it leans so terse that it omits the parameter detail it could have used its budget for.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 two-parameter tool with annotations covering safety and no output schema, the purpose statement is broadly sufficient. The gaps are the undocumented number_type input and the lack of any hint about the shape or currency of the returned price.

Complex tools with many parameters or behaviors need more documentation. 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 only implicitly covers the required 'country' parameter. The optional 'number_type' parameter is never mentioned, so its accepted values and effect on the returned rate are undocumented in both the schema and the description.

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

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

States a specific verb and resource: 'Returns an indicative monthly phone-number price for a country.' That is clearly distinct from get_data_rate and get_account_balance. It does not, however, differentiate itself from close siblings like quote_number or check_call_rate, which also appear to produce pricing quotes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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, when-not-to-use, or prerequisite guidance is given. With sibling tools like quote_number, get_data_rate, and check_call_rate in the same pricing family, an agent has no stated basis for choosing this tool over those.

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 'Phone settings are not changed' largely restates the safety profile. The description does add real value by disclosing the return content (fail and warn items), but says nothing about latency, whether the check must be complete, or error behavior for an unknown/stale request_id.

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

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

Two tight sentences with the purpose front-loaded and no filler. The second sentence is short but leans on annotations to make its point.

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

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

There is no output schema, so the description should carry return-shape detail; it gestures at 'fail and warn items' but not their structure. Combined with the unlinked request_id and unmentioned sibling, an agent has just enough to call it, not enough to call 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 single parameter is undocumented in the schema. The description only reuses the name 'request_id' as the lookup key, adding no format, origin (which tool produces it), or validity/lifetime semantics, 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?

States a specific verb and resource ('Returns the result of an eSIM connection check') plus the scope ('for request_id, including fail and warn items'). The retrieval framing implicitly distinguishes it from run_esim_connection_check, but it never names that sibling, so an agent must infer the pairing.

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

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

No explicit when-to-use statement and no named alternative; the requirement of a request_id only implies that a check must already have been run (presumably via run_esim_connection_check). 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 declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds a genuinely new behavioral fact beyond the annotations: the feature is gated to the Pro plan, which affects whether a call will succeed.

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

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

Two short sentences, front-loaded with what is returned and then the plan constraint; every word earns its place with no redundancy.

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

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

With no output schema, the description must carry the burden of describing the return value, and 'how this seat's numbers are forwarded' is vague about the actual shape (target numbers, conditions, fallback). It is adequate for a zero-parameter read tool but leaves the response format under-specified.

Complex tools with many parameters or behaviors need more documentation. 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 correctly does not invent parameter 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?

Clear specific verb (Returns) and resource (this seat's numbers' forwarding), which an agent can distinguish from the sibling update_forwarding. It does not explicitly name that sibling or state it is the read counterpart, but the scope is unambiguous.

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

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

Usage is only implied: the read-only nature and the presence of update_forwarding suggest when to call this. The 'Pro plan' note is a gating hint rather than a when-to-use rule, and no exclusions or alternatives are named.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, and the description still adds genuine value by enumerating what comes back: the toggles and the low-balance threshold. With no output schema, this return-content disclosure is the only source of that information.

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

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

A single sentence with zero waste, front-loading the verb and the returned payload. Nothing could be removed without losing information.

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

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

For a zero-parameter read tool whose annotations carry the safety profile and whose lack of an output schema is compensated by the field list in the description, this is nearly complete. The only minor gap is not pointing at set_notification_preferences for the write case.

Complex tools with many parameters or behaviors need more documentation. 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 is the baseline-4 case per the rubric. There is nothing for the description to add semantically, and it correctly does not invent parameter guidance.

Input schemas describe structure but not intent. Descriptions should explain 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 (Returns) and resource (notification toggles plus the low-balance threshold), and the payload contents immediately separate it from the sibling set_notification_preferences. It is clear but never explicitly names the setter counterpart, so differentiation is implicit rather than stated.

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

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

The read-oriented phrasing implies 'use this to inspect current settings before changing them', but there is no explicit when-to-use statement, no prerequisite, and no mention of set_notification_preferences as the mutation alternative. Adequate but leaving routing 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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the useful hint that ports are asynchronous/take time, but says nothing about returned status values, polling expectations, or latency.

Agents need to know what a tool does to the 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 purpose. The second sentence is terse and adds a behavioral hint, though it 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?

No output schema exists, so the description should ideally say what the status values look like and whether polling is expected. Given the tool's simplicity (one required param, a read-only operation), the description is barely adequate but leaves the return shape unexplained.

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

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

Schema description coverage is 0% for the single port_id parameter, so the schema alone does not explain the argument. The description does not compensate by describing the identifier's format or where it comes from (e.g., a start_port response).

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

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

The description gives a specific verb and resource: it returns the current status of a port request. That is clearly distinct from start_port and quote_port, though it never names or explicitly contrasts with the closest sibling, port_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?

There is no explicit when-to-use or when-not-to-use statement, and no alternative is named. The sentence 'A port is not instant' implies the tool is meant for checking progress while a transfer is pending, which is only implicit guidance.

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

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

Annotations already declare readOnly, idempotent, and non-open-world behavior, so safety is covered. The description adds genuinely new behavioral context: the thread is returned oldest-first, no account is required, and only one thread is returned. It stops short of describing pagination or note contents.

Agents need to know what a tool does to the 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, zero filler, with the core action and lookup key front-loaded before the ancillary constraints. Every sentence carries 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 single-parameter read tool with no output schema, the description covers what is returned, the ordering, the auth posture, and the scope limit. The only gap is that it does not sketch what a 'product note' contains, which the agent would otherwise have to infer.

Complex tools with many parameters or behaviors need more documentation. 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 conversation_id parameter, but the description ties the parameter to its role ('one product-note thread by conversation_id'). That is the minimum needed; no format, source, or example of a conversation_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 verb and resource ('Returns one product-note thread by conversation_id') and adds the ordering ('oldest first'), so the agent knows exactly what this returns. It does not explicitly contrast itself with the sibling get_thread, leaving a small ambiguity about which thread-retrieval tool to pick.

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

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

'No account is required' and 'Does not list other threads' imply the context of use and rule out a listing interpretation, but there is no explicit statement of when to choose this over get_thread or submit_product_note. Usage is only indirectly conveyed.

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 closed-world, so the safety profile is covered. The description adds value beyond that by enumerating exactly which data categories are returned and framing it as a read-before-write step, which is genuine behavioral context.

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

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

One sentence, front-loaded with the verb and the resource, with the returned categories listed compactly. No filler or repetition 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?

With no output schema, the description usefully enumerates what the caller receives and positions the call in the read-then-update workflow. It is nearly complete for a simple single-parameter read, missing only the identifier's format and any error/empty-result 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% — the single parameter ivr_config_id has no documentation anywhere. The description only weakly compensates by implying the identifier selects 'one receptionist', but it never states the expected format or where the ID comes from. Adequate but with a clear 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 gives a specific verb ('Returns') plus a resource ('one receptionist's profile') and enumerates the returned data categories (contacts, locations, opening hours, categorized business facts). It is clear what the tool does, though it never names a sibling tool or explicitly contrasts itself with the upsert_* write tools.

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

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

The clause 'before you update them' supplies a concrete usage context: read this prior to performing an update, which implicitly routes the agent away from the upsert_receptionist_* siblings. No explicit when-not-to-use condition or alternative tool is named, so it stops short of a 5.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive), so the bar is lower. The description adds genuinely new behavioral facts beyond annotations: the link is short-lived, requires the Business plan, and requires the recordings.read grant. It does not say what happens if the grant is missing or whether the link expires in a retrievable way.

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

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

Two sentences, front-loaded with the return value, then the authorization gates. Every clause earns its place and 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?

A read-only one-param tool with no output schema is fairly simple, and the auth/plan gates are the key missing pieces that were supplied. Still, call_id provenance and error behavior on missing plan/grant are unstated, leaving some gaps an agent would want.

Complex tools with many parameters or behaviors need more documentation. 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 the single call_id parameter is undocumented in both schema and description. Baseline for one param without schema documentation is still a 3, and the description adds no format or source hint (e.g., how to obtain call_id). It compensates only weakly.

Input schemas describe structure but not intent. Descriptions should explain 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 short-lived streaming link for a recorded phone call'), which distinguishes it from siblings like get_transcript (text) and get_call (metadata). It does not explicitly name those siblings, 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?

Usage is implied by the resource description, but there is no explicit when-to-use/when-not guidance and no routing to alternatives such as get_transcript or search_calls. The mention of plan and scope requirements is a gate, not usage guidance.

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

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

Annotations already cover readOnly, idempotent, and non-destructive behavior, so the bar is lower. The description adds genuinely new behavioral detail beyond the annotations: results are ordered oldest-first and 'before' pages toward older messages, which tells the agent how to paginate.

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

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

Two short sentences with zero waste; the core behavior is front-loaded before the pagination detail.

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

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

For a small 3-param read tool with no output schema, the essentials (ordering, cursor meaning) are covered. However, the limit bound (max 50) and the conversation_id identifier's origin are left to the schema and inference, so it is adequate but not fully self-contained.

Complex tools with many parameters or behaviors need more documentation. 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%: 'limit' is documented in the schema, but 'conversation_id' and 'before' are not. The description compensates for 'before' by explaining it is an ISO 8601 cursor for older pages, but adds nothing about conversation_id, leaving a 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 ('Returns messages in one thread') plus the ordering guarantee. It is clearly distinguishable from search_messages by implying single-thread retrieval, though it never names that sibling explicitly.

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

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

No guidance on when to prefer this over search_messages, nor any prerequisites or context for use. The reader must infer the thread-reading use case from the name alone.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the marginal burden is low. The description adds genuinely useful state semantics beyond the annotations: in_progress while the call is live and no_transcript only after the conversation ends with no stored text.

Agents need to know what a tool does to the 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 behavior and the negative scope right after. Every sentence carries information; the only minor cost is the slightly repetitive status phrasing.

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

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

For a one-parameter read tool with no output schema, the description supplies the missing return-state information (in_progress vs no_transcript) that the schema cannot. It stops short of stating what a successful transcript payload looks like beyond 'text', but that is a minor gap.

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

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

The single call_id parameter has no schema description (0% coverage) and is never mentioned in the description. The phrase 'for a phone call' implicitly signals what must be identified, but no format or lookup guidance is added, so it does no more than the schema's required-fields list.

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

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

States a specific verb and resource (returns stored transcript text for a call) and immediately delimits scope with 'Does not start a new transcription.' That negation cleanly separates it from the sibling request_transcript without requiring the agent to open 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?

Gives clear conditions for the tool's use and explicitly rules out the transcription-starting case, which is the main confusion risk. It does not, however, name the alternative (request_transcript) so the agent must infer where the excluded case belongs.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description usefully adds the seat-vs-account scoping distinction, but says nothing about response shape, units, or the default look-back beyond what the schema 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 tight sentences, front-loaded with the returned resource and followed immediately by the one non-obvious parameter behavior. No filler, though the second sentence is terse enough to feel slightly clipped.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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, two-parameter tool with no output schema, the description covers the core purpose and the ambiguous flag. It omits what fields come back and how 'days' bounds the totals, so an agent lacks a little context for interpreting results.

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

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

Schema coverage is 50%: 'days' is documented in the schema, but 'company' has no schema description. The description compensates for 'company' by explaining it means whole-account scope on Business, which is the useful bit; still, no detail on how days interacts with either scope.

Input schemas describe structure but not intent. Descriptions should explain 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 (Returns) and resource (eSIM data balance and minutes used), and pins the scope to 'this seat' vs 'the whole account'. It is clearly distinguishable from get_account_balance and get_data_rate by the seat-level framing, though it never names a sibling to route away 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?

The 'company=true covers the whole account on Business' note implies when to use the account-wide variant, but there is no explicit when-to-use, when-not, or alternative-tool guidance against the many get_*/quote_* siblings. Usage 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 cover the safety profile (readOnly, idempotent, non-destructive). The description adds genuinely new behavioral context: the response includes the transcript, and include_audio yields a short-lived audio link that is gated to Pro plans and above.

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

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

Two sentences, zero waste, with the core return behavior front-loaded and the conditional audio detail following. 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 correctly names the returned content (voicemail plus transcript) and the optional audio link. Nothing critical is missing for a two-parameter read tool whose annotations cover safety.

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

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

Schema description coverage is 0%, so the description must carry the load, and it does: include_audio is explained as producing a short-lived audio link with a plan restriction, and call_id is tied to selecting the voicemail. Format details for call_id are still absent.

Input schemas describe structure but not intent. Descriptions should explain 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: 'Returns one voicemail by call_id'. The singular 'one' implicitly separates it from list_voicemails, but no sibling (e.g. get_recording, get_transcript) is named explicitly.

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

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

No statement of when to call this versus list_voicemails or get_transcript, and no preconditions beyond the implied need for a call_id. The agent must infer usage from the name alone.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false and destructiveHint=false, so the safety profile is covered. The description usefully adds billing/limit context ("start Free", "no account user limit") but does not say what happens on a duplicate invite or what permissions are required.

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

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

Two tight sentences with the action front-loaded. The second sentence (free tier, no user limit) earns its place as decision-relevant context rather than 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 one-parameter invite tool with annotations covering behavior and no output schema, the description is adequate but thin. It omits permission requirements and duplicate-invite behavior, which an agent would want before invoking a non-idempotent mutation.

Complex tools with many parameters or behaviors need more documentation. 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 `email` parameter has 0% schema description coverage, so the description carries the burden. It only implies that email is the recipient ("Emails an invitation") without giving format or constraint details, leaving the parameter under-documented.

Input schemas describe structure but not intent. Descriptions should explain 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 ("Emails an invitation") and resource ("to join this Widely account"), so the agent knows exactly what the tool does. No sibling is named, but with no other invite/team-add tool in the list it is hard to confuse.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 (e.g. admin permission), and no mention of an alternative if the person is already a member. The agent must infer usage entirely.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds one genuinely useful behavioral fact — results are limited to "this seat's" tasks — but says nothing about pagination, ordering, or default result size.

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

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

Two short sentences, no filler, with the scope constraint front-loaded before the filtering hint. Efficient, though borderline terse for a tool with an undocumented status field.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 no output schema, annotations cover safety and the schema covers parameter types, so the description needn't explain return values. However, unanswered questions remain: valid status values, default/max result count behavior, and ordering — enough gaps to hold it at minimum-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?

Schema description coverage is 0%, so the description carries the burden. It gestures at the status and date (since/until) filters but gives no accepted status values, no date format guidance, and never mentions the limit parameter with its 1–50 range, leaving a quarter of the parameters undocumented anywhere.

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

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

The description gives a specific verb and resource ("Lists this seat's Errands tasks") and scopes it to the caller's seat, which cleanly separates it from single-task siblings like get_call_task and mutating ones like cancel_call_task. It does not explicitly name 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?

"Filter by status or date" implies how the tool is used once chosen, but there is no statement of when to prefer it over get_call_task, search_calls, or quote_call_task. Usage is inferable from the name and description 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?

The annotations already establish readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description still adds real value beyond them by disclosing that inactive numbers pending identity registration are included in the result, which is a behavioral nuance an agent would not otherwise 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?

A single front-loaded sentence that states the resource first and then the one qualifying detail. No filler, no restatement of the title or 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 no-parameter, no-output-schema list tool, the description covers what is returned and one important edge case (inactive numbers). It could say a bit more about the returned shape (e.g. what identifies each number), but nothing essential to calling it is missing.

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

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

The tool takes zero parameters, so there is nothing to disambiguate; per the rubric this is the baseline 4. No schema or description detail is missing on the parameter side.

Input schemas describe structure but not intent. Descriptions should explain 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 ('Returns this account's phone numbers') and scopes it to the caller's own account, which implicitly separates it from search_numbers (catalog search) and quote_number. It stops short of explicitly naming those siblings, so the distinction must be inferred.

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

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

Usage is implied by the 'this account's phone numbers' scoping, but there is no explicit when-to-use guidance and no named alternative for the closely related search_numbers or list_identities tools. The agent has to infer that this is the inventory-listing tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds useful context beyond that: results are scoped to 'this Widely seat' and include the supplying provider and capability. It does not mention pagination or any filtering behavior, so this is a moderate add rather than a rich one.

Agents need to know what a tool does to the 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 that packs the verb, the resource list, the scope, and the extra returned metadata with no filler. Efficient and well-structured, though the dense enumeration makes it slightly list-like rather than hierarchical.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 listing tool with full annotation coverage and no output schema, the description does the important remaining job of telling the agent what comes back (numbers, caller IDs, SIMs, extensions, eSIMs plus provider/capability). The main gap is the absence of routing guidance against the other list/search number tools.

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

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

Schema description coverage is 100% and the single parameter (include_shared) is fully documented in the schema, including the Business-plan prerequisite. The description adds nothing about parameters, so the baseline 3 for high-coverage schemas 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 ('Returns') and enumerates the exact resources returned (phone numbers, caller IDs, SIM numbers, PBX extensions, eSIMs), scoped to 'this Widely seat'. Clear on its own, but it does not differentiate itself from list-oriented siblings such as list_did_numbers, list_pbx, or search_numbers, which an agent might reasonably confuse it with.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 exclusion, and no named alternative among the many list_* and search_numbers siblings. The agent must infer usage purely from the enumeration of returned resources.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds one useful negative fact (no processor id returned), which prevents an agent expecting to hand off a processor token, but little else.

Agents need to know what a tool does to the 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 returned resource and fields, with the exclusion placed last. 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 zero-param, no-output-schema read tool the core is present, but with no output schema the description should at least note the return shape (e.g., list vs single, pagination) and when to reach for it over 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 per the rubric the baseline is 4; there is nothing for the description to clarify or compensate for.

Input schemas describe structure but not intent. Descriptions should explain 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 (Returns) and resource (masked saved cards and bank methods) with the exact fields exposed, which distinguishes it from siblings like get_account_balance or list_wallet_activity.

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

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

Provides no guidance on when to use this versus adjacent tools (e.g., get_account, list_wallet_activity) and no exclusions or prerequisites. Usage is only implied by the list_ naming prefix.

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 read-only, idempotent, non-destructive, closed-world. The description adds real behavioral context beyond that: tiered plan requirements for different feature classes and the runtime rule that a queue only rings members who are signed in and available. That conditional behavior is not derivable from annotations or 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 sentences, front-loaded with the return contents before the prerequisites and queue behavior. The first sentence is dense but each clause names a distinct component, and no sentence is filler. Slightly list-like, but efficient.

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

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

With no output schema, the description carries the burden of describing the return shape, and it does so item by item, plus prerequisites and queue semantics. Missing only explicit scoping versus sibling list tools, which is a minor gap for a zero-arg read 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?

Zero parameters and 100% schema coverage, so there is nothing for the description to clarify; the baseline for a no-param tool 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 states a concrete read action ("Returns") and enumerates the resource contents precisely: numbers and their answerers, AI receptionists with greeting/knowledge/voice/languages, press-1 menus, queues, and opening hours. An agent can tell what data comes back. It does not, however, distinguish this from siblings like list_pbx or list_did_numbers, which overlap in the phone-system domain.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 — this is the read-all view of phone-system configuration. The description gives plan prerequisites (owner needs Business; queue agents and shared-number users need Business) but never says when to pick this over list_pbx, list_did_numbers, or get_forwarding. No explicit when/when-not 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 readOnly/idempotent/non-destructive, and the description adds genuinely useful context beyond them: 'No sign-in', 'This does not change the plan', and the per-user pricing semantics that prevent misquoting. It stops short of describing response shape nuances like currency handling.

Agents need to know what a tool does to the 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 purpose and reasonably tight, though several short sentences (sign-in, plan mutation, channel_packs) read as a checklist. Each sentence carries information, but the channel_packs detail is slightly ahead of need for a single-parameter listing call.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 sketches the return shape (per-user monthly figures and channel_packs contents), which is exactly what an agent needs. It omits currency behavior in the result, a minor gap for a tool this simple.

Complex tools with many parameters or behaviors need more documentation. 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 currency parameter is fully documented with enum and default in the schema. The description adds no 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 verb and resource ('List Free, Pro, and Business monthly prices') and names related data (channel_packs). Clearly distinguishable from sibling quote tools like quote_service or explain_charges.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 operational guidance on how to present the result ('Quote that amount. Do not round it...') but never says when to use this tool versus alternatives such as quote_service, quote_number, or explain_charges. Usage is implied rather than routed.

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 by structured data. The description adds only that the result mixes confirmed members with pending invites, which is modest added context about return content rather than behavior. No pagination, auth, or scoping details are given.

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

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

A single front-loaded sentence with no filler or redundancy. Every word carries information, and the return content is stated up front.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 annotations covering safety and no output schema, the description adequately conveys what is returned (people plus pending invites). It could be slightly more complete by noting scoping or ordering, but nothing critical for correct invocation is missing.

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

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

The tool takes zero parameters, so the baseline of 4 applies. The description does not need to explain parameter syntax, and it correctly does not attempt to.

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

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

States a clear verb (returns/lists) and resource (people on the account plus pending email invites), so the agent knows exactly what it retrieves. It does not, however, explicitly distinguish itself from related siblings like list_identities or invite_member, which an agent might reasonably confuse with the 'people on this account' framing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 routing to alternatives. The 'pending email invites' content implies a possible relationship to invite_member, but the description never states that connection. Usage is only inferable from the purpose.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds useful disclosure about the response payload and the conditional transcript ('when one is stored'), but says nothing about ordering, pagination, or truncation 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?

A single front-loaded sentence that states scope first, then the payload. Every clause carries information and nothing is padded.

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

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

With no output schema, the description does carry the minimum return-value information (caller, time, duration, transcript). However, it omits ordering, pagination/limit behavior, and how to retrieve the full transcript or a single voicemail, which are material for a listing tool with a get_voicemail 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?

Schema description coverage is 100% and both optional parameters (days, limit) are documented in the schema itself with defaults and bounds. The description adds no syntax or format detail 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 names a specific verb (Returns) and resource (voicemails) plus the scope 'on this seat', and it enumerates the returned fields (caller, time, duration, transcript). It does not, however, distinguish itself from the sibling get_voicemail, so an agent must infer that this is the bulk/recent listing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 the get_voicemail alternative for a single item, and no exclusion criteria. 'Recent' is the only usage signal and it is undefined in the description (the 30-day default lives only in the schema).

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 covered. The description adds genuinely useful content about what the ledger contains and that each row carries a customer label, but says nothing about pagination behavior, default ordering, or whether results are bounded by the limit/offset pair.

Agents need to know what a tool does to the 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 resource and its contents, with zero filler. Nothing needs trimming.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 reasonably covers what a row contains, and annotations cover the safety profile. However, for a paginated list tool with two undocumented parameters, the missing paging guidance leaves a real gap for correct invocation.

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

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

Schema description coverage is 0% and both parameters (limit, offset) are undocumented in the schema. The description does not compensate at all: it never mentions pagination, the maximum limit of 200, or what offset does. An agent must guess the paging contract.

Input schemas describe structure but not intent. Descriptions should explain 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 ('Returns the wallet ledger') and enumerates the entry types (top-ups, product debits, holds), which clearly differentiates it from general account tools. It does not explicitly contrast with the closest sibling, list_wallet_refunds, so sibling 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?

There is no statement of when to call this tool versus alternatives such as list_wallet_refunds, get_account_balance, or explain_charges. The agent must infer usage purely from the resource 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 the full safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description goes beyond them by disclosing the business rules that determine eligibility — profile not installed and inside the refund window — which is genuine behavioral context an agent could not infer from 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?

One tight sentence with the verb and result front-loaded and the qualifying conditions appended after a colon. No filler, no repetition 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 parameterless, read-only list tool with no output schema, the description covers what is returned and the exact qualifying conditions, which is the essential information. It could optionally note the return shape or ordering, but nothing critical is missing.

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

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

The tool takes no parameters, so the baseline is 4. The description adds no parameter meaning because there is none to add, and schema coverage is 100% regardless.

Input schemas describe structure but not intent. Descriptions should explain 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 (Returns) and a precisely scoped resource (first-eSIM wallet top-ups refundable to the card), which inherently separates it from list_wallet_activity. It does not, however, name or contrast against any sibling, so it stops short of the top mark.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 eligibility criteria ('profile has not been installed', 'inside the refund window') imply when the tool is relevant, giving a competent agent enough to act. But there is no explicit when-to-use statement, no exclusions, and no routing to alternatives such as 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?

Beyond the annotations, the description discloses the billing model (per-GB, no data package), that installation happens later, and that idempotency_key changes repeat behavior. These are meaningful operational details for a mutation tool. The keyed idempotency note does not contradict idempotentHint=false; it clarifies a conditional exception.

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

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

The description is four short sentences with no filler. The core action is front-loaded, followed by only operationally relevant notes about billing, installation timing, and keyed idempotency.

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

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

The description covers key behavior for a mutation tool without annotations, including billing and installation timing. However, it omits the required country parameter semantics and does not clarify what the returned order/profile contains, despite having no output schema.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It explains idempotency_key well, but the required country parameter is never described in the schema or the description. Half of the parameters remain semantically unexplained.

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

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

The description names a specific verb and resource: 'Creates an eSIM profile.' This clearly distinguishes it from read-only siblings like get_usage or esim_install_steps. It does not explicitly contrast with quote_esim, but the action is still clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 order_esim versus quote_esim, prepare_order, or order_service. The billing note ('Data is billed per GB as it is used. There is no data package.') describes consequences, not selection criteria.

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

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

Annotations already disclose readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds only that this action is limited to marketplace services, not travel data. It says nothing about prerequisites, such as needing an offer_id from discovery, whether money is charged or a payment method is required, or what happens when the call is repeated, which both matters because the call is non-idempotent and is not implied by the annotations.

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

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

The purpose is front-loaded in the first sentence, and the sentences are short. 'Available now' is vague filler that costs space without adding actionable meaning.

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

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

For a mutating, open-world tool with four parameters that lack schema descriptions, no output schema, and real cost or side effects, the description is under-specified. It omits required prerequisites (where offer_id comes from), billing implications, the optional `number` parameter, and the shape of the request's effect.

Complex tools with many parameters or behaviors need more documentation. 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 explain the four parameters itself. It clarifies form_factor and number_line only by saying they must be 'allowed by the offer'; offer_id's source is never explained, and the optional `number` parameter is never mentioned.

Input schemas describe structure but not intent. Descriptions should explain 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: 'Starts a Widely order for a listed marketplace service.' The scope exclusion ('Does not order Widely travel data') helps separate it from travel-related siblings, but it never distinguishes itself from prepare_order, quote_service, or order_esim, which are the closest alternatives.

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

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

Steers the agent toward ordering a listed service, with a negative scope rule ('Does not order Widely travel data'), but gives no context about when to call it. It doesn't say whether prepare_order or quote_service must be called first, nor how the tool relates to order_esim.

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 adds two pieces of context not in the annotations: no authentication is required, and the call has no submission side effect. That is genuine added behavioral value, though return shape is unspecified.

Agents need to know what a tool does to the 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, zero waste, with the core purpose front-loaded and the two constraints following as quick clarifiers.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 lookup with no output schema, the description is nearly complete: it says what comes back (documents) and what it does not do. It could briefly indicate what form the document list takes, which is the only minor gap.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly implies no inputs are needed by describing a static lookup, and nothing in the schema requires further explanation.

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

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

The description names a specific verb and resource: it returns the documents a number port requires. It implicitly distinguishes itself from start_port by stating 'Does not submit a port', though it does not name that sibling explicitly.

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

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

Usage is implied by the negations ('No sign-in', 'Does not submit a port'), which tell the agent this is a pre-flight lookup rather than the port submission itself. However, no positive when-to-use condition or named alternative (e.g. start_port, quote_port) is given.

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

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

With readOnlyHint=false the annotations signal a write, and the description usefully clarifies the blast radius: it does not charge a card or the wallet, requires no sign-in, and returns a link rather than completing the transaction. It also discloses return fields (monthly_per_user, monthly_total). It stays silent on idempotency, which the annotations flag as false.

Agents need to know what a tool does to the 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, front-loaded with the purpose and immediately followed by the return value and the pricing caveat. No filler, though the opening enumeration of six order kinds is dense.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 19-parameter, one-required-argument tool with no output schema, the description covers the essential behavior (no charge, returns a link, pricing fields) but leaves most conditional parameters unexplained, so an agent would have to guess how to populate them.

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

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

Schema description coverage is only 42% across 19 parameters, so the description carries a heavy burden, and it only glosses the `kind` categories plus the pricing outputs. Parameters like queue, menu, recording, ai_receptionist, phone_numbers, number_type and who_answers are left undocumented in both places.

Input schemas describe structure but not intent. Descriptions should explain 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 (prepare an order) and enumerates the order kinds, which map cleanly onto the `kind` enum. It also states the concrete outcome (a Widely link to finish). It stops short of distinguishing itself from the many quote_* siblings it sits beside, so the reader has to infer the relationship from 'after the price is known'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 'after the price is known' implies a sequencing rule (quote first, prepare second) but never names the alternative tools such as quote_number or quote_esim, nor states when not to use this tool. Usage is implied rather than specified.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context by explaining that signed-in calls return the account's rate as account_rate true and anonymous calls return list_price true, though it does not describe error behavior or response shape beyond those flags.

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

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

The description is three tight sentences, front-loaded with the core return value and followed by the signed-in distinction and the non-call-placement clarification. Every sentence adds useful information without repetition.

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

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

With no output schema, the description usefully explains the returned rate semantics via account_rate and list_price. The main remaining gap is that all four parameters are optional and the description does not clarify what happens when neither destination nor country is supplied, or when number_type should be used.

Complex tools with many parameters or behaviors need more documentation. 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%: currency and destination are documented in the schema, while country and number_type are not. The description partially compensates by saying the tool prices a destination number or country, but it gives no guidance on number_type or on how the parameters interact when all are optional.

Input schemas describe structure but not intent. Descriptions should explain 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: it returns the per-minute price for dialling a destination number or country. It also explicitly distinguishes the tool from call placement with “This does not place the call,” so an agent can tell it apart from request_call or create_call_task.

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

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

The signed-in versus not-signed-in behavior is clearly explained, but there is no explicit when-to-use guidance or named alternatives such as quote_call_task or get_did_rate. Usage is implied by the rate-checking context rather than stated as a decision rule.

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 behavior, but the description adds substantial context: return values, refusal rules for destinations and marketing briefs, prerequisite Errands terms, aggregated validation errors, and the explicit no-dial guarantee. This is rich behavioral 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?

The description is short and front-loaded, with each sentence carrying relevant information. Some fragments like 'No rate refuses the call' are slightly cryptic, but overall it remains efficient and readable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 29-parameter quote tool with no output schema, the description covers the essential behavior: pricing source, return values, refusals, prerequisites, validation behavior, and non-dialing. It does not detail the full response shape or all guardrails, but annotations and schema cover much of that.

Complex tools with many parameters or behaviors need more documentation. 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 90%, so baseline is 3. The description adds useful semantics: cost is calculated at max_call_minutes, destination refusal categories apply, marketing purpose_category is refused, and bad briefs report all missing/invalid fields at once.

Input schemas describe structure but not intent. Descriptions should explain 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: 'Prices an Errands brief from the call rate sheet, including the ai_task minute.' It also clarifies output ('Returns the caller ID and the cost at max_call_minutes') and explicitly says 'This does not dial', distinguishing it from create_call_task/request_call.

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

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

Provides clear when-not conditions: emergency and premium-rate numbers are refused, marketing briefs are refused, and the seat needs current Errands terms. The 'does not dial' line implies this is a preflight to actual call creation, but it does not explicitly name create_call_task as the alternative or state when to use quote_call instead.

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

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

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false). The description adds some behavioral context: pay-as-you-go billing, 0.1 GiB billing increments, and no sign-in required. However, it doesn't explain rate limits, caching behavior, or whether prices are guaranteed or estimates only.

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

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

The description is concise and front-loads the core purpose. Sentences earn their place, though the phrasing is slightly awkward in places (e.g., 'Pay as you go per GB' could be tighter). Overall efficient.

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

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

For a read-only pricing tool with annotations covering safety, no output schema, and partial schema coverage, the description is adequate but not complete. It should clarify what the country parameter expects (ISO code vs name) and whether the returned price is an estimate or final. As is, an agent has enough to call it but not enough to interpret results 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 67%, so the schema documents the 'gb' and 'currency' parameters, but 'country' has no schema description. The description mentions an optional gb value and 0.1 GiB billing steps, adding some semantics, but doesn't fully compensate for the country parameter gap. Baseline 3 is appropriate.

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

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

States a specific verb ('Price') and resource ('travel data for a country'), and distinguishes itself from home mobile service pricing. Separates from pricing siblings like get_data_rate and quote_call by its travel/eSIM framing, though it doesn't name those siblings explicitly.

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

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

Provides implied usage with 'Use this when a trip needs data and not a home mobile service,' which gives some context, but does not explicitly name alternatives like get_data_rate or quote_call, nor does it state when not to use the tool.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), and the description adds meaningful context beyond them: "No sign-in" (no auth required) and the explicit reassurance that this does not purchase the number. It doesn't mention rate limits or latency, but the key behavioral caveats are present.

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

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

Purpose and result are front-loaded, and the pricing-model sentences all earn their place. The middle is somewhat dense and could be tightened, but there is 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?

With no output schema, the description correctly states what is returned (monthly amount, whether local calls are included), and it explains the channel-pack pricing needed to call the tool correctly. Remaining gaps are the undocumented country/number_type value formats.

Complex tools with many parameters or behaviors need more documentation. 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% (currency and channel_count documented; country and number_type bare), and the description meaningfully compensates for the hardest parameter by explaining the 2-included / 10-per-pack model and what channel_count actually computes for a target like 15. country and number_type formats/values remain unexplained, so it isn't fully compensating.

Input schemas describe structure but not intent. Descriptions should explain 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 (price/quote) and resource (a Widely phone number) plus what the result contains (monthly amount, local-call inclusion). This clearly separates it from quote_call, quote_esim, quote_port and quote_service, though it doesn't explicitly name those siblings or how it differs from get_did_rate.

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

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

"Use this when a UK, US, Israeli, or other local number is needed" gives a clear when-to-use trigger, and "This does not purchase the number" sets an explicit boundary against acquisition. It stops short of naming the alternative quote/purchase tools to route to.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description still adds real value: the move is not instant, no sign-in is required, and crucially that this call does not start the move — a distinction an agent could easily get wrong.

Agents need to know what a tool does to the 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, all front-loaded, no filler. The telegraphic fragments ('No sign-in.', 'The move is not instant.') read abruptly but each carries distinct information, so little is wasted.

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

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

For a read-only quote with no output schema, the behavioral picture is adequate, but three of four parameters are undocumented in both schema and description, leaving an agent guessing at number/country/number_type formats.

Complex tools with many parameters or behaviors need more documentation. 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% (currency alone is documented), so the description carries the burden for number, country and number_type — and it supplies nothing beyond an implicit 'existing number'. 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?

States a specific verb and resource: pricing a port of an existing number onto Widely, with the scope qualifier 'moving an existing number' that separates it from new-number quoting siblings. It doesn't explicitly name quote_number as the 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?

Gives a clear selection condition ('Use this when the current number should be kept') and warns against the misconception that it initiates anything ('This does not start the move'). It stops short of naming the sibling to use for a new number or for actually starting the port.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds two useful behavioral facts beyond the annotations: the price is sourced from the offer, and no sign-in is required. It still omits error behavior (what happens for an ineligible offer/form-factor combination) and return shape.

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

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

Short and front-loaded, which is good, but 'for a form factor and number line that offer allows' is grammatically muddy, and 'This is separate from Widely travel data' is an unexplained aside that spends a sentence without earning it.

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

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

There is no output schema, so the description rightly says where the amount comes from ('The amount comes from that offer'), which partially covers the return value. But for a 4-param tool with 25% schema coverage, the missing explanation of offer_id and number leaves the definition incomplete.

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

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

Schema description coverage is only 25% (only number_line is documented, via 'regular or kosher'). The description gestures at form_factor and number_line but never explains offer_id, the required anchor for the whole call, nor the 'number' property. With low coverage the description should compensate, and it 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 recognizable verb+resource ('Price one listed home mobile service'), which is better than a tautology. However, among the many quote_* siblings (quote_call, quote_esim, quote_number, quote_port) the description gives no basis for telling them apart, and the closing sentence about 'Widely travel data' is unrelated and confusing rather than differentiating.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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' is the only usage-relevant statement; there is no when-to-use guidance, no prerequisites (e.g., needing a valid offer_id), and no mention of when to prefer this over quote_number or quote_call. The agent must infer everything from the schema.

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 safety profile is given. The description adds real context beyond that: deterministic ordering ('oldest first'), the permission model ('any connected account can read it'), and an explicit scope exclusion ('other chats are not included').

Agents need to know what a tool does to the 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 what is returned and the ordering, then permissions, then scope. No filler or repetition; 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, well-annotated read tool with a fully documented single parameter and no output schema, the description covers purpose, ordering, access, and scope. Only pagination/return-shape detail is absent, 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?

Schema coverage is 100% for the single 'limit' parameter, so the schema already documents it. The description adds nothing about limiting or pagination behavior, which is the correct baseline of 3 when the schema carries the parameter burden.

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

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

States a specific verb (returns) and resource (messages in this user's Support chat) plus an ordering guarantee (oldest first). The clause 'Other chats are not included' scopes it apart from thread/message readers, but it never names a sibling tool, so differentiation is implicit rather than explicit.

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

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

'Any connected account can read it' clarifies access but is not a when-to-use rule. There is no guidance on when to pick this over ask_support, search_help, or get_thread, leaving the agent to infer usage from the 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 readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description adds useful context that the refund goes to the card and is restricted to eligible first-eSIM top-ups, but it does not disclose non-idempotency risks or authorization requirements beyond what annotations 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?

Three short sentences, front-loaded with the core action and followed by input and return notes. It is efficient, though the final sentence 'Returns the refund result' adds little value.

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

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

For a financial mutation with no output schema and a required transaction_id, the description is minimally adequate. It omits eligibility details, error behavior, and idempotency context, relying on annotations for safety signals.

Complex tools with many parameters or behaviors need more documentation. 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 transaction_id parameter. The description partially compensates by clarifying that the input is the transaction_id of an eligible top-up, but it does not explain expected format or how to obtain a valid ID.

Input schemas describe structure but not intent. Descriptions should explain 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: refunding an eligible first-eSIM wallet top-up to the card. It is clear enough to distinguish from siblings like topup_with_saved_method and list_wallet_refunds, though it does not explicitly name alternatives.

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

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

Usage is implied by the word 'eligible' and the required transaction_id, but the description does not explain eligibility criteria, when not to use this tool, or point to alternatives such as list_wallet_refunds or topup_with_saved_method.

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, the description discloses the ringing sequence, wait-for-answer behavior, the same-conversation dialing, the resulting outgoing call, and that no destination is dialed if no phone answers. The annotations already cover safety and openness, so this is solid added context. It does not mention rate limits, billing, or concurrent-call behavior.

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

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

The description is short and front-loads the key action. Every sentence conveys useful behavior, though the fragment 'Pro plan.' and the standalone 'The user speaks on it.' make the structure slightly choppy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 tool with no output schema, the description covers the call flow, plan requirement, and no-answer behavior sufficiently. The schema handles identity_id details. It could be stronger by clarifying how this relates to call tasks or what happens if the user is already on a call.

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

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

Schema description coverage is 100%, so both parameters are already fully documented in the input schema. The description adds no parameter-specific meaning, such as identity_id constraints or destination format, beyond what the schema provides. 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?

The description states a specific two-stage action: it rings the user's phones first, then dials the destination into that same conversation. This distinguishes the tool from generic calling tools by describing the bridging flow. It does not explicitly name or contrast with siblings such as create_call_task, 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?

It notes the Pro plan prerequisite and the no-answer outcome, which gives useful context. However, it never says when to choose this tool over alternatives like create_call_task, request_speak, or other call-related siblings, leaving the routing decision 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?

Goes well beyond the annotations: it discloses that the call is asynchronous (returns immediately with task and call ids), that validation lists every missing and invalid field at once, that voicemail is the default, that only allowed_commitments may be agreed to, and that the assistant always closes with a thank-you and goodbye. These are exactly the operational traits an agent needs before invoking a long-running outbound call.

Agents need to know what a tool does to the 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-loads the core action and packs a lot of relevant constraint information into one dense paragraph with little waste. The terse 'Business plan.' fragment is slightly awkward but still informative.

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

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

With no output schema, the description helpfully states the immediate return (task and call ids) and key refusal/validation behavior for a complex nested-brief tool. It could go one step further by pointing to get_call_task/get_call for tracking the call, but it is largely complete for correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning about the brief's structure and the assistant_name resolution order (settings name vs brief.assistant_name) plus the allowed_commitments guardrail. It stops short of explaining the nested limits, escalation, or callback blocks, which the schema already covers.

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

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

States a specific verb and outcome: it dials a number and an AI assistant conducts the errand, with a clear constraint (Business plan, structured brief only). It does not explicitly distinguish itself from close siblings like request_call or create_call_task, leaving the agent to 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.