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

Annotations already declare readOnly=true, destructive=false and openWorld=false, so the safety profile is covered. The description adds the return contents (Tm, GC, dimers), which matters because there is no output schema, but it says nothing about the Tm model/assumptions (salt, concentration, nearest-neighbor) or sequence-format constraints that would affect interpretation of results.

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?

Pipe-delimited and front-loaded with the tool's identity, followed by trigger and return summary; nothing is buried. The alias list is long and bilingual duplication adds bulk, but each section serves a retrieval or routing purpose.

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 one-parameter, non-destructive calculator with no output schema, the description supplies the trigger, the returned quantities, and alias coverage. Only the Tm computation assumptions are left unexplained, a minor gap for a tool this simple.

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?

With a single parameter and 100% schema description coverage, the schema already documents 'sequence'. The description only restates 'given primer sequences' and adds no format detail such as 5'->3' orientation, allowed characters, or length limits, so 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?

The description names a specific verb+resource: computing Tm, GC% and self/cross dimer status for supplied primer sequences. An agent can tell this is a calculation over an existing sequence rather than a design tool, though it never explicitly names the closest sibling (pcr_primer_design) to draw the contrast.

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 'USE WHEN' clause gives a clear trigger condition: when you already have primer sequences and need Tm, GC% or dimer checks. It stops short of stating when NOT to use it (e.g. use pcr_primer_design to generate primers first), so the guidance is contextual but not exhaustive.

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