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

Annotations already declare the mutation profile (readOnlyHint=false, destructiveHint=true, openWorldHint=true), and the description adds genuinely new behavior: it is policy-gated, billed against the workspace balance, and returned fields (body, metadata, error, idempotency_key) require the sms:read scope even on replays. The auth-scope and billing disclosures are exactly the kind of context annotations cannot convey, though return/error semantics beyond scope are not covered.

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 dense sentences, front-loaded with the core action and billing, then the two clarifying constraints. It earns most of its space, though the parenthetical redirect to the purpose property is slightly redundant since that schema field is already verbose.

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 12-parameter mutation tool with no output schema, the description covers the behavioral and auth surface reasonably but leaves ten parameters effectively undocumented. It mentions return fields only to attach the sms:read requirement, not to explain what is returned, so an agent still lacks enough to call it fully informed.

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 25%, so the description should carry the parameter burden, but it only discusses two of twelve parameters (purpose and recipient_type) — and both already have detailed schema descriptions. Fields like from_phone_number_id, to_phone_number, relationship, user_requested, categories, and the nested user_authorization object get no treatment in either the description or a schema 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 ('Send a policy-gated outbound SMS') plus scope modifiers: sent from one of the workspace's numbers and charged to the workspace balance. This separates it from voice siblings like create_outbound_call, but it never names an alternative such as send_agent_template_message, so the 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?

The description says nothing about when to choose this tool over siblings such as send_agent_template_message or create_outbound_call, nor does it state any preconditions for sending. 'Policy-gated' hints that an outbound policy applies but gives no routing guidance, leaving usage entirely to inference.

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