Genomic Intelligence

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

The description discloses that the sequence is stored server-side and that a handle is returned, with the bases staying server-side. This goes beyond the annotations (readOnlyHint=false, openWorldHint=true) by explaining the storage behavior and handle semantics, though it doesn't detail persistence limits or error conditions.

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 brief and front-loaded, with a clear purpose in the first sentence. Additional sentences add usage context and the expression alternative without unnecessary fluff.

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 covers the core functionality, return handle, and the key alternative for expression. Combined with the output schema and full parameter descriptions, it provides sufficient contextual completeness for an agent to select and use the tool correctly.

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?

The input schema provides comprehensive descriptions for all three parameters (gene, species, flank_bp), so the description doesn't need to add parameter-level detail. The description doesn't reference parameters beyond the general task, but the schema already covers them, making the baseline 3 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?

The description explicitly states 'Fetch a gene's reference sequence from Ensembl and store it,' naming the verb, resource, and action. It also distinguishes the tool by directing expression use to fetch_gene_for_expression, and clarifies the handle-based workflow.

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 an explicit alternative: 'For expression, use fetch_gene_for_expression instead,' which is clear guidance on when not to use this tool. It also explains the intended usage pattern with predict_* tools, providing context for when to invoke it.

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

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

With annotations present (readOnlyHint=false, openWorldHint=true), the description goes well beyond them: it discloses that a handle is stored, that Ensembl is contacted to resolve the canonical-transcript TSS, the minimum accepted size (9,198 bp; TSS at least 4,599 bp from each end), the flank_shortened behavior near chromosome ends, and the error condition when the TSS is too close to an end. The readOnlyHint=false annotation is consistent with the description's account of storing a handle.

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 lead sentence is front-loaded and the follow-on paragraphs each carry distinct operational information (model reuse, offset handling, flank minima). It is longer than strictly necessary and the indented block formatting is a little awkward, but no sentence is padding.

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 tool with an output schema, the description supplies exactly the semantics an agent needs beyond it: handle reuse across models, automatic tss_index handling, the specific flank bounds and shortening behavior, and the error case. Nothing required to call 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 description coverage is 100%, so the schema already documents 'gene' and 'species' adequately. The description adds no parameter-level detail (no format, casing, or species conventions), so the baseline 3 for fully-covered schemas applies.

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 first sentence names a specific verb and resource ('Fetch a gene's sequence prepared for expression prediction') and immediately frames the output as a handle for predict_expression. This distinguishes it from siblings like fetch_ensembl_sequence, fetch_region, and load_demo_sequence, which do not produce an expression-ready TSS-centred handle.

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 states the intended downstream use ('as a handle to pass to predict_expression(sequence_ref=...)') and explains why one handle suffices for every expression model. It does not, however, explicitly state when to prefer a sibling such as fetch_ensembl_sequence or fetch_region, so the routing is implied rather than contrasted.

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

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

The description explains the tool's storage behavior ('returns a handle ... the bases stay server-side') and the default strand expectation, which adds context beyond the annotations. It does not fully describe the lifecycle of the stored handle or potential side effects, but the 'store it' wording aligns with readOnlyHint=false. No contradiction with annotations.

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 the purpose and includes a usage example, return-behavior, strand default, and alternatives. It is slightly wordy in the middle sentence but every sentence contributes useful information. It earns a 4, not a 5, due to minor run-on structure.

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 covers the core functionality, return handle, strand expectation, and sibling distinctions. An output schema exists, so return values need not be detailed. The description is complete enough for an agent to understand when and how to use the tool, with no significant gaps given the tool's moderate complexity.

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 parameter semantics are already fully specified in the schema. The description adds marginal value by clarifying that the plus strand is expected by find_genes, but it does not elaborate on the other parameters beyond what the schema provides. 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?

The description uses a specific verb ('Fetch a genomic region by coordinates from Ensembl and store it') and identifies the resource (genomic region by coordinates). It also explicitly distinguishes from siblings by directing users to fetch_ensembl_sequence for gene-by-name and fetch_gene_for_expression for expression requests, making the purpose clear and differentiated.

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 description states exactly when to use this tool ('For "find the genes in chr8:127,680,000-127,800,000"-style requests') and provides explicit alternatives for other scenarios. This gives the agent clear guidance on tool selection, including a concrete example and exclusions.

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

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

Goes well beyond the annotations: it explains that an async job is submitted internally, that wait=True blocks and streams progress and never surfaces a job_id on that path, that an exceeded block ceiling yields a timeout error rather than a handle, and that wait=False returns a pollable job_id. It also discloses the 1,000–500,000 bp input constraint. This is exactly the extra behavioral context annotations cannot carry.

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-loads the core verb+resource+timing in the first sentence, then layers detail efficiently. The parenthetical comparing the bp floor to expression's 9,198 bp is slightly digressive, and the output/format sentence overlaps with the output schema, keeping it below a perfect score.

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 an async, wait-flagged tool with a full output schema and five fully documented parameters, the description covers everything an agent needs: region limits, job lifecycle, return shape, and routing to the expression variant. Nothing material is missing, and return values are legitimately deferred to the output schema.

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, but the description adds the region-length constraint (1,000–500,000 bp) that the schema's sequence property does not state, and reiterates the blocking/detached semantics of wait with the consequence (never returns job_id) that the schema omits. It does not, however, restate the sequence vs sequence_ref mutual exclusivity, so it stops short of a 5.

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 verb and resource ('Find genes (transcript intervals) in a genomic region') and immediately differentiates itself from siblings by naming find_genes_and_predict_expression and explaining why predict_expression cannot operate on a whole region. An agent can distinguish it 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 explicit trigger phrases ('what genes are here', 'find / locate genes', 'annotate this region') and an explicit alternative with its selection condition (use find_genes_and_predict_expression when you need per-gene expression from a raw region). When-to-use and when-to-switch are both covered.

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

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotent=false), the description discloses async-internally execution, that progress always streams, the two return shapes for wait=True vs wait=False, and the 1,000-500,000 bp range with no bp floor or tss_index. It could add more on failure/timeout behavior, but this is well above the annotation baseline.

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 purpose and the routing decision, then the mechanics; dense and mostly waste-free. Some of the wait-mode explanation repeats the parameter schema, which is slight redundancy but not padding.

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 5 params and an output schema, the description covers the chaining model, the async/wait contract, the required context param, and the size envelope. An agent has everything needed to call it correctly.

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 3 is the floor; the description earns above that by clarifying that `description` is REQUIRED (the schema lists no required params) and by explaining wait=True/False semantics and the mutual exclusivity constraints of sequence/sequence_ref.

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 verb phrase (find genes, then predict expression) and labels itself a composite. It explicitly contrasts with the sibling predict_expression and find_genes, so an agent can route without opening schemas.

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') plus a concrete example, and names the alternative and its precondition (predict_expression needs the TSS location and a 9,198 bp window). Nothing is left to inference.

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

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

