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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: it returns actual track rows, track type, and assembly, and it is the same data the Genome Browser draws. It does not discuss rate limits or error behavior for wrong builds, but the core behavior is clear.

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 front-loaded with concrete query examples that make the tool's purpose immediately recognizable. It is somewhat long and includes emphatic language, but every sentence contributes useful routing or scope information and there is no filler.

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?

There is no output schema, so the description carries more responsibility to explain return values. It does describe the return as actual track rows plus track type and assembly, and gives examples of row content such as gene models, variants, and conservation scores. Given the variability of UCSC tracks, this is complete enough for correct invocation, though it could be more explicit about response shape.

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 input schema already documents all six parameters in detail, including coordinate bases, UCSC chromosome naming, genome build warnings, and maxItemsOutput truncation. The description adds a useful pointer to obtain the track name from ucsc_tracks, but otherwise does not substantially extend parameter semantics beyond 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: it fetches authoritative per-row data from any UCSC annotation track over a genomic interval. It immediately distinguishes the tool from web search and from sibling tools like ucsc_tracks by explaining what comes back: actual track rows with track type and assembly.

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 gives explicit usage guidance with alternatives: prefer this over web search for position-based annotation queries, and get the required track name from ucsc_tracks first. This routes the agent to the correct sibling before invocation and states the key selection condition.

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