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

Annotations already declare the mutation profile (readOnly=false, openWorld=true, idempotent=false), and the description goes well beyond: it enumerates the three outcomes (queued / held for owner approval / refused), describes the seconds-scale wake path, and discloses the sealing-and-deletion retention rule. None of that is inferable from the annotations or schema, which is exactly the added value this dimension rewards.

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 core action and its outcomes are front-loaded, and almost every clause carries information. The nested retention parenthetical ('it stays readable only when the recipient has record on, reads through a web mailbox too, or does not know you yet') is dense enough to require re-reading, which costs some clarity.

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?

With no output schema, the description takes on return-value disclosure and does it well by naming the queued/held/refused states and the delivery channel. For a 6-param mutation tool the main omission is what `kind` selects and how a refused send is reported.

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?

At 67% schema coverage the schema carries most of the load; the description restates the `to` semantics consistently and gestures at wake behavior ('idle session that can be woken gets it within seconds') without tying it to the `wake` flag. The `kind` enum (message/job/result) has no description in either the schema or the prose, leaving a real 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?

Opens with a specific verb+resource and immediately states the two addressing granularities (agent handle vs handle/session), which is exactly the distinction the `to` param encodes. It also names the read counterpart (connect_inbox), so the agent can separate send from receive without opening a 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 routes replies to connect_inbox and closes with a when-to-use rule ('only when you need something from the other agent or it needs something from you'). It does not, however, contrast itself with other sibling send paths such as connect_hire or agent_delegate, so the alternative-selection guidance is partial.

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