Skip to main content
Glama
dna-seq
by dna-seq

Download sample genome

download_sample_genome
Idempotent

Download public sample WGS VCFs from Zenodo to test polygenic risk scores without your own data. Optionally auto-normalize to a compute-ready Parquet for immediate use.

Instructions

Download a public sample WGS VCF from Zenodo to try PRS without your own data.

Two whole-genome sequencing (WGS) datasets open-sourced by the just-dna-lite project are pre-configured — download both when you want a multi-person comparison:

  • sample="anton" — Anton Kulaga's genome (~482 MB, CC0 public domain, Zenodo record 18370498, file: antonkulaga.vcf).

  • sample="livia" — Livia Zaharia's genome (~349 MB, CC-BY-4.0, Zenodo record 19487816, file: SIMHIFQTILQ.hard-filtered.vcf.gz).

Pass record_url (e.g. 'https://zenodo.org/records/18370498') to fetch any other Zenodo record, and filename to pick a specific file when a record has several.

The downloaded VCF lands under <cache_dir>/samples/ (or output_dir) and is a drop-in path for normalize_vcf / compute_prs / compute_prs_by_trait (including samples=["Anton=<path>", ...]).

auto_normalize defaults to True: the download is normalized to a reusable Parquet in the same call, so data carries both path (the raw VCF) and normalized_path — a one-call, compute-ready genotype source with no separate normalize_vcf round-trip. (Normalization is idempotent, so a re-download of an already-staged sample is cheap.) Pass auto_normalize=False to fetch the raw VCF only.

Use list_genomes to see which genomes have already been downloaded and/or normalized.

Idempotent: if the target VCF already exists with the size Zenodo reports, the ~hundreds-of-MB download is skipped and the cached file is reused; likewise a present Parquet skips re-normalization. data echoes reused_cache (download skipped) and downloaded_bytes (bytes actually transferred, 0 on a cache hit) so the caller can tell a cache hit from a fresh fetch. Pass force=True to re-download/re-normalize regardless.

Returns a PRSJob immediately. When done, result is an OpResult whose data carries the local path. Poll prs_job_status if status is still running — the download is hundreds of MB.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
forceNo
sampleNoanton
filenameNo
output_dirNo
record_urlNo
auto_normalizeNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
toolYesTool that created the job.
errorNoFailure message when status is failed.
job_idYesPass this to prs_job_status until status is done or failed.
resultNoWhen status is done: the original tool payload (TraitPRSReports, NormalizeResult, OpResult, or a list of PRSResult). Read html_link / result_paths from this object.
statusYesqueued/running: call prs_job_status. done: read result and html_link. failed: read error. Do not start a second identical compute while queued/running.
messageYesLatest progress line.
progressNoCompleted work units, when known.
html_linkNoPRIMARY REPORT DELIVERY TARGET. When set, put this exact value in the user reply as a markdown link and explicitly tell the user to open the interactive report. It is an HTTP URL when available and a file:// URI for local stdio. Never omit, fetch, or paste the HTML.
poll_withNoPoll this tool with job_id. Optional wait_seconds keeps one poll under typical client timeouts (try 25).prs_job_status
created_atYesUTC timestamp when the job was created.
html_errorNoOptional HTML-generation error. Scores remain valid when this is set.
progress_totalNoTotal work units, when known.
Install Server

TDQS

A4.9/5.0
Behavior5/5

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

The description provides extensive details beyond annotations: idempotency with size-checking, cache reuse, force flag behavior, return of PRSJob and OpResult with data.path, and distinguishes cache hits via reused_cache and downloaded_bytes. No contradiction with idempotentHint.

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?

Well-structured with bullet points and clear sections, but the length is somewhat verbose. However, every piece serves a purpose given the tool's complexity, and it front-loads the primary purpose.

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?

Covers purpose, parameters, caching, normalization, async behavior, return format, and integration across the pipeline. No missing critical information for an agent to use the tool correctly.

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 coverage is 0%, so the description is the sole source for parameter meaning. It explains sample (anton/livia with metadata), record_url, filename, output_dir, auto_normalize, and force with practical examples.

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 clearly states the tool downloads a public sample WGS VCF from Zenodo for PRS testing without personal data. It names specific samples and distinguishes itself from compute/analysis siblings.

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 specifies when to use (try PRS without own data), how to integrate with downstream tools (normalize_vcf, compute_prs), and references list_genomes as the complementary tool. Also explains when to use auto_normalize or custom record_url.

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

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dna-seq/just-prs-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server