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?

Annotations provide limited safety traits (readOnlyHint=false, openWorldHint=true), so the description carries much of the transparency load. It adds useful behavioral detail: resolves TSS via Ensembl, returns exactly 9,198 bp, and clarifies that tss_index is unnecessary. This goes beyond basic annotations, though it does not mention potential side effects or failure modes.

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 concise: two sentences that front-load the purpose, then provide the key detail about the window size and the handle usage. No word is wasted, and the structure is logical.

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 highly complete for a tool with an output schema: it explains the return value's role and how to use it in a downstream call. It could mention edge cases (e.g., gene not found, species restrictions) but is otherwise sufficient for an agent to invoke 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?

Schema description coverage is 100%, so the schema already documents 'gene' and 'species' with clear descriptions. The description adds meaning by explaining how the gene is used (TSS resolution) but does not introduce new parameter-specific details. Baseline 3 is appropriate given high schema coverage.

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 action: fetching a gene's sequence prepared for expression prediction. It distinguishes the tool from siblings by specifying the exact TSS-centred 9,198 bp window and its role as a handle for predict_expression, making it unique among fetch and prediction 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 provides clear context: this tool should be used when preparing a gene sequence for expression prediction, and it explicitly mentions the integration point with predict_expression. However, it does not explicitly state when to avoid this tool or compare it with alternatives like fetch_ensembl_sequence or find_genes_and_predict_expression.

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?

Beyond the readOnlyHint=true annotation, the description explains the async job submission, blocking vs detached modes, that wait=True never returns a job_id, and that timeout yields an error rather than a job handle. It also discloses the approximate runtime (8-25s) and the size constraint (1,000–500,000 bp), which are not captured in annotations. 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 long but well-organized into focused paragraphs. The first sentence states the purpose, and subsequent paragraphs cover usage, return format, and alternatives. While it is verbose, every section provides actionable information without redundancy. It earns a 4 for being structured and informative, though it could be tightened slightly.

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 tool is complex (async, multiple modes, rich output), and the description covers all critical aspects: the input size range, the async job behavior, the return structures for both wait modes, the output fields (transcript type, exon/intron/CDS arrays, GFF3 track), and the pointer to the alternative tool for expression. With an output schema present, it appropriately avoids over-explaining return values, but still clarifies the {data, meta} envelope and job_id path. This is comprehensive for the tool's 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 baseline is 3. The description adds some context, such as the bp range limitation and the mutual exclusivity of sequence and sequence_ref, but these are already implied in the schema descriptions (e.g., sequence_ref mentions mutual exclusivity). The additional value is modest, mainly the runtime and size guidance, so a 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 description opens with a specific verb+resource: "Find genes (transcript intervals) in a genomic region" and immediately distinguishes from siblings by naming the alternative tool for expression (find_genes_and_predict_expression). It clearly states what the tool returns (transcript boundaries, confidence scores, etc.) and when to use it, making it 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?

Explicit guidance is given: "Use this for 'what genes are here', 'find / locate genes', or 'annotate this region'." It also provides a clear exclusion: "To get each gene's *expression* from a raw region, use find_genes_and_predict_expression instead." The async behavior and wait parameter are thoroughly explained, including what happens in each mode.

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 goes well beyond the readOnlyHint/openWorldHint annotations by revealing async behavior, progress streaming, blocked vs. detached return shapes, the absence of a job_id on the blocking path, polling behavior on the detached path, and the hard requirement for expression-oriented description. No annotation contradiction exists.

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 longer than average but every sentence earns its place: first sentence states the purpose, then it scopes usage, differentiates from sibling tools, covers async modes, return shapes, and a required parameter. It is well structured, front-loaded, and contains no tautology or 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?

Given the tool's complexity—server-side chaining, dual wait modes, async behavior, required context, and comparison to siblings—the description fully equips an agent to select and invoke it correctly. Output schema exists, so return values need no further explanation.

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 descriptions already cover all 5 parameters with 100% coverage, so the baseline is 3. The description adds useful context beyond the schema: explanation of why description is required, the 1,000–500,000 bp length constraint in operational terms, and clarification of wait modes. This justifies a 4 rather than a 3.

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 a specific verb+resource: 'Find genes in a sequence, then predict each gene's expression (composite).' It clearly states server-side chaining and explicitly contrasts itself with the sibling predict_expression tool, making its scope and distinct value 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 explicitly says when to use this tool ('whenever you want expression for a raw region or sequence'), contrasts it with predict_expression ('scores ONE TSS window and needs you to know where that TSS is'), and gives practical operational guidance including sequence length range, wait=True/False modes, polling with get_job, and the required description parameter.

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 indicate readOnly, and the description goes far beyond by detailing the exact return shape (flat object vs. envelope), the meaning of bio_spec fields (caps vs. window sizes), and concrete values like 500,000 and 9,198. This adds substantial behavioral context not present in 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 well-structured with the purpose first, then usage, then detailed output explanation. It is longer than some list tools, but every sentence adds value, especially the clarification of bio_spec fields. It could be slightly condensed but remains efficient.

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 thorough: it covers purpose, usage, output format, field semantics, and contrasts with predict tools. Given the single parameter, existing output schema, and annotations, nothing essential is missing for an agent to correctly invoke the tool.

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% with the task parameter fully described via its description listing allowed values. The tool description does not add extra parameter semantics beyond the schema; it focuses on output details, so 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 explicitly states 'List available models for a task' with a clear verb and resource. It also distinguishes itself from siblings by noting it returns model IDs for use with predict tools, differentiating it from the predict and sequence-fetch 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?

It clearly says 'Use to discover model ids before passing one as the `model` argument to a predict tool' and mentions the alternative resource `gi://models`. While it doesn't explicitly list when not to use it, the primary use case and an alternative are given, making it functional but not exhaustive.

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 already indicate read-only and non-destructive behavior, and the description adds substantial behavioral context: the API rejects requests without a description, rejects sequences under 9,198 bp with no padding/truncation fallback, and warns that a wrong-but-in-range offset silently scores the wrong window. It also tells users to verify meta.task_specific_counts.scored_window, which goes well beyond the 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 detailed but tightly structured with a clear opening, bolded requirements, bullet-pointed input modes, and a formula for window slicing. Every sentence conveys necessary operational information—length limits, rejection behavior, error modes, and alternatives—without 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?

Given the tool's complexity—TSS windowing, length constraints, coordinate offset pitfalls, and multiple input paths—the description is thorough and self-contained. It covers parameter requirements, edge cases, verification steps, and sibling-tool alternatives, so the agent has enough context to invoke it correctly. The presence of an output schema means return-value documentation is not necessary.

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?

Although the input schema covers all parameters at 100%, the description adds critical semantics: the exact 9,198 bp window, the two acceptable ways to supply input, the slicing formula sequence[tss_index-4599 : tss_index+4599], and the required condition for tss_index. It also clarifies that sequence_ref comes from acquisition tools and that `description` is mandatory, enriching the schema's otherwise neutral parameter 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?

The description opens with 'Predict a gene's expression from a TSS-centred window', a specific verb+resource statement that clearly defines the tool's function. It also differentiates from siblings by naming easier alternatives like fetch_gene_for_expression and find_genes_and_predict_expression.

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 explicitly explains the two valid input modes (exactly 9,198 bp centred vs. longer locus with tss_index), states that `description` is REQUIRED, and specifies the exact length constraints. It also points users to easier paths and clarifies when tss_index is required, providing both when-to-use and alternative guidance.

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.