Estimate Message Blast

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuine context beyond them: consent semantics in EU jurisdictions ('consented counts only the clients who agreed'), SMS cost beyond the plan's free allowance, and the guarantee that nothing is sent. It could go further on return shape or error behavior, but it meaningfully supplements the annotations.

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 purpose is front-loaded in the first sentence, followed by a focused second paragraph on consent and cost. Slight redundancy between 'without sending it' and the closing 'Nothing is sent' keeps it from a 5, but every sentence largely earns its place.

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 read-only estimate tool with no output schema, the description explains what the caller receives (reach counts, per-channel send counts, SMS cost) and the consent nuance that changes the count. Minor gaps remain around invalid client IDs or partial failures, but the core call context is complete.

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 all three parameters are already documented, including that message length sets SMS parts and client_ids come from list_clients. The description echoes the same facts ('same clients, channel and text') but adds little new parameter-level meaning. Baseline 3 is appropriate when the schema does the heavy lifting.

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 (count/estimate) and resource (who a Message Blast reaches and its SMS cost), and immediately distinguishes itself from send_message_blast ('without sending it'). An agent can tell exactly what this tool produces versus its sibling without opening either schema.

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?

Explicitly frames itself as the dry-run counterpart to send_message_blast: 'Asks Booksy what send_message_blast would do with the same clients, channel and text.' The alternative is named and the condition that selects it (wanting to preview rather than send) is clear, reinforced by 'Nothing is sent.'

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