Genomic Intelligence

fetch_gene_for_expression

Fetch a gene's sequence prepared for expression prediction.

    Resolves the gene's canonical-transcript TSS via Ensembl and stores a
    gene-sense sequence centred on it, as a handle to pass to
    predict_expression(sequence_ref=...). Longer TSS-centred sequence
    gives better predictions, so this already fetches as much flank on
    each side of the TSS as the listed expression models recommend (the
    largest bio_spec.recommended_flank_bp from list_models). One handle
    serves every expression model: the API reads what the chosen model
    needs around the TSS and ignores the rest.

    The handle records `tss_index` (the TSS offset into it), and
    predict_expression uses it when you do not pass one, so no offset
    arithmetic is needed. Every expression model accepts at least
    9,198 bp with the TSS at least 4,599 bp from each end. Near a
    chromosome end the flank is shortened to what fits (reported as
    `flank_shortened`), never below 4,599 bp; a TSS closer to the end
    than that is an error.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`gene`	Yes	Gene symbol (e.g. 'HBB').
`species`	No	Species name.	human

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedJul 27, 2026

TDQS

A4.4/5.0

Behavior5/5

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

With annotations present (readOnlyHint=false, openWorldHint=true), the description goes well beyond them: it discloses that a handle is stored, that Ensembl is contacted to resolve the canonical-transcript TSS, the minimum accepted size (9,198 bp; TSS at least 4,599 bp from each end), the flank_shortened behavior near chromosome ends, and the error condition when the TSS is too close to an end. The readOnlyHint=false annotation is consistent with the description's account of storing a handle.

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 lead sentence is front-loaded and the follow-on paragraphs each carry distinct operational information (model reuse, offset handling, flank minima). It is longer than strictly necessary and the indented block formatting is a little awkward, but no sentence is padding.

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?

For a tool with an output schema, the description supplies exactly the semantics an agent needs beyond it: handle reuse across models, automatic tss_index handling, the specific flank bounds and shortening behavior, and the error case. Nothing required to call it correctly is missing.

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 schema already documents 'gene' and 'species' adequately. The description adds no parameter-level detail (no format, casing, or species conventions), so the baseline 3 for fully-covered schemas 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?

The first sentence names a specific verb and resource ('Fetch a gene's sequence prepared for expression prediction') and immediately frames the output as a handle for predict_expression. This distinguishes it from siblings like fetch_ensembl_sequence, fetch_region, and load_demo_sequence, which do not produce an expression-ready TSS-centred handle.

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 states the intended downstream use ('as a handle to pass to predict_expression(sequence_ref=...)') and explains why one handle suffices for every expression model. It does not, however, explicitly state when to prefer a sibling such as fetch_ensembl_sequence or fetch_region, so the routing is implied rather than contrasted.

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?