Generated banner for Genomic Intelligence
Generated logo for Genomic Intelligence

Genomic Intelligence

K-DenseCommunityCreated by Genomic IntelligenceDistributed by K-Dense

  • Skill
  • Tool integration
  • Science and research
  • MIT
  • No issues found

From the author

Predicts regulatory features, gene structure, and expression directly from DNA sequence using Genomic Intelligence's hosted transformer DNA language models — no local GPU or model weights. Six tasks over a REST API and a hosted MCP server (keyless public demo): promoter regions, splice donor/acceptor sites, enhancer activity, chromatin state, sequence-to-expression (log TPM), and de-novo gene annotation, plus a composite find-genes-then-predict-expression workflow. Use when the user has a gene symbol, a genomic region, or a DNA/FASTA sequence and wants any of these predictions, mentions Genomic Intelligence, genomicintelligence.ai, api.genomicintelligence.ai, or mcp.genomicintelligence.ai.
— the description by Genomic Intelligence

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

Genomic Intelligence provides managed access to transformer DNA language models for sequence-based biological analysis. The platform offers six core tasks: promoter identification, splice site prediction, enhancer activity scoring, chromatin state annotation, gene expression prediction (log TPM), and de-novo gene annotation. It operates as a thin client, offloading heavy computation to hosted GPUs, and supports both a REST API for universal integration and an MCP server for handle-based workflows that keep large sequences out of the agent's context.

What it does

  • Predicts promoter regions and splice donor/acceptor sites from DNA sequences.
  • Scores enhancer activity and annotates chromatin states across hundreds of tracks.
  • Estimates gene expression levels (log TPM) based on cell-type context.
  • Performs de-novo gene and transcript annotation.
  • Executes composite workflows to identify genes and predict their expression in a single operation.
  • Provides handle-based sequence management via MCP to optimize context window usage.

When to use it

  • When you need to perform regulatory genomics analysis directly from DNA or FASTA sequences.
  • When you require model-based predictions for gene expression or structural annotation.
  • When working within an MCP-enabled agent environment to handle large genomic sequences efficiently.
  • When you need to integrate DNA language model inference into automated research pipelines.

Advantages

  • Eliminates the need for local GPU resources or model weight management.
  • Supports both synchronous and asynchronous processing for long-running tasks.
  • Provides a keyless public demo tier for rapid experimentation and testing.
  • Offers specialized tools for TSS-centered expression window calculations.
  • Standardized API and MCP interfaces ensure consistent model interaction.

Usage examples

“Find the promoter regions in the provided TP53 genomic sequence.”
The agent calls the promoter prediction task and returns a list of identified promoter regions with their associated confidence scores.
“Predict the expression level of the HBB gene in K562 cells.”
The agent fetches the TSS-centered sequence for HBB and submits it to the expression prediction model with the required cell-type description.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/k-dense-ai/genomic-intelligence/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip genomic-intelligence.zip -d .agents/skills

Documentation by Genomic Intelligence

Genomic Intelligence — DNA Sequence Models

Genomic Intelligence (GI) serves transformer DNA language models over six sequence-analysis tasks on managed GPUs. Give it a gene symbol, a genomic region, or a DNA/FASTA sequence; it returns structured predictions — promoter regions, splice sites, enhancer activity, chromatin state, expression (log TPM), and de-novo gene annotation. Nothing runs locally: no model weights, no GPU, no heavy Python stack. It is a thin client over a hosted, versioned inference API.

Official docs: docs.genomicintelligence.ai · REST contract at api.genomicintelligence.ai/v1/openapi.json · hosted MCP server at https://mcp.genomicintelligence.ai/mcp

When to use this skill

Use GI when the user has DNA and wants a model prediction:

  • Find promoters in a genomic region (promoter)

  • Predict splice donor/acceptor sites (splice)

  • Score enhancer activity — developmental & housekeeping (enhancer)

  • Annotate chromatin state across hundreds of tracks (chromatin)

  • Predict expression as log(TPM+1) from a sequence + cell-type context (expression)

  • Annotate genes/transcripts de novo, no reference needed (annotation)

  • Find the genes in a region and predict each one's expression (composite)

Not for local alignment, variant calling, or file I/O — use a local tool (BioPython, bcftools) for those. GI is for model inference from sequence.

