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

Annotations already mark this as destructive, non-idempotent, closed-world; the description adds substantial context they cannot convey — live calls to real people, calling-window and compliance enforcement, AI-minute consumption (cost), that the attestation is legally recorded under the acting user with a timestamp, and that refusals abort with an explanation. (One nuance worth noting: outbound calls to real people borders on 'open world', yet openWorldHint is false — not a direct contradiction of the description's claims, but an inconsistency an agent might trip over.)

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 action and its effect, and every clause about compliance, minutes, and refusal is load-bearing. It loses a little to redundancy around consent_attested ('must be true', 'it is a legal statement', 'it is true only when the person launching has said so'), which restates the same point twice, and the parenthetical about scheduled_at is slightly tangled.

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, consent-gated mutation with no output schema, it covers effect, cost, legal basis, preconditions, and refusal behavior — nearly everything an agent needs. Gaps: no description of what a successful launch returns (campaign object? status only?), and no pointer to the preparation steps (add_voice_campaign_contacts, test_call_voice_campaign) that precede a real launch.

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 baseline is 3, but the description genuinely enriches consent_attested — it explains the legal meaning (TCPA/FCC 2024 ruling), that it is recorded with the user and timestamp, and that it may only be true if the launcher has actually asserted consent. campaign_id gets no added meaning, which is acceptable since the schema already points to list_voice_campaigns.

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

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

States a concrete verb (launch) and resource (voice campaign) and immediately defines the effect: the AI agent starts calling its contacts for real, or becomes 'scheduled' if scheduled_at is set. The 'for real' framing plus the note that only draft or scheduled campaigns qualify implicitly separates it from test_call_voice_campaign, resume_voice_campaign, and pause_voice_campaign.

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 preconditions (campaign must be a draft or scheduled) and explicit failure conditions (no consent, invalid contacts, line unable to call, minutes cap) with the guarantee that nothing starts on refusal. What it lacks is direct routing to siblings — it never says to use test_call_voice_campaign first or resume_voice_campaign for a paused campaign.

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