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 (null for a model
    without one). For expression, `recommended_flank_bp` is how many bp the
    model reads on each side of the TSS; longer TSS-centred input is
    better, and fetch_gene_for_expression already fetches the largest
    listed value. `request_max_bp` is the only cap; the other
    fields describe what the model reads, 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

Schema Changelog

Changes observed during successful MCP inspections.

First observedJul 27, 2026

TDQS

A4.2/5.0

Behavior4/5

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

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

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

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

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

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

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single `task` param already documents its enum of allowed values. The description implies a task scoping but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

Purpose5/5

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

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

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

Usage Guidelines5/5

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

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

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

All Genomic Intelligence tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?