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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, and the description usefully adds the behavioral consequence that saved values become the starting point for later PCR, primer design and codon optimization calls. However, it never mentions the `clear` path, i.e. that this same tool forgets preferences and resets panels to defaults, which is the one genuinely non-obvious behavior here and is in tension with the read-only-sounding 'remember'. Persistence lifetime and partial-update semantics ('keep') are also unstated.

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 a purpose clause followed by an enumerated scope list; nothing is wasted and the motivation comes before the payload. The grammar around 'start on it' is slightly tangled, which costs it a point against an otherwise tight construction.

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 10-parameter mutation tool with nested objects and an output schema, the description covers the happy path of writing preferences but is silent on the deletion path exposed by the `clear` enum, which is arguably the behavior an agent is most likely to misuse. Schema and output schema fill most remaining gaps, so this is adequate rather than broken.

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% and the enum descriptions are unusually rich (e.g. the full polymerase product catalog with vendor names), so the schema carries the load. The description echoes four of the ten parameters without adding format, units or constraint detail beyond them, and omits `clear`, `polymerase_product`, `_subject` and `_files` entirely. Baseline 3 is appropriate.

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?

'Remember what this lab uses' names a specific verb and resource, and the colon list pins down exactly which preferences (polymerase, primer length and GC windows, expression host). It is clearly distinguishable from every sibling, which are all analysis/design tools rather than preference storage. It falls short of 5 only because the name/title already carry 'remember lab preference', so the description spends its first clause restating rather than extending.

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 clause 'so the PCR program, primer design and codon optimization start on it' implicitly tells the agent why and when to call this: before running those downstream tools, to seed their defaults. That is real routing context. But there is no explicit when-not, no statement of scope (per-project? per-session? global?), and no mention of the alternative path of just overriding parameters on the downstream call.

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