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

Goes well past the annotations (readOnlyHint=false, destructiveHint=true, openWorldHint=true) by disclosing rate limits (10 private calls per rolling 24h), per-minute billing, the verified/enabled Caller ID prerequisite, carrier-refusal failure behavior with no platform-number retry, idempotency-key reuse, and the redial policy distinguishing terminal no-answer/busy from a failed result.

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 purpose and confirmation prerequisite, then arranged by prerequisite, alternatives, failure mode, limits, and retry policy. Dense but each clause carries operational weight; the verification/caller_id_status aside and the redial paragraph are slightly longer than strictly needed.

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, billed, outbound-calling tool with 9 parameters, it covers the confirmation gate, auth prerequisites, rate limits, idempotency, retry semantics, and sibling routing. Return values need not be described since an output schema exists and wait_seconds/wait_for_call behavior is addressed.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds semantic distinctions the schema does not: original_message is the user's unedited request while message is the faithful sentence spoken aloud, both screened; and idempotency_key must be reused to recover the same attempt rather than place a second call.

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

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

Opens with a specific verb and resource: "Call one private person and relay one message from the user." It explicitly bounds scope ("not an open-ended conversation or a broadcast tool") and names the sibling it must not be substituted for ("Never substitute call_business for a private recipient"), so the agent can route between call_person, call_business, and call_me without opening schemas.

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

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

Gives explicit preconditions (confirm recipient, E.164 number, exact spoken message, then set user_confirmed=true), names alternatives with selecting conditions (caller_id_status for readiness, call_me for a receiving number, wait_for_call for in_progress), and defines when a retry is and is not permitted. Both when-to-use and when-not-to-use are covered.

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