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

Annotations already declare mutating-but-not-destructive, idempotent, and closed-world. The description adds only the hint that only privacy-filtered project metadata flows through. It does not disclose optimistic concurrency (expectedVersion) failure behavior, the meaning of 'delivery' (retry? ack?), or whether updates are partial. Fine but thin given annotations.

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?

One sentence, front-loaded with the verb. Efficient size, though it substitutes hedge words ('hosted', 'privacy-filtered') for actual meaning.

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 7-parameter, nested-object mutation with no output schema and concurrency control, the definition is borderline. The schema carries parameter docs and annotations carry the safety profile, but an agent still can't tell what a successful 'delivery update' changes or when the handoff record transitions state.

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 100%, and the schema already explains details, idempotencyKey, and expectedVersion. The description's phrase 'privacy-filtered project metadata' loosely gestures at the 'details' object but adds no semantics beyond it; it does not warn that the schema's own descriptions appear copy-pasted across every ID field.

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 restates the tool name ('Update hosted record chat handoff delivery') and adds only a vague qualifier ('using privacy-filtered project metadata'). It never explains what is actually being updated (delivery status? handoff record?) and gives no hint of which sibling it complements, like create_chat_handoff.

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?

No when-to-use context is given. It doesn't say whether this is meant to be called after create_chat_handoff, on retry, or by a delivery worker, nor what distinguishes it from update_* siblings like update_report or update_queue_item.

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