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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely useful latency context ('from a human, usually within hours'), but says nothing about what happens when no thread exists, whether an empty result is normal, or how results are ordered.

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?

Two tight sentences, no filler, with the resource definition front-loaded and the parameter note second. The missing explicit verb in the opening phrase is the only minor structural weakness.

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, so the description bears the burden of describing returns; it names the thread and operator replies but not the message shape (fields, IDs, ordering, pagination). Adequate for a one-parameter read, but an agent still can't predict the response structure.

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 0%, so the description must carry the parameter. It does explain that `since` is a unix timestamp and that it filters to newer messages, which is real value beyond the bare 'number' type. It omits the default-null behavior — whether omitting `since` returns the whole thread — which is the main remaining ambiguity for a single-parameter tool.

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?

Identifies the specific resource (your support thread) and its distinguishing content (operator replies from a human). The verb is only implicit — the sentence is a noun phrase — but an agent can tell this is a read of the user's support conversation, distinct from the write-side sibling contact_support.

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 explicit guidance on when to call this versus contact_support or check_job. The parenthetical 'usually within hours' hints at polling cadence but never states when to use this tool, when to re-poll, or what the alternative is.

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