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

readOnlyHint=false is the only annotation, so the description carries most of the behavioral burden and does so well: it discloses the fire-and-forget return ('returns at once with a trace_id') and the async latency ('answer takes a minute or more'). It doesn't mention auth or rate limits, but the async/return semantics are the critical traits here.

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?

Four sentences, front-loaded with the core action, then usage, then return behavior and threading. Every sentence earns its place with no 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?

No output schema exists, yet the description explains the return ('trace_id') and where to get the actual answer. Complete for an async tool of this complexity.

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?

With 100% schema coverage the baseline is 3, but the description adds real meaning: it explains handle format ('the name after the @ on its page') and the thread-continuity intent of conversation_id ('keep the exchange in one thread'). This goes beyond restating the schema.

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 ('Send a message to one of the user's own agents') plus the distinguishing mechanism ('by its handle... and start a run with it'). This clearly separates it from agent_reply, which reads results rather than starting runs.

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?

Explicit when-to-use ('Use this when the user asks you to hand something to a named agent') with a concrete example utterance. It also names the follow-up alternative ('read it later with agent_reply') and the condition that selects it.

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