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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds substantial context beyond that: it is a snapshot, recordings can take hours, partial results are surfaced via an errors array with null/missing parts while the rest stays accurate. This is genuine behavioral disclosure not present in structured fields.

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 purpose, then output shape, then usage semantics, then the polling caveat. Despite its length, each segment carries unique information an agent needs, and the ordering puts the most decision-relevant content first.

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?

There is no output schema, so the description carries the full return-value burden and does so thoroughly: it enumerates the usage object, row fields, the kind:'run' case with no project_id, and the errors structure. Nothing an agent needs to interpret results or call correctly is missing.

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%, so the baseline is 3; the description goes beyond by spelling out the state semantics shared with the enum param (pending waits for a free slot and self-starts; in_progress/done/failed) and by defining row ordering (in-progress first, then most recent). It doesn't add syntax for limit or project_id, so it lands just above baseline rather than a 5.

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?

States a specific verb+resource (status of this workspace's auto-recordings) plus the generations-usage angle, and anchors it concretely to 'the same view as the Recordings page in the Clueso app.' An agent can distinguish it from sibling read tools like get_project or check_uploads without opening the 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?

Explicit when-to-use guidance: 'check once after record_screen, then again when the user asks,' and an explicit when-not with rationale: 'do not poll in a loop.' This routes the agent correctly relative to the record_screen sibling and sets the snapshot expectation.

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