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

Annotations already declare readOnlyHint and idempotentHint, so the description does not need to repeat safety traits. It adds behavioral context by explaining that the tool 'enumerate and score candidate primer pairs against length/Tm/GC/3'-clamp/structure constraints', revealing its algorithmic nature and output type. This goes beyond the annotations without contradicting them.

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 a single, information-dense sentence that front-loads the core purpose and method. It includes a parenthetical clarification ('Primer3-style penalty picker') and lists key constraints, all without unnecessary words.

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?

Given the tool has 19 parameters and no output schema, the description gives a useful high-level overview but omits important details like the return structure (e.g., a list of scored primer pairs) and the role of optional parameters such as targetStart/targetEnd. It is adequate for understanding the core function but falls short of being complete for such a complex tool.

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 only 47% (9 of 19 parameters have descriptions). The description mentions constraint categories like 'length/Tm/GC/3'-clamp/structure' but does not explain specific parameters such as gcMax, tmOpt, ampliconMin, or targetStart. With this low schema coverage, the description should compensate, but it remains at a high level and adds little value for understanding individual parameters.

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 clearly states the tool's function: 'De-novo PCR primer design' and specifies the method as a 'Primer3-style penalty picker' that enumerates and scores candidate primer pairs against constraints. This distinctly separates it from sibling tools like melting_temperature (which only calculates Tm) or kasp_primer_design (which is specifically for KASP genotyping).

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 phrase 'De-novo PCR primer design' implies the tool is for designing new primers, as opposed to checking existing ones or calculating Tm only. However, it does not explicitly state when to use this tool over alternatives like primer_specificity or aso_design, nor does it provide exclusions or conditions.

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