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

With no annotations, the description carries the full burden and does so excellently. It discloses asynchronous sending, immediate return, recipient skipping for opt-out/bounce (with 'skipped' logging), and tracking via provider webhooks. This gives a clear picture of side effects and timeout behavior.

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 three sentences, each earning its place: the action, the side effects/skipping behavior, and the status/confirmation/tracking guidance. It is front-loaded with the core purpose and contains no filler or redundancy.

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?

Given the tool's moderate complexity and lack of output schema/annotations, the description is remarkably complete. It covers prerequisites (draft/scheduled status), behavioral side effects (asynchronous, skip logic), required confirmation, and post-invocation tracking via a sibling tool. An agent has enough context to invoke correctly and know what to expect.

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 description coverage is 0%, so the description must compensate. It adds the critical requirement 'Requires confirm: true', which the schema alone does not convey. However, orgSlug, campaignId, and apiKey are left to self-explanatory names, and the description doesn't elaborate on them further. The confirm requirement adds meaningful value, but overall parameter semantics are only partially compensated.

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 the tool 'Execute a draft or scheduled campaign' and 'Sends messages to all matching recipients asynchronously', which is a specific verb+resource scope. It distinguishes from siblings like comms_get_campaign and comms_send_message by focusing on bulk campaign execution and explicitly referencing comms_get_campaign for tracking.

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 provides clear usage context: 'Campaign must be in draft or scheduled status' and 'Requires confirm: true'. It explicitly names comms_get_campaign as the tool for tracking progress, serving as an alternative. It doesn't explicitly state when not to use it, but the constraints are clear enough for an agent to decide.

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