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

Annotations already declare the safe read-only, idempotent, closed-world profile, so the description only needs to add context — and it does: authentication via POLYRANK_API_KEY, the SIMULATED nature of backtest/paper figures, and the meaning of queue_position and awaiting_backtests as live-state fields. It stops short of describing error behavior for unknown ids or how in-progress chats are represented.

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?

Front-loaded with the resource, then progressively disclosing field meanings and the simulation caveat. It is a bit of a run-on with backtick-laden clauses, but every sentence carries information an agent would otherwise lack.

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 usefully enumerates the response shape (status, questions, answers, notices, result cards, queue counters). The remaining gap is operational — how to obtain the id, what an error looks like, and whether large chats require paging via `last`.

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 50%: `last` is documented in the schema itself (last N messages, default all), while `id` is only implied by "one of your Lab assistant chats". The description reinforces that the tool returns a single chat, but adds no format or provenance detail for the id beyond what the UUID schema already imposes.

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 names a specific resource — a single Lab assistant chat — and enumerates its contents (status, questions, answers, notices, result cards). It is clearly distinguishable from polyrank_lab_ask and polyrank_lab_reply, though it never names the natural sibling polyrank_lab_list_chats.

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?

Usage is only implied: an agent must infer that this is the retrieval call once it has a chat id, and that list_chats is the way to obtain one. No explicit when-to-use or when-not-to-use statement, and no guidance on choosing `last` values or when to poll versus wait.

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