Annotations already declare read-only and non-destructive behavior, and the description adds the three possible return envelope shapes (data/meta, progress, error) and the 'once' semantics. This goes beyond the structured annotations with useful runtime behavior.

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 two sentences, front-loaded with the core action. Every sentence earns its place, with no filler or repetition.

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?

Given the simple one-parameter design and the presence of an output schema, the description covers the essential behavior and return envelope types. It is complete enough for an agent to select and invoke correctly.

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?

The input schema already fully describes job_id, including its provenance from async tools, so the description adds no new parameter meaning. With 100% schema coverage, the baseline of 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?

The description uses the specific verb 'Poll' with the resource 'async job', clearly distinguishing it from siblings like list_jobs. The phrase 'once' clarifies it is a single-attempt status check, not a subscription or list operation.

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 description implies usage after an async job has been started, and the schema's job_id parameter references source tools. However, it does not explicitly state exclusions or alternatives, so it lacks full 'when-not' guidance but provides clear context.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, signaling a safe read operation. The description adds that jobs are scoped to the caller and recent, plus an alternative identifier (gi://jobs/recent), but it does not disclose behavior like pagination, ordering, or response details. It provides modest additional context but not deep transparency.

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 a single succinct sentence, front-loaded with the action and resource, and includes a brief parenthetical alternative identifier that adds value without bloat. Every word earns its place.

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?

