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

Beyond the annotations (readOnly=false, destructive=true, openWorld=true), the description discloses non-obvious behavior: the tool sends a real message to a real person, requires an explicit confirm gate, and automatically appends a Lodestone signature line on the Free plan. That footer behavior is critical context an agent could not infer from structured fields.

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 warning is front-loaded in brackets, followed by the core action, prerequisites, and one non-obvious system behavior. Every sentence contributes necessary information and there is no wasted phrasing.

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 destructive send tool with no output schema, the description covers the essential scope: what it does, who it affects, required preconditions, the confirm gate, and an automatic footer side effect. Nothing critical for correct invocation is missing.

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 baseline is 3. The description adds value beyond the schema by emphasizing the confirm:true safety gate and by warning the agent not to add the signature line into the text parameter, which directly affects how text should be filled.

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 opening bracket states the operation type and real-world consequence, then names the specific verb and resource: sending a text message to a Beeper conversation. The Beeper qualifier distinguishes it from sibling senders like telegram_send_message and email_send without needing to name them.

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 preconditions — read the thread first and confirm the exact text with the user — and reinforces the confirm gate. It does not explicitly name sibling alternatives or state a when-not-to-use case, so it falls short of the full 5 criteria.

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