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?

Beyond annotations, the description reveals that the tool resolves the TSS through Ensembl and returns exactly the TSS-centred window required by the model, as a handle/ref. This adds process-level behavior not present in the schema or annotations, though it doesn't mention failure modes or network dependencies.

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?

Three short sentences; the first states the action, and the following two concisely explain the resolution logic and how the result is consumed. No filler or redundancy.

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 has an output schema and minimal annotations; the description explains the Ensembl resolution, the TSS-centred window, and the intended downstream call, making selection and invocation clear. It doesn't enumerate edge cases or supported species, but the schema covers essential parameters, so the completeness is solid.

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%: the gene parameter includes a concrete example and species states purpose/default. The description adds no extra parameter-specific semantics, so 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 opens with a specific verb+resource ('Fetch a gene's sequence') and immediately clarifies its specialized purpose: preparing a TSS-centred window for expression prediction. This clearly distinguishes it from siblings like fetch_ensembl_sequence and fetch_region.

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 states the exact use case (preparing input for predict_expression via sequence_ref) and names the downstream tool, giving clear context. However, it does not explicitly state when not to use it or list alternative tools, so it misses the exclusion criterion.

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/destructiveHint annotations, the description discloses async behavior (~8-25s), the internal job submission, wait semantics (blocking with progress vs immediate job_id), timeout behavior instead of returning a job handle, and the exact return shapes for both wait modes. It also reveals the output structure (transcript type, exons/introns/cds arrays, GFF3 track). This substantially exceeds annotation-only 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 front-loaded with the core action and time expectation in the first sentence. It is structured into three focused paragraphs: what the tool returns, when to use alternatives, and async/wait behavior. Each sentence adds distinct value—no fluff or repetition. The length is justified by the tool's complexity and the need to clarify async semantics.

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 has an output schema, the description doesn't need to enumerate every return field, but it does describe the high-level return containers for both wait modes, the internal structure (exons/introns/cds), and the GFF3 track. It also covers error behavior (timeout) and the relationship to get_job. This is comprehensive for a tool with async execution and multiple input modes.

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%, with each parameter (wait, model, sequence, sequence_ref, sequence_name) already described in the schema. The description adds minimal new parameter information—it repeats wait behavior and mentions sequence_ref handles from acquisition tools, but does not meaningfully extend the schema definitions. Baseline 3 applies due to 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 opens with a specific verb+resource: 'Find genes (transcript intervals) in a genomic region'. It further clarifies the exact nature of the output (transcript boundaries, TSS + PolyA, BED-style intervals) and distinguishes from the sibling tool find_genes_and_predict_expression by stating what this tool does not do (expression analysis). This is a clear, differentiated purpose.

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 use cases are given: 'Use this for "what genes are here", "find / locate genes", or "annotate this region".' It also provides a clear alternative: 'To get each gene's *expression* from a raw region, use find_genes_and_predict_expression instead' with reasoning about TSS windows. Additionally, it explains wait=True vs wait=False usage and directs polling with get_job for detached mode, giving complete when-to-use 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?

Beyond the annotations (readOnlyHint, openWorldHint, destructiveHint), the description discloses key behavioral traits: server-side chaining in a single call, internal async execution at every size, progress streaming, the exact return shapes for wait=True vs wait=False (including the absence of job_id on the blocking path), and the requirement for description. This goes well beyond what annotations provide and sets clear expectations.

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 moderately long but well-structured: a one-sentence summary, then a detailed explanation of chaining, use case, behavioral modes, and required parameters. Each clause earns its place, and the formatting (paragraph breaks, bullets for wait modes) aids scannability. Slightly dense, but not redundant.

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 (chained operations, async modes, required param) and that an output schema exists, the description covers all essential aspects: operation, use case, behavioral modes, return types, and required context. No critical gaps remain for an agent to select and invoke 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 baseline is 3. The description adds meaningful semantics by explaining why description is required (the workflow ends in expression) and how wait controls blocking vs detached behavior, which reinforces and augments the schema descriptions. It also clarifies the mutual exclusivity of sequence and sequence_ref in context.

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 clear verb+resource+action: 'Find genes in a sequence, then predict each gene's expression (composite).' It explicitly distinguishes from siblings by stating it's the right tool for raw region/sequence and explaining why predict_expression cannot be used on a whole region, citing the per-gene TSS window requirement.

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 explicit when-to-use guidance ('This is the right tool whenever you want expression for a raw region or sequence') and contrasts with the alternative ('You cannot call predict_expression on a whole region'). It also details both wait=True and wait=False usage paths, including when to use get_job for polling, and flags that description is REQUIRED.

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 read-only and non-destructive behavior. The description adds the fact that the catalog is also available as a resource, but does not disclose other behavioral aspects such as whether the list is static, paginated, or ordered. This is typical for a simple read-only list with good 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 concise with two sentences, front-loaded with the primary action, and no filler. The minor multi-line formatting adds a slight structural overhead but does not harm clarity.

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 schema, the presence of an output schema, and annotations, the description adequately covers the tool's purpose, usage context, and alternative access. It doesn't need to explain 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?

The single 'task' parameter is fully documented in the schema with a description and enumerated values. The tool description adds no additional parameter semantics beyond what the schema provides, 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 clearly states 'List available models for a task' and explains the purpose of discovering model IDs before prediction, effectively distinguishing this tool from the various predict_* siblings. The verb 'list' and resource 'models' are 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?

Explicitly instructs to use the tool before passing a model argument to a predict tool, and mentions the same catalog is available as the resource `gi://models`, providing an alternative access method. This gives clear when-to-use and a named alternative.

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 known. The description adds a useful length constraint and output dimensionality, but does not disclose error behavior, how the model is selected, or what happens when the sequence exceeds the limit.

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 very short, with no filler, and front-loads the core purpose. It is efficient, though the brevity omits context that would help the agent; nevertheless, for conciseness and structure it earns a 4.

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?

Despite having an output schema and full parameter descriptions, the tool is a complex prediction tool with multiple input modes and an optional model. The description fails to mention key usage context such as how to provide a sequence, whether a sequence is required, and how to interpret the 919-feature output. This leaves significant gaps for an agent.

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 descriptive parameter definitions, so the schema carries the parameter semantics. The description adds no extra meaning to the parameters themselves; the length limit is not tied to a specific parameter.

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 identifies the tool as performing chromatin annotation using 919 features and names the model (G0 DeepSEA), which distinguishes it from sibling prediction tools. However, it lacks an explicit verb like 'predicts' or 'returns', and does not clarify the output shape beyond the feature count.

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 offers no guidance on when to use this tool instead of alternatives such as predict_enhancer or fetch_region. It only provides a technical limit (500,000 bp) and does not explain the required input (sequence vs sequence_ref) or how to choose a model.

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 readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds valuable behavioral context: the maximum input length (500,000 bp), the default model's minimum length requirement (50 bp), and server-side rejection behavior. It also explains why the client-side minimum remains permissive across models, which is beyond what annotations 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 two sentences that are information-dense without redundancy. The first sentence states the core purpose, and the second provides necessary behavioral constraints. Every phrase earns its place, and the structure is clear and front-loaded.

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 has an output schema, so return values do not need explanation. The description covers the core purpose and key behavioral constraints (length limits, model behavior), which is sufficient for a prediction tool with well-annotated schema. However, it could have briefly mentioned when to prefer this over related prediction tools, which would make it more 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?

The input schema already covers all parameters with descriptions, including the mutual exclusivity of sequence and sequence_ref. Schema description coverage is 100%, so baseline is 3. The description adds context about model-specific length floors but does not add new meaning to individual parameters beyond what the schema provides.

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 the tool predicts enhancer activity using the G0 DeepSTARR model, which is a specific verb+resource+model combination. This clearly distinguishes it from sibling tools like predict_promoter or predict_chromatin, which predict different functional elements.

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 the tool is for enhancer activity prediction and provides length constraints, but it does not explicitly state when to use this tool instead of alternatives or mention any exclusions. No direct comparisons to sibling tools are given, so usage guidance remains implied rather than explicit.

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 flag readOnly/destructive safety, but description adds critical context: the 9,198 bp client guard, the API's silent truncation/padding for other lengths, and the mandatory `description` parameter for cell-type specificity. 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?

Front-loads the purpose, then provides requirements and alternatives in compact, purposeful sentences. No filler; every sentence contributes to correct invocation.

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?

Despite full schema coverage and annotations, the description supplies the crucial misuse warning (silent truncation) and alternative routing, making it fully actionable for a moderately complex 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 covers 100% of parameters, which sets a baseline of 3. The description adds the TSS-window length constraint and clarifies that `sequence_ref` comes from specific acquisition tools, enhancing parameter semantics beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States 'Predict a gene's expression from a TSS-centred input window' — a specific verb, resource, and scope. It also distinguishes from siblings by demanding an exact TSS-centered window, and directly contrasts with 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?

Explicitly says when to use alternatives: 'Call fetch_gene_for_expression(gene) for a correctly-prepared handle, or find_genes_and_predict_expression for a raw region or whole gene.' It also warns against off-window sequences and explains why, giving clear use vs. avoid 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 provide readOnlyHint=true and destructiveHint=false. The description adds value beyond these by disclosing the output envelope format ('Returns the {data, meta} envelope') and the list of predicted promoters with start/end/score, which is helpful contextual information not captured 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 extremely concise—two short sentences—and front-loads the core purpose. Every word earns its place, efficiently conveying the action, size limit, and return format without unnecessary detail.

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 exists, annotations cover safety, and all parameters are documented, the description is complete enough for an agent to invoke the tool. It covers the essential purpose, the input size limit, and the expected result structure.

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%, with each parameter (model, sequence, sequence_ref, sequence_name) having a clear description. The tool description does not add any additional parameter semantics, 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 clearly states the tool's function: 'Predict promoter regions (G0)', using a specific verb and resource. It distinguishes itself from sibling prediction tools (predict_enhancer, predict_chromatin, etc.) by naming the exact biological target.

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 a size constraint ('Up to 500,000 bp') but does not explicitly state when to use this tool over alternatives or when not to use it. Usage is implied by the tool name and the brief description, but no alternatives or exclusions are mentioned.

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 adds a key behavioral constraint (maximum input length) and the model name, which goes beyond the readOnlyHint and destructiveHint annotations. It does not contradict 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 two short sentences with no wasted words. It front-loads the purpose and then states a key limitation, making it easy to parse.

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 that the input schema is fully described and an output schema exists, the description covers the essential purpose and a key constraint. However, it lacks explicit guidance on when to use this tool vs. sibling prediction tools, which would make it fully 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?

All 4 parameters have descriptions in the schema (100% coverage), so the description does not need to explain them. It adds no additional parameter semantics beyond what the schema already provides.

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 function: 'Predict splice donor/acceptor sites', which is a specific verb+resource. It also names the model (G0 BigBird), helping to distinguish it from other prediction tools like predict_promoter or 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 provides a constraint ('Up to 500,000 bp') but does not explicitly state when to use this tool over alternatives or provide exclusions. Usage context is implied by the tool's name rather than spelled out.

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 all annotation hints false, the description carries the burden and discloses that the sequence 'passes through the LLM on THIS call' and does not save context on its own, alerting users to privacy/performance implications. It also hints at handle reuse, though it doesn't specify handle lifetime or persistence 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 concise and front-loaded with a clear first sentence, but the follow-up paragraph adds necessary caveats. Each sentence contributes, and it's not bloated, 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 description covers purpose, usage context, alternatives, and a key caveat, and the existence of an output schema means return values aren't needed. For a 2-param tool with weak annotations, this is complete and actionable.

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 (name and sequence) with descriptions, and the description doesn't add specific parameter-level details beyond the schema. It reinforces the purpose of the sequence but provides no extra syntax/format info, so a 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 states exactly what the tool does: 'Store a human-pasted sequence and return a handle to re-use it.' It specifies the resource (sequence) and the output (handle), and distinguishes itself from siblings by focusing on inline sequences and explicitly naming alternatives for server-side fetch.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when-to-use guidance: 'For a sequence you've already pasted into the conversation', and provides clear alternatives for large sequences: 'prefer fetch_ensembl_sequence / fetch_gene_for_expression / load_local_fasta'. This is a model example of usage direction.

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