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

No annotations are provided, so the description carries the full behavioral burden. It does not say whether the text is spoken to the caller, whether the call is blocked or paused while waiting, whether the answer is terminal for that question, or whether multiple answers are allowed — all critical for a mid-call interaction tool.

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

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

Two short, front-loaded sentences with no filler; the purpose comes first and the non-obvious parameter mapping second. It is efficient, though the extreme brevity is part of why other dimensions fall short.

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

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

An output schema exists, so return values need not be explained, but for a mutation-style mid-call action with no annotations and 0% parameter coverage the description leaves too much unsaid: the effect of 'text', the meaning of call_id, and the interaction with wait_for_event/send_instruction are all absent.

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

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

Schema description coverage is 0% and all three parameters are required, yet the description only clarifies question_id ('the event's seq'), which is genuinely valuable non-obvious information. call_id and text remain completely undefined, so two of three parameters get no semantics from either schema or 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 ('answer') and a well-scoped resource ('a question the voice agent asked mid-call'), which is far more informative than the bare name 'answer'. However, it never distinguishes itself from the adjacent sibling send_instruction, which an agent could plausibly pick for the same intent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 'a question the voice agent asked mid-call' implies the trigger condition (a question event arrives during a live call), but there is no explicit when-to-use statement, no mention of the wait_for_event/get_call workflow that would surface such a question, and no exclusion relative to send_instruction.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the human-approval gate, but says nothing about irreversibility, external side effects (actually placing a phone call), failure behavior, or what the response contains.

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

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

Two short sentences, zero waste, with the core action front-loaded and the constraint immediately after 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?

An output schema exists so return values needn't be described, and the approval precondition is covered. What remains thin is the parameter's meaning and the consequences of dialing (cost, irreversibility), which matter for an outward-facing action with no annotations.

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

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

The single parameter call_id has 0% schema description coverage and the description never mentions it or clarifies that it must reference an existing draft. The phrase 'a drafted call' hints at the link, but nothing states the ID's origin or format.

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

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

States a specific verb (Dial) and a specific resource (a drafted call), and the qualifier 'drafted' ties it to the draft_call sibling, so an agent can distinguish it from draft_call, rehearse_call, or get_call without opening a schema.

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

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

'Only use after the user approved this specific draft' is an explicit, unambiguous gating condition that tells the agent both when to invoke it and when not to. This is exactly the kind of prerequisite an agent needs for a side-effecting action.

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

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

With no annotations, the description carries the full behavioral burden and does well: it discloses the return payload (call id, normalised number, opening line, briefing), the critical consequence that omitting voicemail makes the agent hang up, and the progress-event toggle. It omits auth requirements, idempotency, and whether the draft expires or must be confirmed.

Agents need to know what a tool does to the 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 is front-loaded, then behavior and field semantics follow in a logical order without padding. It is dense but every sentence conveys operational information rather than restating the name.

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

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

An output schema exists, so the return-value detail is a bonus rather than a necessity. For a 10-parameter mutation-ish tool with zero annotation and zero schema-description coverage, however, half the parameters (principal, facts, region, language, must_not) are left unaddressed.

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

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

Schema description coverage is 0% across 10 parameters, so the description must compensate, and it only explains voicemail, topic, and progress in depth. Facts, principal, region, language, and must_not receive no semantic guidance, though 'to' and 'goal' are inferable from the purpose statement.

Input schemas describe structure but not intent. Descriptions should explain 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 opening verb+resource+scope, 'Prepare a call without dialling', is precise and immediately signals this is a pre-dial stage. It implicitly separates the tool from confirm_call's dial action, but no sibling is named explicitly, so the differentiation is inferred rather than stated.

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

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

The 'without dialling' framing implies this is the step before confirm_call, and the voicemail warning implies when the field is needed. However, the description never names an alternative or states an explicit when/when-not condition, leaving the workflow position 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?

With no annotations, the description carries the behavioral disclosure burden. It usefully states that the draft is not modified and remains confirmable, but it omits other relevant traits such as idempotency, permissions, or what happens to the rehearsal session itself.

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

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

Two short sentences, front-loaded with the core action, that contain no filler. The key behavior follows immediately, making the description efficient and easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 output schema covers return values and the operation is simple, but the description omits parameter semantics and usage alternatives. With no annotations and zero schema description coverage, those gaps leave the definition only minimally complete.

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

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

Schema description coverage is 0%, and the description never mentions the sole required parameter 'call_id'. It adds no meaning beyond the bare schema title, leaving the agent without guidance on what identifier to supply.

Input schemas describe structure but not intent. Descriptions should explain 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 ('End a rehearsal'), which distinguishes it from confirming or drafting. However, it does not explicitly name a sibling alternative or clarify its relationship to rehearse_call/confirm_call, so it falls short of the top score.

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

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

The description implies a consequence ('draft stays unchanged and can still be confirmed') but gives no explicit when-to-use guidance or named alternatives. An agent must infer that confirm_call is the tool to use for confirming rather than ending.

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

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

No annotations are provided, so the description carries the full burden. It does disclose one genuinely useful behavioral trait: `cost` is only populated once the call has ended, which tells the agent the field may be empty mid-call. It says nothing about auth requirements, error behavior, or transcript availability timing, so the coverage is partial rather than complete.

Agents need to know what a tool does to the 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 returned fields, and the second sentence spends its words on the non-obvious cost breakdown. The nested parenthetical is slightly dense but nothing is wasted.

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

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

With an output schema present, explaining return fields is partly redundant, so the real added value is the cost-timing nuance. Missing usage guidance and any parameter context leaves it adequate but not complete for a tool whose semantics are otherwise obvious.

Complex tools with many parameters or behaviors need more documentation. 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 call_id is never mentioned in the description, so no meaning is added beyond the schema. The parameter is self-evident, which softens the gap, but the description contributes nothing to it.

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

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

The description names the resource (a call) and enumerates what the caller gets back: status, duration, transcript and cost. It reads as a retrieval tool and is clearly distinct from the plural list_calls and the action siblings (answer, end_rehearsal), though it never states the verb 'get' or explicitly contrasts with list_calls.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 alternatives such as list_calls, nor any prerequisite (e.g. needing a known call_id). Usage is only inferable from the name and the returned fields.

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

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

No annotations are provided, so the description carries full burden. It states ordering ('newest first') but says nothing about pagination behavior, default limit semantics, recency/scope of 'recent', or return shape – despite an output schema existing, behavior beyond the return shape (e.g., does it paginate? is it scoped to a session?) is undisclosed.

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

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

It's a single short clause with no waste, which is good, but it is an incomplete sentence fragment rather than a front-loaded full purpose statement. Concise but under-specified rather than tight.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 listing tool with an undocumented limit parameter and no annotations, the description is too thin. It gives ordering but omits scope, pagination defaults, and what the agent should do with results – not enough for reliable invocation despite the output schema covering return shape.

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

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

Schema coverage is 0% and the single 'limit' parameter (default 20) is undocumented in either the description or the schema. The description does not explain what limit does, its default, or bounds. With one parameter at 0% coverage, the description should compensate but adds nothing.

Input schemas describe structure but not intent. Descriptions should explain 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 'The user's recent calls, newest first' is a noun phrase that restates a resource but does not state a verb or action. It's not a full purpose statement – the action ('list/retrieve') must be inferred from the tool name. It's not tautological but it's a fragment, not a clear purpose.

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

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

No guidance on when to use this tool versus siblings like get_call or the rehearsal/draft tools. The ordinal hint 'newest first' implies a browsing use case but the description doesn't state when an agent should prefer this listing over fetching a specific call. 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?

With no annotations, the description carries the full burden and does well: it discloses that the real agent runs with the real briefing, that the mode is text, and that nobody is actually called — important safety-relevant context. It omits lifecycle details such as how the rehearsal ends (end_rehearsal) or whether state persists.

Agents need to know what a tool does to the 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 in the first clause, then gives the operational workflow. Dense but each sentence earns its place; the parenthetical about events_after is slightly compressed but functional.

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

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

An output schema exists and the description explains how to consume its events, so return values need not be restated. It covers start-of-rehearsal and the interaction loop, but not how the rehearsal concludes, which an agent must learn from end_rehearsal.

Complex tools with many parameters or behaviors need more documentation. 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 call_id has no schema description, but the description's framing ('a drafted call') makes the parameter's role inferable as the id of the drafted call. With a single trivial parameter, this is adequate but adds no explicit format or sourcing detail.

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

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

States a specific verb and resource ('Start a rehearsal of a drafted call') and immediately scopes it as text-only with no real call placed. This clearly separates it from siblings like confirm_call (real call) and rehearse_say (mid-rehearsal reply).

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

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

Explicitly routes the agent to the follow-up tools: read agent output with wait_for_event (passing returned events_after as after) and reply with rehearse_say. It stops short of stating when to rehearse instead of placing a real call (e.g., before confirm_call), so it is clear context but not full when/when-not guidance.

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

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

No annotations are provided, so the description carries the full burden. It hints that this is a simulation via 'rehearsal' and specifies the caller's role, but says nothing about side effects, whether the agent responds, permissions, or reversibility.

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

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

A single tight sentence with no padding, front-loaded on the action. It is efficient, though its brevity borders on under-specification rather than being a structural flaw.

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

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

An output schema exists, so return values are covered, and two required params need guidance. With no annotations and 0% parameter coverage, the description leaves too much unstated for a multi-agent rehearsal tool that sends a message.

Complex tools with many parameters or behaviors need more documentation. 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 schema gives only bare titles 'Text' and 'Call Id'. The description implies text is the utterance and call_id identifies the rehearsal but adds no format, constraints, or meaning beyond that obvious mapping.

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

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

States a specific verb (say) and scopes it to a running rehearsal and a role (the person being called), which distinguishes it from rehearse_call and end_rehearsal. However 'say something to the agent' remains slightly abstract about the actual effect.

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

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

'In a running rehearsal' implies the prerequisite that a rehearsal must already be active, which is useful context. It does not explicitly name alternatives or state when-not to use it versus sibling tools like answer or rehearse_call.

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

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

With no annotations, the description carries the full burden and delivers the key async trait: delivery is not immediate, it lands on the agent's next tool call or at latest before hangup. That is genuinely useful behavioral context. It still omits permission requirements and behavior when the call has already ended.

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

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

Two sentences, front-loaded with the action and immediately followed by the timing caveat. Every clause earns its place with no filler.

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

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

An output schema exists so return values need not be explained, and the delivery semantics are covered. However, with 0% parameter description coverage and no annotations, the definition leaves call_id/text semantics under-specified for a two-required-param tool.

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

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

Schema description coverage is 0% for both call_id and text, so the schema documents nothing. The description implies 'text' is the instruction and 'call_id' targets a running call, but adds no format, length, or identification detail to compensate for the gap.

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

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

States a specific verb+resource: 'Queue a follow-up instruction for a running call.' An agent can tell it apart from siblings like draft_call, confirm_call, or answer, though it doesn't explicitly name the differentiating sibling.

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

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

The phrase 'for a running call' implies the precondition (call must be in progress), but there is no explicit when-to-use vs alternatives guidance and no when-not conditions, so 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?

With no annotations, the description carries the full burden and does disclose the important traits: a bounded blocking wait (timeout), an empty-list return rather than an error on no activity, and the loop-termination condition. It omits auth requirements, whether the wait is a true long-poll versus sleep, and concurrency caveats, so it is good but not exhaustive.

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

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

Three tight sentences, front-loaded with what is being waited on, then the parameter contract, then the return/loop semantics. 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 3-parameter polling tool with an output schema, the description covers the essential loop contract and return-on-empty behavior; because an output schema exists it need not detail the event payload shape. Only the call_id semantics and any failure behavior are unaddressed.

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

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

Schema description coverage is 0%, so the description must compensate, and it does for two of three parameters: timeout is in seconds and after is the highest seq already seen (with a default implied by the polling loop). call_id is never explained, though its meaning is inferable from the resource context.

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

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

Specific verb (wait) plus resource (new events on a call) and an enumeration of the event kinds that can arrive (questions, progress reports with stage/note, call ended). It is unmistakably a long-poll primitive rather than a state read, though it never names a sibling (e.g. get_call) to sharpen the boundary.

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

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

Gives concrete operating instructions: pass the highest seq seen so far as after, expect an empty list when nothing happened, and re-call until status is 'done' or 'failed'. That is clear when-to-use guidance for the polling loop, but no alternative tool or condition for preferring get_call over waiting is mentioned.

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