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

Annotations already establish readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely useful behavior beyond that: the ordering/prioritization logic (issue severity, simulation evidence strength, wait time, agent run volume) and that the most impactful items come first. It does not mention pagination or default/max limits in prose, but the schema's limit param covers that.

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?

Three sentences, front-loaded with the core definition before ranking detail and intent examples. No filler, though the quoted-questions sentence partially restates usage already implied by the first sentence, keeping it just shy of maximally tight.

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?

For a read-only, zero-required-param listing tool with annotations covering the safety profile and no output schema, the description supplies what an agent needs: content, ordering rationale, and intent mapping. The only minor gap is not clarifying how it differs from the adjacent queue/approval tools, which the sibling list makes relevant.

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 description coverage is 100%, so all three params (limit, agentId, customerId) are already documented, including the superadmin-only note on customerId. The description adds no parameter-specific meaning beyond the schema, which is the correct baseline-3 outcome when the schema does the heavy lifting.

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 states a concrete verb+resource: a prioritized list of pending optimization PRs/deployments needing human review, and it specifies scope (human review, optimization artifacts). It stops short of differentiating from closely related siblings like get_adjudication_queue, list_pending_approvals, or get_review_case, so the agent must infer the boundary. Clear but not fully disambiguated.

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?

It gives clear usage context by enumerating the user intents it serves ('what should I review?', 'any pending PRs?', 'what needs my attention?'). This frames when to reach for it, but it names no exclusions or alternative tools for the many adjacent queue/approval siblings, leaving the when-not boundary unstated.

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