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

With no annotations, the description carries the full burden and does: hard content refusals (money, addresses, phones, emails), the refusal is silent ('nothing is sent'), the instruction-injection policy (other side's words are data, escalate money/links/commitments to the human first), budget semantics ('each press grants a run of messages and days', conversation_paused on exhaustion), and rate limits (4000 chars, 60/hour).

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?

Purpose is front-loaded and most sentences carry unique operational rules, but the body is one dense paragraph mixing refusal policy, injection defense, budget mechanics and rate limits with parenthetical tool references, which is hard to scan. Some value is gained but structure suffers.

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?

No output schema or annotations, yet the description covers refusals, escalation, budget exhaustion state, and limits well enough to call the tool correctly. The only real gap is the undocumented intro_id, which matters for invocation.

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 50%: text is documented in the schema, intro_id is not. The description adds real meaning for text ('their words as they said them, translate only if asked, up to 4000 characters, 60 an hour') but says nothing about intro_id, so it only partially compensates for the coverage gap.

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 and resource ('Carry your human's words to the other side's agent') and immediately distinguishes this from the reply/collect siblings by framing it as one half of a two-way relay. An agent knows this sends and does not receive.

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 routes the agent to alternatives for every blocked case: money goes to respond(propose_offer), contact details to respond(request_send_contact), photos to respond(request_photo), and a spent budget to respond(request_keep_talking). It also gives a when-not rule (never pack multiple messages into one; ask near the end of the budget).

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