This is a simple read-only list tool with a single well-documented parameter and an output schema present. The description covers purpose and scope, and annotations cover safety. It omits minor details like result ordering or pagination behavior, but these are not critical given the tool's simplicity and schema coverage.

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%: the only parameter 'limit' has a clear description, default, and bounds. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline of 3 applies.

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 clearly states the tool lists the caller's recent async jobs, using the specific verb 'List' and identifying the resource as jobs scoped to the caller. This distinguishes it from sibling tools like get_job, which presumably retrieves a single job, and other fetch/find 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?

The description implies this tool is for retrieving a list of the caller's recent async jobs, but it does not explicitly explain when to use it versus alternatives such as get_job (e.g., for a specific job ID). There is no mention of exclusions or when not to use it.

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

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

Annotations already cover the safe read profile (readOnlyHint, destructiveHint=false), so the bar is lower. The description adds genuine beyond-annotation context: the FLAT return shape versus the {data, meta} envelope of predict tools, and the semantic meaning of bio_spec fields (which is the only enforced cap, which describe model reading, the null-trained_window case).

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 first two sentences are tight and front-loaded, but the long bio_spec exposition dominates the body and much of it narrates output-field meaning that the output schema arguably already carries. It is information-dense yet disproportionately weighted toward return-value interpretation.

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?

An output schema exists, so return values needn't be explained at all — yet the description goes further and clarifies the semantics an agent needs to interpret those returned fields. Coverage of selection context and result shape is thorough; if anything it is over-complete.

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% and the single `task` param already documents its enum of allowed values. The description implies a task scoping but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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 verb+resource ("List available models for a task") and immediately distinguishes itself from siblings by naming the predict tools that consume its output. An agent knows exactly what this returns versus predict_promoter/predict_expression etc.

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?

"Use to discover model ids before passing one as the `model` argument to a predict tool" gives explicit when-to-use, and it names an alternative access path (the `gi://models` resource). The trigger condition is unambiguous.

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

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

With no helpful annotations (all false), the description carries the transparency burden. It discloses that the tool 'Stores the demo and returns a handle', clarifies 'no Ensembl fetch, no quota', and explains that it provides a curated positive control. These are meaningful behavioral traits beyond the schema, though it does not cover failure modes or persistence details.

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 the core purpose, followed by valuable context and an example. Its length is justified by the need to explain the 'bundled positive control' concept, though it is slightly more verbose than strictly necessary.

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 single-parameter tool with an output schema, the description fully explains when and why to use it, and how the demo relates to prediction tools. It lacks only explicit error-case or edge-case behavior, which is not critical given the simplicitly and output schema.

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% and the schema already includes examples and the gi://sequences resource. The description also provides an example and references the resource, but it does not add new semantics beyond what the schema already states, so the baseline score of 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?

The opening sentence 'Load a bundled demo reference sequence and return a handle' uses a specific verb and resource, clearly distinguishing it from fetchers like fetch_ensembl_sequence. The phrase 'no Ensembl fetch' further differentiates it as a local, pre-bundled option.

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 description provides clear context: this is for smoke-testing a prediction end-to-end and avoids Ensembl fetch/quota, implying use for quick local tests. However, it does not explicitly name alternatives or give 'when not to use' guidance, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds behavioral detail about the model's context window: it reads 1,000 bp and accepts 200–999 bp by padding. This is valuable beyond the annotations, though it doesn't elaborate on output behavior beyond what the schema would.

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 two sentences plus a bullet, extremely concise and fully front-loaded with the core purpose. Every sentence adds information: the model identifier, input length range, and a critical model constraint (1000 bp window with padding for shorter inputs). No fluff.

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 covers the essential behavior: the model's reading context and accepted input length. The output schema is present, so return values are understood. While it doesn't detail the 919 features or output format, the output schema presumably handles that. The input constraints are clear, and the tool's role among siblings is apparent. Slight gaps: no mention of typical use cases or performance notes, but it's sufficiently complete for an API.

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% for all parameters (sequence, sequence_ref, sequence_name, model). The description adds minimal parameter-specific guidance; it only mentions the input length range (200–500,000 bp) which relates to the sequence parameter, but does not explain parameter usage beyond what the schema already provides. 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?

