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

Normalize VCF

normalize_vcf
Idempotent

Normalize raw VCF files into reusable, quality-filtered genotype Parquet for efficient polygenic risk score analysis. Apply optional filters (depth, quality, FILTER) and reuse cached output across multiple scoring runs.

Instructions

Normalize a VCF to a quality-filtered genotype Parquet.

This tool is optional preprocessing, not a prerequisite for scoring: compute_prs, compute_prs_batch, and compute_prs_by_trait accept raw VCF paths directly. Use normalization when you intentionally want a reusable Parquet for many later analyses or custom quality filters. Before normalizing, list_genomes can show whether a cached Parquet already exists.

Strips the chr prefix, renames id→rsid, computes genotype from GT, applies optional quality filters (FILTER allow-list, min DP, min QUAL), and writes zstd-compressed Parquet. The output is a drop-in genotype source for compute_prs / compute_prs_batch (genotypes_path) and for compute_prs_by_trait (a samples entry ending in .parquet), so each VCF is normalized once and reused. Normalize every genome you plan to compare; scoring still happens per genome.

Idempotent: if the target Parquet already exists it is reused and the (slow) normalization is skipped — reused_cache=True flags the hit. Custom filters (pass_filters / min_depth / min_qual / sex) always re-run, since the cached Parquet may not reflect them. Pass force=True to re-normalize unconditionally.

Normalization is the slow step (seconds to minutes depending on VCF size). Returns a PRSJob immediately; poll prs_job_status when status is running. When done, result is a NormalizeResult.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sexNo
forceNo
min_qualNo
vcf_pathYes
min_depthNo
output_pathNo
genome_buildNo
pass_filtersNo

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

A5/5.0
Behavior5/5

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

Beyond the idempotentHint annotation, the description explains the idempotency rule in detail (reuse existing Parquet, skip normalization) and the caveat about custom filters. It discloses the actual transformations (chr prefix stripping, id→rsid, genotype computation) and the async behavior (returns PRSJob, poll status), adding significant context not available from annotations alone.

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?

The description is well-structured with clear paragraphs, each serving a purpose: overview, usage guidance, behavioral details, and async/result note. No redundancy exists—every sentence adds value (e.g., 'Normalize every genome you plan to compare') while remaining concise for the complexity covered.

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?

Given the tool's complexity (8 params, async execution, idempotency, filters), the description is complete. It covers all operational aspects, includes the output schema reference (NormalizeResult), and explains the async pattern, making it self-sufficient for an agent to use 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?

Despite schema description coverage of 0%, the description explicitly names and elaborates on all key parameters: vcf_path, output_path, pass_filters, min_depth, min_qual, sex, force. It explains that custom filters always re-run and that force=True triggers unconditional normalization, giving meaning beyond the schema's type definitions.

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 normalizes a VCF to a quality-filtered genotype Parquet, which is specific and action-oriented. It explicitly distinguishes this from scoring tools like compute_prs, establishing its role as optional preprocessing, not a prerequisite.

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?

The description gives explicit guidance on when to use this tool: 'Use normalization when you intentionally want a reusable Parquet for many later analyses or custom quality filters.' It also directs users to check list_genomes for existing caches, and clarifies that raw VCF paths are accepted directly by scoring tools, providing clear when-not.

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