Send bulk message

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

Annotations already mark the operation as non-read-only, non-idempotent, and non-destructive, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: scheduling, UTM marks, dispatch routing cascade, Telegram usernames and tdlib user IDs, and the implication that bulk sends do not return a delivery ID for tracking. Minor caveats such as cost, rate limits, or failure handling are not disclosed, so it stops short of 5.

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: a clear first sentence stating the core action, a feature-support list, and then usage guidance with a routing instruction. Every sentence earns its place; no filler or redundant restatement of the title.

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 tool with eight parameters and no output schema, the description covers purpose, typical usage, and the key limitation around delivery tracking. It is slightly incomplete on what the caller should expect back from a bulk send, but the explicit redirect to send_message when tracking is needed mitigates that gap.

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 100%, so the input schema already fully documents all eight parameters, including formats, constraints, and relationships like 'requires "tdlib" in dispatch_routing.' The description only summarizes feature areas rather than adding meaning beyond the schema, making the baseline 3 appropriate.

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 opens with a specific verb and resource: 'Send the same message to multiple phone numbers at once.' It clearly differentiates from send_message by emphasizing bulk recipients and also names the sibling it should not be used for ('For one recipient... use send_message').

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?

It gives explicit use cases ('announcements, campaigns or reminders to a list of recipients') and an explicit exclusion with alternative: 'For one recipient, or when a delivery ID is needed for tracking, use send_message.' This leaves no ambiguity about when to choose this tool over its sibling.

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