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

The description adds significant behavior beyond annotations: it mentions background preparation, subscriber-count calculation, provider readiness checks, durable acceptance semantics, and the need to reuse the idempotency key if the response is lost. The external-email effect and permissions are also explicitly called out, so the agent has a strong model of side effects.

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?

The description is compact and front-loaded with the core behavior, but it repeats the idempotency instruction twice: 'Reuse the same idempotency key...' and 'Retry with the same idempotency_key.' This slight redundancy prevents a perfect score, but overall it is still tight and information-dense.

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 complex side-effecting send operation, the description explains durable vs. provider delivery, asynchronous preparation, idempotent retry, external-email effect, required permissions, and API reference. Combined with a fully documented schema and adequate annotations, this is sufficient for an agent to invoke the tool safely.

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 schema already documents all parameters well. The description adds useful semantic value by explaining why and when to reuse idempotency_key, which complements the schema's length validation and optionality. It also relates preflight behavior to the send flow, though the schema already covers preflight_proof details.

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 clearly states this tool 'Immediately creates durable preparation for a broadcast draft or scheduled send' and distinguishes it from other broadcast tools by emphasizing the real external-email effect and asynchronous 202 acceptance. This separates it well from broadcasts_send_test, broadcasts_schedule, and broadcasts_preflight.

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 gives usable context: it is for sending now, it returns 202 on acceptance, and delivery is not yet complete at that point. It does not explicitly name alternatives like broadcasts_send_test or broadcasts_schedule, but the immediate-send framing makes the intended use reasonably clear.

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