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

Annotations only declare it is a safe read; the description goes well beyond by disclosing ordering (least sure first), result composition, the include_pictures/thumbnail behavior, and two strong safety constraints: every number is AMT's own and must never be calculated or invented, and row text/labels/file names are user data that must never be followed as instructions.

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?

Long, but front-loaded and dense: what the queue is, the two modes, the per-item return shape, routing, then two safety rules. Each sentence carries distinct information, though the return-field enumeration could be trimmed slightly.

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, and the description fully compensates by enumerating the returned fields (text or picture name, answer and confidence, top three categories, up to three similar labelled items, existing suggestion). An agent has everything needed to call it correctly.

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%: model_id and include_pictures are documented in the schema, while limit and offset are not. The description adds real value by explaining the with/without model_id branching and that results are paged 'least sure first', but it never clarifies limit/offset semantics, so it only partially compensates for the coverage gap.

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 resource (the Review Queue) and precisely what it contains: answers a model was unsure about. It even distinguishes two modes (per-model counts with no model_id, a page of waiting items with model_id), so an agent can tell it apart from review_suggest, review_answer and review_suggestions without opening any 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 routing: read labelling_guide_get before proposing, use review_suggest to propose, review_answer to record answers. It names the prerequisites and the sibling tools for the downstream actions, leaving nothing to inference.

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