get_coverage

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

Beyond the readOnlyHint annotation, the description discloses that the tool is not implemented in this build and will return a specific error. It also explains the default read filtering, a behavioral trait not visible from the schema alone.

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?

Two sentences deliver the essential purpose, filtering semantics, and the critical not-implemented warning without wasted words. The most important operational fact—that it returns unsupported—is clearly placed at the end.

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?

The description is adequate for a tool that currently cannot execute: it states the intended function, the input type, the default filters, and the explicit error behavior. It does not describe the output schema or parameter behaviors, but the unsupported status makes those less critical, and an output schema is present to cover return values.

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 13%, so the description carries most of the parameter-semantics burden. It explains file, interval, and default exclude flags, but does not clarify bin_size, min_base_quality, min_mapping_quality, or the reference parameter, which are otherwise unexplained by the schema.

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 specific verb and resource: read depth over an interval from indexed BAM/CRAM, and clarifies it is like samtools depth. This is distinct enough from siblings such as get_pileup, get_reads, and get_signal without needing to open the schema.

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 clearly identifies the input domain (indexed BAM/CRAM over an interval) and the default filtering behavior. The explicit 'Not implemented in this build: returns error code unsupported (E4)' tells an agent not to rely on this tool, though it does not name an alternative tool to use instead.

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