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

Annotations already mark readOnlyHint, idempotentHint, and openWorldHint false, but the description adds substantial behavioral detail beyond this: nothing is transcribed, each hit carries the accession and 1-based span it was cut from, hit parts may appear in multiple library vectors, and spliced or approximate parts are excluded because their sequence is not fully determined. This gives the agent insight into both the return payload and the filtering boundary.

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 description is packed with relevant information and every clause earns its place. It front-loads the main purpose and the precise data source, then clarifies boundary behavior in a single final sentence. Despite its richness, it remains a single readable paragraph without redundancy.

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 search tool with six optional parameters and no output schema, the description covers the essential execution expectations: what kinds of parts are searchable, how exact sequences are handled, what result metadata appears, and which parts are excluded. Combined with the annotations and fully self-documenting input schema, an agent has enough context to decide to invoke the tool and how to interpret its results.

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 all six parameters, including constraints on limit and kinds, are already documented in the schema. The description contributes lexical context (promoters, terminators, RBSs, polyA signals, etc.) but does not add meaning beyond what the parameter descriptions already provide. Baseline 3 is appropriate for this level of schema coverage.

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 ('search'), a well-defined resource ('a parts list harvested from the annotated features of the vector library'), and the searchable dimensions (name, kind, length). The description also highlights a defining scope: parts are the exact sequences from GenBank annotations, while spliced or approximate locations are excluded. This sharply distinguishes the tool from generic sequence search or whole-vector search siblings.

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 clearly indicates when the tool applies: searching for defined genetic parts from vector parts libraries, with filtering by name, kind, or length. It does not explicitly name a sibling alternative or state 'when not to use this,' but the context and content make the appropriate scenario obvious. A small deduction because alternatives like vector_library_search are not explicitly contrasted.

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