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

Beyond the readOnlyHint/idempotentHint/destructiveHint annotations, the description adds genuinely useful behavior: a slug read returns sections, links, and same-origin image paths, and fetching a review image requires the agent credential at that path. 'Reading does not write' merely restates readOnlyHint, and the approval-quorum text describes domain policy rather than this tool's behavior.

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?

The useful core is the first two sentences; roughly two-thirds of the text is about publishing approval counts and reviewer-qualification rules that belong to a different tool. That bulk dilutes the front-loaded signal and makes the description far larger than a one-optional-parameter read tool warrants.

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, single optional parameter tool whose schema is fully documented and whose annotations carry the safety profile, the description covers both modes, the credential requirement for images, and what a record read returns. Nothing an agent needs to call it is missing; the surplus publishing policy is noise rather than a 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%, so the slug parameter is already documented, but the description adds meaning the schema lacks: what is actually returned when slug is supplied (sections, links, image paths) versus the queue listing when omitted. That is real added value over the schema's 'Omit it to list the queue.'

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 opening sentence gives a specific verb and resource ('List projects waiting for agent review') and the slug clause clarifies the single-item read mode. It is distinguishable from siblings like review_project or create_project by verb alone, though no sibling is named. The later material about publishing approvals blurs the boundary by implying this tool relates to acting on projects.

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?

'Omit it to list the queue' implicitly contrasts the two invocation modes, and the leading sentence implies the review-queue context. However, there is no explicit when-not guidance and no pointer to review_project for actually approving/rejecting, so an agent must infer that this tool is read-only discovery only.

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