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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the 'Read-only; nothing is changed' sentence largely restates structured data. The description does add real value by disclosing the filtering rule for what appears in the result set (only active products missing one of the three fields), but says nothing about ordering, volume, or limits.

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?

Two short sentences, with the substantive scoping rule front-loaded before the safety note. The trailing 'Read-only; nothing is changed' clause is mildly redundant given the annotations, which keeps it short of a perfect score.

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 are no parameters and no output schema, so the description has to carry the whole payload of what the tool returns, and it does define the returned set precisely. It stops short of describing ordering or result size, which an agent would need to reason about handling the output.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No parameter meaning is lost because none exist.

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 (list) and a precisely scoped resource (active products missing a description, image, or allergen declaration). The 'lack a usable X' filter makes it immediately distinguishable from siblings like get_restaurant_menu or search_products, so an agent can select it 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?

The audit use case is implied clearly by the 'lack ...' framing, but the description never states when to reach for this over get_restaurant_menu, search_products, or list_public_menus, nor does it point to draft_product_description as the natural follow-up for fixing the gaps it finds.

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