Research and development use. Not for clinical or diagnostic decisions.

Two ways to call GI

Hosted MCP server (keyless; preferred on MCP hosts)

GI hosts an MCP server at https://mcp.genomicintelligence.ai/mcp (Streamable HTTP). When your agent host supports MCP, prefer it: it works keyless against a rate- and concurrency-limited public demo tier, and an optional gi_ bearer key raises those limits. It exposes acquisition tools that return a sequence handle (sequence_ref) and predict_* tools that take that handle, so large sequences stay out of the context. See MCP workflow below and references/mcp.md.

REST API (universal)

Plain HTTP with requests against https://api.genomicintelligence.ai/v1. The REST path requires a GI_API_KEY (a gi_ bearer). Use it on any host, in scripts, or when you need the raw envelope. See Core REST workflow.

Access and authentication

  1. The hosted MCP demo is keyless — try it with nothing set.

  2. REST prediction and job operations need a key, sent as Authorization: Bearer <key>. Public GET /v1/tasks/{task}/models discovery needs no key and is rate-limited by source IP; inspect model windows and bounds before requesting access. See the current authentication contract. Request a prediction key at [email protected].

  3. Never hardcode the key. Read it from the GI_API_KEY environment variable (or a .env via python-dotenv). Never commit keys.

export GI_API_KEY="gi_yourkeyhere"     # optional for MCP; required for REST
export GI_BASE_URL="https://api.genomicintelligence.ai"   # override for staging

Keys are scoped to a partner tier with concurrency and per-minute caps. A 429 means you hit a cap — back off and retry, or ask GI to raise your tier.

The six tasks

Each task is its own published operation with its own request schema, its own minimum length, and its own closed options object — POST /v1/tasks/promoter/predict, /v1/tasks/splice/predict, /v1/tasks/enhancer/predict, /v1/tasks/chromatin/predict, /v1/tasks/annotation/predict, /v1/tasks/expression/predict. Each path is a literal string, so nothing needs to be constructed, and there is no shared PredictRequest schema. Body is {sequence, sequence_name?, model?, options?}, returning a {data, meta} envelope. What differs per task:

TaskRecommended modeAccepted lengthcontext_window_bpNotes
promotersync300–500,000 bp2,000 bpsliding-window promoter regions
splicesync100–500,000 bp15,000 bpdonor/acceptor sites (long-context BigBird); strand-specific — feed transcript orientation
enhancersync50–500,000 bp249 bpdev + housekeeping scores (DeepSTARR, Drosophila)
chromatinsync200–500,000 bp1,000 bphundreds of tracks (DeepSEA)
expressionsync9,198–500,000 bpn/a (trained_window_bp 9,198)log(TPM+1); needs tss_index unless exactly 9,198 bp, plus a cell-type description
annotationasync1,000–500,000 bpn/ade-novo transcripts; submit + poll; sync JSON above 200,000 bp is 413 sync_too_large

Recommended mode is guidance, not a constraint — every task accepts both. Omit Prefer for a synchronous 200; send Prefer: respond-async for a 202 plus GET /v1/tasks/jobs/{job_id}. The one enforced limit is per operation: where /v1/openapi.json publishes x-sync-limit-bp on a POST, a synchronous JSON request above that length is 413 sync_too_large — 200,000 bp on annotation and 50,000 bp on the composite workflow in contract revision 16. Read the field rather than memorising the numbers. Annotation BED/GFF3 stays synchronous at any admitted length and can time out; the other five predict tasks have no hard sync cap.

The minimum is admission control, not regime. A request above the floor but shorter than the selected model's bio_spec.context_window_bp is accepted and scored — against a window padded out to the context window. Enhancer is the sharp case: the floor is 50 bp but the context window is 249 bp, so 50–248 bp is scored mostly on padding. Compare your length against context_window_bp from GET /v1/tasks/{task}/models to know whether the model saw real sequence. Longer-than-context input is fine — the scanner steps a prediction window at a time and pads only the final partial window.

Under the floor and over the 500,000 bp cap are both 422 validation_failed at loc ["body","sequence"]; over-length is not a 413. All lengths are measured after whitespace is stripped, so a line-wrapped FASTA body can be pasted verbatim (a > header line still fails the alphabet check).

