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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is supplied. The description adds the meaningful guarantee that recoding is synonymous ('same protein, no recognition site') and limited to internal sites, but leaves open whether the open record is mutated in place versus a new record returned, and what happens when no synonymous choice is available.

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 the operation stated first and the constraint appended after an em-dash; every clause carries information. The adverb 'Silently' is the one slightly ambiguous word, since it is unclear whether it refers to silent (non-protein-changing) mutation or to a lack of reporting.

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 9-parameter, nested-object mutation tool the description covers the core operation, the sequence-preservation invariant and the intended downstream use, and an output schema exists to describe results. Remaining gaps are edge-case behavior (failure when no synonymous codon exists, in-place vs. returned record) rather than the primary call contract.

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 the schema already explains cds_start/cds_end, enzyme, table/table_tsv, cds_strand and _subject in detail. The description only obliquely motivates the CDS bounds via 'inside a part's coding sequence' and adds nothing about the enzyme or codon-table parameters beyond what the schema states, so the baseline of 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?

The description gives a specific verb and resource: recode Type-IIS recognition sites within a part's coding sequence, with the constraint that the protein stays identical. That scope ('internal', 'coding sequence', 'same protein') is distinctive enough to separate it from siblings like scrub_restriction_sites or optimize_sequence, though no sibling is named 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?

It states the downstream purpose ('so the part can be used in a Golden Gate assembly'), which implies when to reach for it, but there is no explicit when-not guidance and no pointer to alternatives such as scrub_restriction_sites or check_golden_gate_parts. The agent must infer the boundary between domesticating an existing CDS and other site-removal tools.

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