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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the internal detection model (clean sequence up to the breakpoint, then two offset superpositions), which genuinely helps an agent interpret a positive result. It does not say how confident the call is, what happens with noisy or short traces, or how the breakpoint_scan and quality_value_reading switches affect the outcome – that material lives only in the schema.

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 that opens with the question the tool answers and then supplies the mechanism; no filler. The all-caps emphasis on the key terms is functional but slightly informal, and the colon-clause makes it denser than it needs to be.

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?

With an output schema present and every parameter richly documented in the schema, the description's remaining burden is conceptual, and it delivers that. A six-parameter trace-analysis tool would ideally also hint at the open-tab default and the 'upstream never fires' caveat, but those are already in the schema, so nothing essential is missing.

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 table, document, breakpoint_scan, quality_value_reading and the _subject record. The description mentions the indel's length and offset conceptually but adds no syntax or selection advice for any of the six parameters. Baseline 3 applies when the schema carries the parameter burden.

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 states a concrete question the tool answers ('whether a Sanger trace splits into TWO READS OF DIFFERENT LENGTH') and ties it to the biological cause (heterozygous insertion or deletion), so the verb and resource are unambiguous. It stops short of naming a sibling such as tide_quantify_indels or call_mixed_bases_from_trace, so an agent must infer the distinction between this detector and other indel/mixed-base tools.

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 phrase 'which is what a heterozygous insertion or deletion does' – call it when you suspect a heterozygous indel in a Sanger trace. There is no explicit when-not guidance, no named alternative for homozygous indels, mixed bases, or quantification, and no prerequisites stated.

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