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

With no annotations, the description carries the full behavioral burden and does substantial work: it discloses the output shape (composite 0-100 score, per-dimension breakdown, flagged positions) and explains that metal_binding_context suppresses penalization of functional Cys/His/carboxylate residues. It omits any auth/rate-limit or performance context, but for a compute-style assessment tool the disclosure is strong.

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?

Front-loaded purpose followed by parameters and returns, with every enumerated dimension earning its place. The explicit 'Returns:' line partially duplicates the existing output schema, so it is slightly redundant but not wasteful.

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 moderate-complexity analysis tool with an output schema present, the description covers the purpose, the key input semantics, and the return contract adequately. It is slightly over-complete on returns (already in the output schema) while leaving the api_key parameter unaddressed.

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 0%, so the description must compensate; it does so well for 'sequence' (amino acid sequence) and exceptionally for 'metal_binding_context' (explains the exact residues affected and the default). Only 'api_key' is left undocumented, which is a minor gap given it is an injected credential.

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 ('Assess') and resource ('biopharmaceutical developability') and enumerates all 8 risk dimensions plus the composite scoring model, which precisely scopes the tool as a multi-dimension aggregate. This enumeration effectively distinguishes it from single-dimension siblings like covabio_deamidation, covabio_charge_profile, and covabio_viscosity.

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 purpose (run this for a developability read), but there is no explicit when-to-use, when-not-to-use, or routing to the single-dimension sibling tools that overlap with its dimensions. Only the metal_binding_context parameter carries any decision guidance.

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