Genomic Intelligence

list_models

Read-only

List available models for a task.

    Use to discover model ids before passing one as the `model`
    argument to a predict tool. The same catalog is also available
    as the resource `gi://models`.

    Returns a FLAT object — {task, default_model, models: [...]} — not the
    {data, meta} envelope the predict tools return. Each model carries a
    `bio_spec`, whose useful fields are `request_max_bp` (the enforced
    ceiling, 500,000 everywhere) and `context_window_bp` (what the model
    reads in one step — compare your sequence length against it: a shorter
    one is scored against a padded window). `trained_window_bp` is the fixed
    receptive field where there is no sliding window (9,198 for
    g0-expression). `request_max_bp` is the only one of the three that is a
    cap; the window fields describe what the model scores, not what the
    route accepts.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`task`	Yes	Task name. One of: promoter, splice, enhancer, chromatin, expression, annotation.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A4.4/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

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?