The description clearly states the tool's purpose: chromatin annotation across 919 features using a DeepSEA model. It specifies the input size range (200–500,000 bp) and distinguishes itself from sibling predictors like predict_enhancer and predict_promoter by focusing on chromatin state annotation.

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 description provides input constraints (sequence length range) and notes the model's context window, but it does not explicitly explain when to use this tool over alternatives. While the name and description imply chromatin annotation, there is no direct statement like 'use this for chromatin state prediction.' This is a clear purpose but lacks explicit selection criteria.

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

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

Beyond the readOnlyHint annotation, the description discloses non-obvious behavioral details: the API 422s below 50 bp, the model scoring against a padded 249 bp context window, and that shorter sequences are still accepted. This is valuable context that significantly aids correct invocation.

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 compact and front-loaded with the core purpose, followed by one focused paragraph of necessary technical caveats. No sentence is wasted; the formatting emphasizes the critical 249 bp context.

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 four-parameter tool with 100% schema coverage and an output schema, the description provides the essential non-obvious context about sequence length limits and scoring behavior. It does not discuss alternatives or output semantics, but those are largely covered by schema, annotations, and the tool's clear purpose.

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 parameters are already documented. The description adds important meaning for the sequence parameter by explaining the admission floor and context window, which is not present in the schema. Other parameters like model and sequence_ref are left to the schema, but the added length guidance justifies a score above baseline.

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 clearly states the tool predicts enhancer activity using G0 DeepSTARR, giving a specific verb and resource. It does not explicitly differentiate from sibling prediction tools like predict_promoter or predict_chromatin, but the enhancer focus is clear enough.

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 description gives concrete guidance on sequence length: the 50 bp admission floor, the 249 bp context window, and the recommendation to submit at least 249 bp for meaningful results. However, it does not explicitly say when to use this tool versus the sibling tools or mention alternatives.

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

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

Annotations cover safety (readOnly/openWorld/non-destructive), but the description adds substantial behavior beyond them: the API 422s for missing description, sub-9,198 bp sequences, off-centre TSS, and N-rich/low-complexity windows; a WRONG-but-in-range tss_index silently scores the wrong window; extra flank beyond recommended_flank_bp is ignored. That is exactly the kind of failure-mode disclosure that prevents misuse.

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 purpose, then constraints, then easiest paths. It is long and repeats some tss_index/4,599 bp rules already in the schema, which costs a bit, but the ordering is sensible and nearly every sentence carries operational value.

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 complex, high-stakes prediction tool with an output schema present, the description is complete: it covers required context, sequence windows, offset semantics, verification of meta.task_specific_counts.scored_window, and the recommended acquisition path. An agent needs nothing more to call it correctly.

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, but the description goes well beyond the schema by explaining parameter interactions: description is REQUIRED despite being schema-optional, tss_index is unnecessary for exactly 9,198 bp but mandatory for longer sequences, sequence_ref handles carry their own offset, and wrong offsets succeed silently. This is real added meaning.

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?

