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

Annotations only mark it as a non-read-only, open-world, non-idempotent call; the description adds the important behavior an agent cannot infer: it always runs async internally, wait=True blocks and streams progress and never returns a job_id, wait=False returns {data: {job_id, status}} to poll via get_job, and `description` is mandatory because the pipeline ends in expression. It stops short of stating cost/latency expectations or what happens on failure mid-pipeline.

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?

Front-loaded with the core action and the key sibling contrast, then moves to operational details in a logical order. It is somewhat long and repeats the 'no 9,198 bp floor' point twice, but nearly every sentence carries decision-relevant information.

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 composite async tool with five parameters, the description covers the chaining behavior, input-size bounds, the mandatory context field, and both wait modes including the exact return shapes; an output schema exists, so return-value detail is not needed. Nothing an agent needs to invoke it correctly 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 coverage is 100%, so the baseline is 3; the description earns a notch more by explaining the rationale behind the required `description` (workflow terminates in expression, which the API rejects without it), by clarifying that no tss_index is taken, and by tying the 1,000-500,000 bp range to the gene-finding first stage. It does not address sequence vs. sequence_ref exclusivity or the sequence_name echo, leaving those to 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?

States a specific two-stage operation (find genes, then predict expression per discovered TSS) and explicitly positions itself against predict_expression and fetch_gene_for_expression, so an agent can distinguish it from siblings without opening any 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?

Gives an explicit when-to-use rule ('the right tool whenever you want expression for a raw region or sequence') with a concrete example, plus when-not: predict_expression requires a known TSS, a >=9,198 bp sequence and a tss_index, which this tool avoids. The alternative's prerequisites are spelled out so selection is unambiguous.

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