Genomic Intelligence

find_genes

Read-only

Find genes (transcript intervals) in a genomic region (async, ~8-25s).

    Takes 1,000–500,000 bp. The floor is the strictest of the scanning
    tasks: gene finding needs a region, not a site. (Only expression's
    9,198 bp is higher, and that is a fixed window rather than a minimum
    region size.)

    Gene-finding: detects transcript boundaries (TSS + PolyA) and returns
    one interval per predicted transcript — start/end, strand, a
    confidence score, and predicted TSS/PolyA positions (BED-style feature
    intervals, not free-text notes). Use this for "what genes are here",
    "find / locate genes", or "annotate this region".

    Each transcript also carries its type (mRNA/lnc_RNA) and internal
    exon/intron/CDS structure in `exons`/`introns`/`cds` arrays, plus a
    browser-ready GFF3 track in `data.formats.gff3`. To get each gene's
    *expression* from a raw region, use find_genes_and_predict_expression
    instead — expression needs a per-gene TSS window, so predict_expression
    cannot run on a whole region.

    Submits an async job internally. With wait=True (default), blocks and
    streams progress, then returns the result {data, meta} — it never
    returns a job_id on this path. (If a generous block ceiling is
    exceeded it returns a timeout error, not a job handle.) With
    wait=False (detached), returns {data: {job_id, status: 'submitted'}}
    immediately — poll it with get_job.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`wait`	No	Default True: block and stream progress until the result is ready. Set False for detached mode — returns a job_id immediately to poll with get_job.
`model`	No	Optional model id; omit for the task default. See list_models.
`sequence`	No	DNA bases A/C/G/T/N (case-insensitive). Line breaks are ignored (a wrapped FASTA body may be pasted verbatim; a `>` header line may not). Mutually exclusive with `sequence_ref`.
`sequence_ref`	No	Handle (seq_…) from any acquisition tool (fetch_ensembl_sequence, fetch_region, fetch_gene_for_expression, load_demo_sequence, load_local_fasta, store_inline_sequence). Mutually exclusive with `sequence`.
`sequence_name`	No	Label echoed back in the response (ignored when `sequence_ref` is used).	sequence

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A4.6/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All Genomic Intelligence tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation5/5

Each tool targets a distinct operation: fetching gene/region/expression-window sequences, finding genes, predicting chromatin/enhancer/expression/promoter/splice, and managing jobs/models. The fetch tools are explicitly cross-referenced with guidance on which to use, eliminating ambiguity.

Naming Consistency5/5

All tools follow a consistent lowercase snake_case verb_noun pattern, with clear verbs like fetch, find, predict, get, list, load, and store. Even compound names like find_genes_and_predict_expression remain readable and predictable.

Tool Count5/5

Fifteen tools is at the upper end of the ideal range but each tool earns its place: five prediction tasks, five sequence acquisition paths, two gene-finding tools, plus job and model management. No tool feels redundant or superfluous.

Completeness4/5

The surface covers sequence acquisition, gene finding, five prediction tasks, async job polling, and model discovery—strong coverage for the stated domain. A minor gap is that store_inline_sequence references a load_local_fasta tool that does not exist in the tool list, though agents can work around it via fetch_ensembl_sequence or fetch_region.

Resources

Need Help?