options is typed and closed (additionalProperties: false) per task — an unknown key is a hard 422 validation_failed with type: "extra_forbidden", never ignored:

Taskoptions keys
promoterthreshold (0–1, default 0.5)
splicethreshold (0–1, default 0.5), site_types (subset of ["donor","acceptor"], default both)
enhancer(none)
chromatinthreshold (0–1, default 0.5)
annotationbatch_size (1–128, default 8), shift_coordinates, reverse_complement (default true)
expressiondescription — required, and the only key

Prefer: respond-async is a declared header on all six predict operations and on the composite, not just annotation — see Async.

Omit model and the API uses the task's default — that is the recommended call. Default model IDs are intentionally not documented here: defaults change and retired IDs fail hard, so never hardcode one. To pin a model, or to pick a non-human one (Drosophila, yeast, and Arabidopsis models exist for several tasks), discover IDs at call time with GET /v1/tasks/{task}/models (REST) or list_models (MCP) — and never invent one. Full per-task output shapes are in references/tasks.md.

expression is the strictest of the six: alone among them its schema requires options as well as sequence. Three hard rules it enforces — every violation is a 422, nothing is padded or clamped, and there is no opt-out flag, header, or query parameter:

  • It always scores exactly one 9,198 bp TSS-centred window — sequence[tss_index-4599 : tss_index+4599]. The endpoint itself accepts 9,198–500,000 bp; anything below 9,198 bp is rejected outright.

  • tss_index is required unless the sequence is exactly 9,198 bp. It is the 0-based TSS offset into the whitespace-stripped sequence, bounded by 4599 ≤ tss_index ≤ len(sequence) − 4599. At exactly 9,198 bp it defaults to 4,599, the only legal value there. So you may submit a whole locus (up to 500 kb) and let the server cut the window — but the server does not discover the TSS for you (that is the composite workflow's job), and does not reverse-complement: submit gene-sense sequence.

  • options.description — a cell-type / assay string (e.g. "K562 cells") — is required, and is the only key expression accepts inside options. Unknown top-level body fields are rejected too.

Note: the legal tss_index range is wide, so an offset that is merely wrong (counted over raw FASTA characters including newlines, or relative to a locus start rather than the submitted slice) does not error — it returns a confident 200 for the wrong window. Assert on meta.task_specific_counts.scored_window / .tss_index in the response. The submitted length is meta.sequence_length; the scored width is always 9,198, i.e. scored_window[1] - scored_window[0]. In revision 16, data.input contains only sequence_name, description, and tss_index; it does not contain the submitted length or scored window.

Both tss_index violations — "required unless exactly 9,198 bp" and the range check — come from a whole-model validator, so they surface at the body level rather than under tss_index. Match on error.code == "validation_failed" and use the message for display only. Any loc tuple quoted in this skill is illustrative of that shape, not part of the contract: it is not published in the schema and must not be branched on.

Sequence acquisition

You rarely start from a raw 9,198 bp string. Acquire sequence first:

  • From a gene symbol → MCP fetch_ensembl_sequence(gene=...); from coordinates → fetch_region(region=...). Both acquire public reference sequence (no key), using a bundled coordinate catalog, cache, UCSC, or Ensembl; retain the returned provenance. REST users can query Ensembl REST directly. (find_genes is the annotation task, not an acquisition tool.)

  • For expression → use the TSS-centred fetch so the window is exactly 9,198 bp. MCP: fetch_gene_for_expression (handles the centring). Otherwise fetch a wider locus and pass the TSS as tss_index so the server cuts the window — but compute that offset on the stripped nucleotide string, not on file characters.

  • From a local FASTA → MCP store_inline_sequence, or read the file yourself for REST. (load_local_fasta exists only in local deployments, not on the hosted server.)

  • A demo sequence → MCP load_demo_sequence(name=...) returns a ready handle for a keyless smoke test; name is required.

See references/sequence-acquisition.md for the exact Ensembl calls and the expression-window math.

Core REST workflow

The following transport recipe was tested with mocked responses, not authenticated inference. Supply a task-appropriate seq before calling it. Use the exact expression-context wording consistently when comparing predictions.

import os
import time
import requests

BASE = os.environ.get("GI_BASE_URL", "https://api.genomicintelligence.ai").rstrip("/")
HEADERS = {"Authorization": f"Bearer {os.environ['GI_API_KEY']}"}
TASKS = {"promoter", "splice", "enhancer", "chromatin", "annotation", "expression"}

def predict(task, sequence, sequence_name, model=None, options=None, tss_index=None):
    if task not in TASKS:
        raise ValueError("Unknown GI task")
    body = {"sequence": sequence, "sequence_name": sequence_name}
    if model is not None:
        body["model"] = model
    if options is not None:
        body["options"] = options
    if tss_index is not None:
        if task != "expression":
            raise ValueError("tss_index is expression-only")
        body["tss_index"] = tss_index
    r = requests.post(f"{BASE}/v1/tasks/{task}/predict", headers=HEADERS,
                      json=body, timeout=(10, 300))
    r.raise_for_status()
    if r.status_code != 200:
        raise RuntimeError(f"Unexpected prediction status {r.status_code}")
    return r.json()

# After acquiring and checking an appropriate promoter sequence:
# out = predict("promoter", seq, "TP53_region")
# print(out["meta"]["task_specific_counts"]["regions_found"])

# A validated gene-sense expression window, or longer locus with known TSS:
# out = predict("expression", locus_seq, "HBB", tss_index=tss_offset,
#               options={"description": "polyA plus RNA-seq; Homo sapiens K562"})
# assert out["meta"]["sequence_length"] == len("".join(locus_seq.split()))
# assert out["meta"]["task_specific_counts"]["scored_window"] == [tss_offset-4599, tss_offset+4599]
# print(out["data"]["prediction"]["expression_log_tpm"])

data.summary is for display: its keys may change without a contract revision. Use the declared fields in data and meta.task_specific_counts for computation. A timeout or proxy error may have a non-JSON body; it does not establish that the inference never ran. Preserve the request ID and avoid blind POST resubmission.

Send Prefer: respond-async on any of the six tasks or the composite. A 202 is {data: {job_id, status: "accepted", links}, meta}. Content-Location and X-Job-Id identify the same job. Async is JSON-only; text format plus async is 400. Save the job ID before polling. This bounded polling example surfaces HTTP failures (including 429 and 410) for the caller to handle:

def submit_annotation(sequence, sequence_name):
    r = requests.post(f"{BASE}/v1/tasks/annotation/predict",
                      headers={**HEADERS, "Prefer": "respond-async"},
                      json={"sequence": sequence, "sequence_name": sequence_name},
                      timeout=(10, 30))
    r.raise_for_status()
    if r.status_code != 202:
        raise RuntimeError(f"Unexpected submission status {r.status_code}")
    return r.json()["data"]["job_id"]

def wait_for_job(job_id, max_polls=120):
    if max_polls < 1:
        raise ValueError("max_polls must be positive")
    for attempt in range(max_polls):
        r = requests.get(f"{BASE}/v1/tasks/jobs/{job_id}", headers=HEADERS,
                         timeout=(10, 30))
        r.raise_for_status()  # failed job -> its underlying 4xx/5xx, not 200
        if r.status_code == 200:
            return r.json()
        if r.status_code != 202:
            raise RuntimeError(f"Unexpected polling status {r.status_code}")
        if attempt + 1 < max_polls:
            time.sleep(5)
    raise TimeoutError(f"Polling stopped; resume this job rather than resubmit: {job_id}")

# job_id = submit_annotation(seq, "TP53_region")  # persist this ID
# result = wait_for_job(job_id)
# assert result["data"]["task"] == "annotation"
# transcripts = result["data"]["transcripts"]

200 is completion; 202 contains data.status and data.progress. Unknown/not-owned jobs are 404; expired jobs are 410 job_expired. Results are documented as retained 24 hours from last activity; save results locally. Job listing is a recent, bounded list, not a paginated archive.

MCP workflow (handle-based)

On an MCP host, acquire a handle, then predict against it — sequences stay out of the context:

# 1. Acquire a sequence handle (each returns data.ref, passed as sequence_ref):
load_demo_sequence(name="promoter_tp53")  # keyless smoke test; name is required
fetch_ensembl_sequence(gene="TP53", flank_bp=5000)  # include regulatory context
fetch_region(region="chr11:5,225,000-5,235,000")   # coordinates -> handle
fetch_gene_for_expression(gene="HBB")     # TSS-centred 9,198 bp handle for expression

# 2. Predict against the handle:
predict_promoter(sequence_ref=<ref>)
predict_expression(sequence_ref=<ref>, description="K562 cells")
predict_splice(sequence_ref=<ref>)        # + predict_enhancer / predict_chromatin

# 3. Annotation on MCP is `find_genes` (there is no predict_annotation).
#    It takes a handle, not a region, and runs async internally:
find_genes(sequence_ref=<ref>)            # wait=True (default) returns the result
find_genes(sequence_ref=<ref>, wait=False)  # own key only -> job_id; poll get_job(job_id)

# Acquisition returns data.ref; use that value as sequence_ref.
# Discover models with list_models(task); reference context lives in the
# gi://models, gi://docs/tasks, and gi://account MCP resources.

The shared demo disables get_job, list_jobs, and detached wait=False. Keep wait=True there; a wait timeout is an error, not a recoverable job handle. See MCP details for resources, result envelopes and lifetimes.

Composite: find genes, then predict expression

To answer "what genes are in this region and how are they expressed?", use the composite:

  • MCP: find_genes_and_predict_expression(sequence_ref=..., description=...) — takes a handle, not a region (acquire one with fetch_region first); description is required. Finds genes in the sequence and returns an expression prediction for each.

  • REST: one call — POST /v1/workflows/find-genes-and-predict-expression, body {sequence, options} with sequence 1,000–500,000 bp and options.description (cell type / assay) required; a missing or empty description is a 422 validation_failed. It annotates, centres a 9,198 bp window on each discovered gene's TSS (padding with N up to half the window rather than dropping an edge gene), and returns a prediction per gene. meta.task_specific_counts = {genes_found, genes_predicted, genes_skipped} with genes_predicted + genes_skipped == genes_found; per-gene causes in data.expression_predictions[].skip_reason. Above 50,000 bp (its x-sync-limit-bp) it forces async: a synchronous request over that size is 413 sync_too_large with error.details = {sequence_length, threshold} — retry the same body with Prefer: respond-async.

The API also publishes a separate, under-development VCF workflow. Its outputs are not established model results when meta.model is absent; see the bounded contract note.

Errors

Codeerror.codeMeaningAction
400bad_requestMalformed requestCheck the body shape
401 / 403unauthorized / forbiddenMissing/invalid key (REST)Set GI_API_KEY; or use the keyless MCP demo
404not_foundUnknown task (/v1/tasks/bogus/predict) or unknown jobCheck the task name — an unrecognised task is a 404, not a 422
413payload_too_largeRaw request body over 16 MiBSplit the input — this is the body cap, not the sequence cap
410job_expiredResult retention elapsedRecover saved results or deliberately submit new work
413sync_too_largeSynchronous JSON request above the operation's x-sync-limit-bp (200,000 bp on annotation, 50,000 bp on the composite)Retry with Prefer: respond-async
415unsupported_formatUnsupported format query valueUse a format the task supports; there is no silent fallback to JSON
422validation_failedThe most common failure: sequence under the task floor or over 500,000 bp, expression below 9,198 bp, a missing/out-of-range tss_index, a missing options.description, or any unknown body or options key; also the splice response capRead the message; fix the body
429rate_limited / too_many_requestsRate / concurrency capBack off (honour Retry-After); ask GI to raise your tier
5xxinternal_error / service_unavailable / model_loading / timeoutServer errorPreserve request/job IDs; retry polling with backoff, avoid blind POST resubmission

error.code is a closed 21-value enum (bad_request, unauthorized, forbidden, not_found, conflict, job_expired, payload_too_large, sync_too_large, unsupported_format, validation_failed, too_many_requests, rate_limited, internal_error, timeout, insufficient_memory, model_not_found, task_not_supported_by_model, model_loading, service_unavailable, http_error, unknown); treat an unlisted value as a generic failure, not a parse error.

Branch first on code, never on message text or loc. Pydantic request failures usually carry details.errors; the splice response cap instead carries record_count, maximum_records, sequence_length, and threshold. Handle these as distinct optional detail shapes. More than 20,000 splice records causes 422 validation_failed, not a truncated result; raise the threshold and record that changed analysis setting. See task caveats.

For correlation, error.request_id and the X-Request-Id header are both documented on API responses, and success envelopes carry meta.request_id. Reading the header first remains a safe default. API responses document RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset, RateLimit-Policy; a 429 adds Retry-After. The limit is a burst bucket, not rpm: the published x-rate-limit-burst-divisor is 6, so the sustained minute allowance is six times that header. Proxy failures may omit these headers and the usual JSON error envelope.

Reviewed 2026-10-01 against live OpenAPI info.version 2026.09.22.2 (af902d84), x-contract-revision: 16, and gi-mcp 0.1.0a21. Record the contract revision, resolved model ID, assembly, strand/TSS provenance, options, and experimental description with results. Hash the exact submitted bases when available. A handle-only MCP acquisition returns a preview, not the full bases or a checksum: preserve its acquisition parameters and source release metadata, and do not invent a hash or claim byte-level verification. Review evidence and limits distinguish public discovery, source review, and mocked examples from inference validation.

Reference files

  • references/tasks.md — per-task output shapes, model registries, the async annotation contract.

  • references/api-and-auth.md — REST endpoints, the {data, meta} envelope, auth, base-URL override, tiers.

  • references/mcp.md — the hosted MCP tool list, the handle-based flow, and the gi:// resources.

  • references/sequence-acquisition.md — Ensembl fetch calls and the expression-window (9,198 bp, TSS-centred) math, including tss_index.

Files

references/tasks.md

Tasks Reference

Six DNA-sequence tasks, each its own published REST operation — POST /v1/tasks/promoter/predict, /v1/tasks/splice/predict, /v1/tasks/enhancer/predict, /v1/tasks/chromatin/predict, /v1/tasks/annotation/predict, /v1/tasks/expression/predict — with body {sequence, sequence_name?, model?, options?}, returning a {data, meta} envelope. Each path is a literal string, and each carries its own request schema, its own minLength, and its own closed options object; there is no shared PredictRequest. On MCP, use predict_<task>(sequence_ref=...), except annotation is find_genes(sequence_ref=...).

Omit model to get the task's default — the API resolves it server-side (model is optional: "If omitted, the task's default model is used."). Default model IDs are deliberately not listed here: defaults change and old IDs are retired, so a hardcoded ID is a future hard failure. Discover them at call time with GET /v1/tasks/{task}/models (REST) or list_models(task) (MCP), and never invent one.

Source of truth for bounds: the live OpenAPI at https://api.genomicintelligence.ai/v1/openapi.json.

TaskRecommended modeAccepted lengthcontext_window_bpDefault architecture
promotersync300–500,000 bp2,000 bpsliding-window; human/mammalian
splicesync100–500,000 bp15,000 bpBigBird (long-context)
enhancersync50–500,000 bp249 bpDeepSTARR — Drosophila
chromatinsync200–500,000 bp1,000 bpDeepSEA — hundreds of tracks
expressionsync9,198–500,000 bp (scores one 9,198 bp window)n/a (trained_window_bp 9,198)log(TPM+1)
annotationasync1,000–500,000 bpn/ade-novo transcripts; sync JSON above 200,000 bp (x-sync-limit-bp) is 413 sync_too_large

Recommended mode is guidance, not a constraint — every task accepts both. Omit Prefer for a synchronous 200; send Prefer: respond-async for a 202 plus GET /v1/tasks/jobs/{job_id}. The one enforced limit is per operation: where /v1/openapi.json publishes x-sync-limit-bp on a POST, a synchronous JSON request above that length is 413 sync_too_large — 200,000 bp on annotation and 50,000 bp on the composite workflow in contract revision 16. Read the field rather than memorising the numbers. Annotation BED/GFF3 remains synchronous above its JSON cap and can time out; the other five predict tasks have no hard sync cap.

The minimum is published as minLength on each task's request schema and enforced before any model loads. There are no per-model floors: a task's floor is the strictest its models need, and every model stays listed and loadable.

Floor ≠ regime. A request above the floor but shorter than the selected model's bio_spec.context_window_bp is accepted and scored — against a window padded out to the context window. Enhancer is the sharp case: the floor is 50 bp while the context window is 249 bp, so 50–248 bp is scored mostly on padding. Compare your length against context_window_bp to know whether the model saw real sequence. Longer-than-context input is fine — the scanner steps a prediction window at a time and pads only the final partial window.

Under the floor and over the cap are both 422 validation_failed at loc ["body","sequence"]; over-length is not a 413. All lengths are measured after whitespace is stripped.

options is typed and closed (additionalProperties: false) per task — an unknown key is a hard 422 (type: "extra_forbidden"), never ignored:

Taskoptions keys
promoterthreshold (0–1, default 0.5)
splicethreshold (0–1, default 0.5), site_types (subset of ["donor","acceptor"], default both)
enhancer(none)
chromatinthreshold (0–1, default 0.5)
annotationbatch_size (1–128, default 8), shift_coordinates, reverse_complement (default true)
expressiondescription — required, and the only key
compositedescription, annotation_model, expression_model, batch_size, shift_coordinates

Per-task output format values (an unsupported one is 415 unsupported_format, never a silent fallback to JSON; text formats are synchronous-only): promoter json|bed|bedgraph, splice json|bed|gff3, enhancer json|bedgraph, chromatin json|bed, annotation json|bed|gff3, expression JSON only.

Reading outputs

Narrow on data.task. The six tasks declare data.model, data.input, and data.summary; summary keys are deliberately outside the stable contract. Nested region/window/site records are open objects, so inspect actual records instead of assuming every record has name or strand. Preserve input coordinates and orientation separately. Stable counts live in meta.task_specific_counts, not summary aliases:

TaskDeclared data fieldsDeclared counts
promoterregions, window_detailswindows_processed, regions_found
splicesites, tracks, window_detailswindows_processed, sites_found
enhancerwindows, trackswindows_processed
chromatinwindows, trackswindows_processed, total_annotations
annotationtranscriptstranscripts_found
expressionpredictiontss_index, scored_window (schema permits null; check before use)

promoter

Sliding-window classification, with promoter regions and individual window scores. Current public discovery includes human, Drosophila, yeast, and Arabidopsis models. Check the chosen model's organism and window; the default is human. A predicted region is a model output, not experimentally established promoter activity or a transcription start site annotation.

splice

The default BigBird model is strand-specific. Submit transcript orientation; reverse-complement a minus-strand locus before scoring. The official contract warns that wrong-strand input still yields plausible, high-scoring sites. Neither confidence, count, nor the presence of GT/AG motifs validates orientation. There is no promised strand field on a site; track orientation caller-side.

start/end bound a scored BPE token span, typically 4–8 bases, with token_index identifying the token. They do not identify a base-resolution junction. GFF3 exports retain this span semantics. Do not report an invented single-base donor/acceptor coordinate or treat overlap with a reference junction as exact localization.

More than 20,000 emitted sites causes 422 validation_failed; the service rejects the request rather than returning a truncated list. The check occurs during inference, so an accepted input length does not guarantee success. details can contain record_count, maximum_records, sequence_length, and threshold instead of details.errors. Avoid threshold zero: the official limits guide recommends 1e-3 for low-threshold exploration. Increasing a threshold changes recall; record it and do not equate a filtered list with every biological splice site. This cap is documented in the guide but not represented as an x- extension or typed detail schema in revision 16.

enhancer

Current DeepSTARR models target Drosophila, returning continuous developmental and housekeeping activity scores per window. The scores are not calibrated probabilities or human enhancer evidence. data.windows and data.tracks are the declared outputs; summary aliases are display-only.

chromatin

The current DeepSEA models score 919 ENCODE features, grouped into eight track categories (DNase, CTCF, Pol2, c-Myc, H3K27ac, H3K27me3, H3K4me1, Other). The API declares data.windows and data.tracks; do not promise an unfiltered 919-column matrix. options.threshold gates reported labels and meta.task_specific_counts.total_annotations counts reported annotations.

expression

Expression as log(TPM+1) from a fixed window. Its operation is POST /v1/tasks/expression/predict, schema ExpressionPredictRequest — alone among the six it requires options as well as sequence. Body: {sequence, options, tss_index?, sequence_name?, model?}, closed to unknown fields. Three enforced requirements, each a 422 when violated:

  1. 9,198–500,000 bp. The model scores exactly one 9,198 bp window centred on the TSS — sequence[tss_index-4599 : tss_index+4599] — but the endpoint accepts up to 500 kb and slices for you. Below 9,198 bp is rejected; nothing is padded or truncated.

  2. tss_index — 0-based TSS offset into the whitespace-stripped sequence. Required unless the sequence is exactly 9,198 bp (where it defaults to 4,599, the only legal value). Bounds: 4599 ≤ tss_index ≤ len(sequence) − 4599. The server does not find the TSS for you and does not reverse-complement — submit gene-sense.

  3. options.description — a cell-type / assay string (e.g. "K562 cells"). Required, and the only key options accepts here.

Whitespace is stripped before lengths and tss_index are interpreted, so a line-wrapped FASTA body can be pasted verbatim — but a > header line cannot (it fails the A/C/G/T/N alphabet check), and offsets must be counted on the stripped string, not on file characters.

Result: data.prediction.expression_log_tpm (and expression_tpm). meta.task_specific_counts carries tss_index and scored_window ([start, end], always 9,198 wide) — assert on it, because an in-range but wrong tss_index scores the wrong window with a 200. data.input echoes only sequence_name, description, and tss_index in revision 16. Read the submitted length from meta.sequence_length and the window from meta.task_specific_counts.scored_window; do not read removed data.input.scored_window or data.input.submitted_sequence_length fields. The exact description text conditions the score: hold it fixed in comparisons. Canonical transcript selection is a reference convention, not proof of the biologically active TSS in the assayed cell type.

Both tss_index failures come from a whole-model validator and so report at loc: ["body"], never body.tss_index. Match on error.code == "validation_failed" — never on loc.

annotation

De-novo gene / transcript structure — transcript intervals and strand, no reference annotation. Run it async (Prefer: respond-async is available on every predict operation; annotation is the one that most often needs it): submit with Prefer: respond-async → job_id; poll GET /v1/tasks/jobs/{job_id} until it returns 200. data.transcripts lists each transcript with name, start, end, strand, score, plus structure fields (length, tss_position, polya_position, transcript_type, exons, introns, cds).

Composite: find genes + predict expression

"What genes are in this region, and how are they expressed?" — MCP find_genes_and_predict_expression(sequence_ref, description) takes a handle, not a region (acquire one with fetch_region first); description is required. It finds genes in the sequence and returns an expression prediction per gene. The composite does its own gene finding and windowing, so it has no 9,198 bp floor and takes no tss_index.

Over REST it is a single published operation: POST /v1/workflows/find-genes-and-predict-expression, request FindGenesAndPredictExpressionRequest — sequence 1,000–500,000 bp and options both required, and options.description required in FindGenesAndPredictExpressionOptions in revision 16. A missing/empty description fails validation. Optional: annotation_model, expression_model, batch_size (1–128, default 8), shift_coordinates.

It cuts a TSS-centred 9,198 bp window per discovered gene, padding with N up to half the window rather than dropping an edge gene — the direct expression route refuses to pad at all. meta.task_specific_counts = {genes_found, genes_predicted, genes_skipped} with genes_predicted + genes_skipped == genes_found; per-gene causes in data.expression_predictions[].skip_reason. Check skipped before interpreting the per-gene expression (log(TPM+1)) and expression_tpm fields; there is no required nested prediction object on a composite gene record.

Above 50,000 bp (its x-sync-limit-bp) it forces async: a synchronous JSON request over that size is 413 sync_too_large with error.details = {sequence_length, threshold}. Retry the same body with Prefer: respond-async. annotation carries the same guard at 200,000 bp; no other predict task publishes one today.

The equivalent by hand is annotation to discover genes, then one expression call per gene with that gene's window and tss_index — useful when you want per-gene control, though you then own the TSS-centring the composite does for you.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs an MCP server, Needs an API key, Needs Python

The author says: Python 3.10+ with the `requests` library for the REST examples. Network access required. The REST `/v1` API needs a `GI_API_KEY` (a `gi_` bearer); the hosted MCP server at mcp.genomicintelligence.ai/mcp works keyless against a rate- and concurrency-limited public demo tier, key optional.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
Genomic Intelligence
Publisher
K-Dense (Community)
Distributed by
K-Dense
Source
K-Dense-AI/scientific-agent-skills · skills/genomic-intelligence · commit a25cf9e
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE.md)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Genomic Intelligence or K-Dense.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download genomic-intelligence.zip