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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds value beyond that: the required `[conversations:read]` scope, the queue-change/restart behavior of the waiting mode, and the critical caveat that 'only `utterance` is speech' among message kinds — a detail an agent would otherwise get wrong. Pagination/resultCursor continuation mechanics are left to the schema rather than restated.

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 framing sentence followed by four tightly scoped bullets — front-loaded and scannable, with no filler. The repeated '[conversations:read]' tag on every bullet is redundant since the scope is uniform and could be stated once.

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 single-parameter tool with a large four-branch anyOf schema and an existing output schema, the description covers what is needed to choose a mode and call it. Continuation semantics (`resultCursor` repeated requests, concatenating content chunks) live only in the schema, which is a minor gap for a read tool that can paginate.

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?

Top-level schema description coverage is reported as 0%, so the description carries real burden — and it does explain the four `query` const values that discriminate the anyOf branches, plus the meaning of `cursor=start` and the existence of identity/time/assignment/handled filters. It does not explain `limit`, `resultCursor`, or the from/to exclusivity in prose, relying on nested schema text for those.

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 line names a specific verb and resource: 'Read a project's chat conversations and their messages.' Each of the four `query` modes is then stated with a distinct verb (waiting/list/get/messages), so an agent can identify the right mode without inspecting the anyOf 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?

Per-mode guidance is explicit: 'waiting' is for current waiting work in shared priority order with 'continue or restart when the queue changes', 'list' is for filtered traversal with 'cursor=start for complete creation-order traversal', and 'get'/'messages' are scoped to a single conversationId. It stops short of saying when *not* to use this tool versus the siblings (content_search, knowledge, widgets), so a 4 rather than a 5.

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