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

Annotations already declare this a safe, non-destructive, non-open-world read, so the description only needed to add behavioral context — and it does: hits are reported on both strands, and each motif's threshold is interpreted as a fraction of that matrix's own score range, which materially affects hit counts. It does not discuss runtime, hit limits, or overlapping-hit handling, and the return shape is left to the output schema.

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?

A single front-loaded sentence with no filler; the core action comes first and the qualifiers follow. It is dense, with nested parentheticals, but every clause carries information, so it reads as economical rather than padded.

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?

With a full output schema and 100%-documented parameters, the description only needs to convey what a call means — matrix-based scanning across both strands with motif-relative stringency — and it does that. The remaining gap is guidance on choosing this over sibling motif/promoter scanners, which is a routing concern rather than a calling correctness one.

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% and the schema already spells out the motif object (name, counts, relativeThreshold vs absolute threshold, JASPAR pseudocounts) and the open-record default for sequence. The description largely restates the threshold-as-fraction-of-score-range semantics rather than adding new meaning, so the baseline 3 applies.

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 ('find every place') and a precisely defined resource (a position-frequency matrix matching a DNA sequence), including scope details like both-strand scanning and per-motif thresholds. It explains the mechanism well enough to distinguish matrix-based scanning from a simpler pattern search, but never names the nearest sibling (find_linear_motifs) explicitly.

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?

Usage is implied by the framing: supply a DNA sequence (or rely on the open record) plus a set of matrices. There is no explicit when-to-use/when-not statement, no mention of alternatives such as find_linear_motifs or the promoter/terminator scanners, and no prerequisites or caveats about matrix quality.

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