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

Annotations already flag destructive/openWorld/no-idempotency, and the description adds genuinely new behavioral facts: opt-outs, missing marketing consent and topic unsubscribes are stripped before sending; dry_run returns count, cost, rejected rows and consent.no_opt_in; scheduled_at is capped at 30 days; quiet hours can block or defer; and a live key sends real messages.

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 dense sentences that lead with what the tool does, then filtering, then dry-run, then scheduling, ending on the live-key warning — good front-loading. Some clauses duplicate schema text (quiet_hours, scheduled_at) rather than adding new 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 14-parameter destructive send with no output schema, the description covers the things an agent must know before calling: who gets filtered out, how to validate safely, and the real-world consequence of a live key. The main residual gap (which recipient selector wins, and what a real send returns) is minor relative to what is disclosed.

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 71%, so the schema already documents most parameters (including from, tags, dry_run, list_id, topic_id, quiet_hours, check_line_types). The description restates and slightly enriches those (what dry_run returns, the 30-day cap, opt-out removal) but adds nothing for undocumented fields such as name, category enum consequences, or recipients.variables — and it omits list_id from its own recipient enumeration.

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 one message to many people (a broadcast or campaign)") and immediately scopes it against sibling send_message by emphasizing many-recipient broadcast semantics. The enumerated recipient-selection fields make the operation concrete.

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?

Rich operational context is present (dry_run for validation, scheduled_at window, consent filtering, live-key warning), but the description never explicitly routes the agent between this and send_message / send_verification, nor states mutual exclusivity between segment_id, tags, list_id, contact_ids and recipients. Usage is implied rather than prescribed.

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