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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, and the description adds real context beyond them: it discloses that in-flight (incomplete) generations are included in the result and that the returned ids are the handles other tools consume. It does not discuss result size or per-project scoping costs, but the output schema covers the return shape.

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?

A single dense sentence that front-loads the payload contents, then the id-routing value, then the default behavior. No filler, no repetition of the title.

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 an output schema present and rich annotations, the description only needs to establish scope and result character; it does that by naming the included entity types and the in-flight state. The only meaningful omission is any sense of result volume or whether the board can be large enough to warrant care, which for a single-project read tool is a minor gap.

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 single optional project_id is fully described in the schema as 'omitted, the active project.' The description restates the same default behavior without adding format or lookup guidance, so the schema is doing the heavy lifting and baseline 3 applies.

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?

Enumerates the concrete resources returned (mascots, props, poses, animations, in-flight generations) and frames the output as an id source for other tools, which clearly separates it from siblings like list_projects or check_generation. The read verb itself is carried by the name/title rather than the description, so it stops just short of a fully self-contained purpose statement.

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?

The clause 'Defaults to the active project' implies when this tool is the right call (the passive default read) and hints at select_project as the alternative for switching context, but neither is stated explicitly. No when-not-to-use guidance or named sibling alternative is given, so usage must be inferred.

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