Opens with a specific verb+resource+scope ('Predict a gene's expression from the sequence around its TSS'), which cleanly separates it from siblings like predict_chromatin, predict_promoter, and predict_splice that share the same prediction idiom.

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?

Explicitly routes the agent: 'Easiest paths' names fetch_gene_for_expression for pre-fetched TSS-centred handles and find_genes_and_predict_expression for raw regions, and points at list_models for recommended flank sizes. It also states when to omit model (server default) and which params are mutually exclusive via the schema.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds valuable behavioral detail: it clarifies the return envelope ({data, meta}) and specifies that data.regions contains start/end/score. It also discloses the padding behavior for sequences shorter than the model's context window – a non-obvious side effect that annotations do not cover. This goes beyond the structured metadata.

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 compact (about 100 words) and front-loaded with the core purpose. It uses a clear structure: purpose statement, return envelope, and a practical caveat about context windows. Each sentence adds value, though the final sentence about checking model context could be seen as slightly verbose but is still actionable.

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?

Given the output schema is present, the description needn't detail return types, but it goes further by explaining the data.regions structure and the padding behavior, which are crucial for correct interpretation. It also references list_models for model-specific details, making the tool self-sufficient. For a predictive tool with complex input constraints, the description provides enough context to use it correctly.

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?

The input schema has 100% parameter description coverage, with each parameter (model, sequence, sequence_ref, sequence_name) already described in detail, including mutual exclusivity and ignored cases. The description adds no additional parameter-specific meaning; it focuses on output and constraints. Thus a baseline score of 3 is appropriate because the schema carries the explanatory load.

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 clearly states the tool predicts promoter regions (G0) with a size range (300–500,000 bp). It distinguishes from sibling tools like predict_enhancer and predict_chromatin by specifying the exact biological target and provides a unique constraint on input length. The verb-resource pairing is specific and unambiguous.

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 description provides concrete guidance on input length requirements (300 bp floor) and explains how the model handles shorter sequences via context window padding. It directs the agent to check model specifics via list_models, which is practical. However, it does not explicitly contrast with alternative predictors (e.g., when to choose predict_enhancer over this), so it lacks explicit exclusionary guidance but still offers strong contextual direction.

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

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

Annotations already declare readOnlyHint=true, but the description adds crucial behavioral context beyond that: the 15,000 bp context window and its effect on short inputs, strand-specificity, and the silent failure mode (wrong strand yields plausible high-scoring sites at different positions with no error flag). This is exactly the kind of failure-mode disclosure that an agent needs and that annotations do not provide.

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 a single focused paragraph that front-loads the purpose and then states two important usage caveats. It is not padded, but the phrase 'not the near-zero scores once documented here' is a historical note that adds little actionable value for an agent. Still, the overall structure is efficient and prioritizes the most critical 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 prediction tool with an output schema and fully documented parameters, the description covers the essential usage pitfalls: the context window, strand sensitivity, and how to obtain the correct strand. It does not need to describe return values (output schema exists), and the openWorldHint is handled by annotations. An agent has enough context to call this tool correctly and avoid common mistakes.

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 each parameter already has a detailed description (sequence vs sequence_ref mutual exclusivity, line-break handling, etc.). The description itself does not add new parameter semantics, but it reinforces the strand guidance related to sequence_ref. Per the rubric, a baseline of 3 is appropriate when the schema carries the parameter documentation 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 opens with 'Predict splice donor/acceptor sites', a specific verb and resource that clearly distinguishes this from sibling prediction tools (predict_chromatin, predict_enhancer, predict_expression, etc.). The mention of 'G0 BigBird' adds model specificity without ambiguity. The name and description both point to the same unique function.

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 description provides concrete usage guidance: feed a whole transcript locus to avoid the padded-window effect, and submit the transcript's own orientation because the wrong strand fails silently. It even points to fetch_region's `strand` parameter, which is actionable. It does not explicitly contrast with alternative tools, but the domain-specific warnings are sufficient for correct selection and invocation in most cases.

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

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

Adds rich behavioral context beyond the sparse annotations: the full sequence passes through the LLM on this call, whitespace is stripped so handle length and tss_index align with the API's measurement, and FASTA header lines are rejected. No contradiction with annotations (readOnlyHint=false, destructiveHint=false).

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?

Every sentence adds distinct value: purpose, use-case, caveat, alternatives, and formatting details are clearly separated and front-loaded. The description is moderately long but tightly written with 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?

For a 2-parameter tool with an output schema, the description covers the full lifecycle: when to use, what happens, what to avoid, and important edge cases (FASTA headers, whitespace). It is complete without needing to describe return values since an output schema exists.

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 already covers both parameters (100% coverage), and the description adds meaningful semantics: explains that line-wrapped FASTA bodies can be pasted verbatim, whitespace is stripped, and how this affects the handle's measured length. This goes beyond the schema's basic descriptions.

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 exactly what it does: 'Store a human-pasted sequence and return a handle to re-use it.' The verb 'store' and resource 'sequence' are clear, and it distinguishes itself from siblings by contrasting with server-side fetch tools (fetch_ensembl_sequence, load_local_fasta) and by noting it avoids re-pasting for predict_* calls.

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?

Explicitly explains when to use: for sequences already pasted in conversation. Provides a clear exclusion: 'For large sequences, prefer fetch_ensembl_sequence / fetch_gene_for_expression / load_local_fasta' and warns about the LLM round-trip caveat. This is direct when/when-not guidance with named alternatives.

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