Genomic Intelligence

store_inline_sequence

Store a human-pasted sequence and return a handle to re-use it.

    For a sequence you've already pasted into the conversation, this
    gives back a short handle so you can run several tasks on it
    without re-pasting the bases in each predict_* call. Note that the
    full sequence still passes through the LLM on THIS call — it does
    not save context on its own. For large sequences, prefer
    fetch_ensembl_sequence / fetch_gene_for_expression / load_local_fasta,
    which acquire the bases server-side and never round-trip them.

    A line-wrapped FASTA *body* may be pasted verbatim: whitespace is
    stripped before storing, so the handle's `length` counts bases and a
    later `tss_index` counts into the same string the API measures. (A
    FASTA `>` header line is not a sequence and is rejected by the API's
    alphabet check.)

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	No	Label for this sequence.	sequence
`sequence`	Yes	DNA bases to store and get a handle for. Line breaks are fine — whitespace is stripped, so the handle holds bases.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A5/5.0

Behavior5/5

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

Adds rich behavioral context beyond the sparse annotations: the full sequence passes through the LLM on this call, whitespace is stripped so handle length and tss_index align with the API's measurement, and FASTA header lines are rejected. No contradiction with annotations (readOnlyHint=false, destructiveHint=false).

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

Conciseness5/5

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

Every sentence adds distinct value: purpose, use-case, caveat, alternatives, and formatting details are clearly separated and front-loaded. The description is moderately long but tightly written with no filler.

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 2-parameter tool with an output schema, the description covers the full lifecycle: when to use, what happens, what to avoid, and important edge cases (FASTA headers, whitespace). It is complete without needing to describe 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.

Parameters5/5

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

Schema already covers both parameters (100% coverage), and the description adds meaningful semantics: explains that line-wrapped FASTA bodies can be pasted verbatim, whitespace is stripped, and how this affects the handle's measured length. This goes beyond the schema's basic descriptions.

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 exactly what it does: 'Store a human-pasted sequence and return a handle to re-use it.' The verb 'store' and resource 'sequence' are clear, and it distinguishes itself from siblings by contrasting with server-side fetch tools (fetch_ensembl_sequence, load_local_fasta) and by noting it avoids re-pasting for predict_* calls.

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?

Explicitly explains when to use: for sequences already pasted in conversation. Provides a clear exclusion: 'For large sequences, prefer fetch_ensembl_sequence / fetch_gene_for_expression / load_local_fasta' and warns about the LLM round-trip caveat. This is direct when/when-not guidance with named alternatives.

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?