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

Annotations already declare this a read-only, idempotent, non-destructive, closed-world operation, so safety is covered. The description goes further by disclosing a hard capacity limit (at most 5000 records per call), the validation problems it surfaces (full-text exclusions without a reason, pending full-text decisions, duplicate ids), and the concrete return payload shapes (PNG/SVG/links, counts, CSV for the appendix). That is meaningful behavior beyond the annotations, though error handling and pagination/overflow behavior are not described.

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?

It is a dense single paragraph, but the purpose is front-loaded and each subsequent sentence adds a distinct fact: row shape, derived counting/grouping, returned artifacts, reviewer-facing validation, optional identification input, and the size cap. No sentence is pure filler, though the length sits at the upper end of comfortable for a tool description.

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 nested-schema tool with an output schema, the description covers the essential agent-facing unknowns: input row semantics, output artifacts and their formats, validation feedback, and the record cap. It does not explain what happens past the 5000-record limit or how diagram links are scoped, which are minor gaps given the output schema carries return details.

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 67%, so a baseline of 3 applies and the description must add value. It does: it explains the row model (one row per record, title/abstract decision, full-text decision only for records that passed, a reason per exclusion) and clarifies that the identification counts fill in the top of the diagram, which is semantics the schema only partially captures. It stops short of documenting the optional 'footnotes' flag or a few identification sub-fields.

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 opens with a specific verb and resource: turning screening decisions into PRISMA 2020 counts, a flow diagram and a screening log. It is far more concrete than a restatement of the title. However, it never differentiates itself from the sibling prisma_flow_diagram, which sounds like it targets the same artifact, so an agent cannot fully disambiguate without opening both schemas.

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 description implicitly defines the entry condition (you have per-record screening decisions and want PRISMA counts/diagram) and states the 5000-record cap, which shapes when the tool is usable. It gives no explicit when-not guidance and does not name prisma_flow_diagram or any other sibling as the alternative for adjacent tasks. Usage is inferable but not spelled out.

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