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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds substantial interpretive context: counts reflect administered findings only, the endogenous block measures the body's own peptide and is not evidence about taking it, and a 0 human count means none within the filters rather than no study existing. These caveats prevent real misreadings of the output. It stops short of describing ordering, pagination or response shape, but with an output schema present that is a minor gap.

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?

Purpose and scope are front-loaded in the first two sentences, followed by alternatives and then interpretation caveats. Every sentence carries information, though the block on evidence classes and the zero-count caveat could be tightened given the tool takes only two parameters.

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?

Given a simple two-parameter read tool with full schema coverage and an output schema, the description covers the interpretive essentials an agent needs. The remaining gaps are the effect of the 'view' mode and the dangling reference to 'filters' that the schema does not expose.

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 both parameters are already documented, which sets the baseline at 3. The description adds nothing about the 'view' parameter (compact vs full) or how peptide name/alias/slug/ID resolution behaves, and it references 'filters' that do not exist among the parameters, which is slightly confusing. The meaning it adds is about count semantics, not parameter usage.

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 and resource ('Return checked finding counts for one peptide') and enumerates the exact breakdowns produced: outcome group, evidence class, direction, plus year, design and safety counts. It also names the siblings it is not (search_findings, compare_peptides), so an agent can distinguish 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?

Explicitly says when to use this tool ('inspect evidence coverage and gaps') and when not to, routing to search_findings for individual claims and source sentences and compare_peptides for multiple peptides. The alternatives are named with the condition that selects each.

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