Skip to main content
Glama

genotype_pca

Read-only

Principal components of a call set's genotypes, the population-structure picture: biallelic sites above a minor-allele count, LD-pruned by sliding windows, scaled per site (Patterson, standard or centring) and decomposed; every sample's coordinates with its population, and the variance each component explains (scikit-allel pca). Validated on 1000 Genomes phase 3 APOL1, all 2,504 samples.

Input Schema

NameRequiredDescriptionDefault
vcfYesthe call set as VCF text (a .vcf, or a .vcf.gz already decompressed); every record's GT is read, ploidy 2.
pruneNodrop sites in LD before the decomposition (locate_unlinked), as scikit-allel's PCA assumes.
_filesNoThe project: record references shaped like _subject. Their records become library documents a tool names in sequences/parts/document; a trace or alignment is found by file name.
minMacNokeep biallelic sites whose REF and first ALT are each seen at least this many times.
scalerNoper-site scaling before the decomposition: Patterson divides the centred dosage by √(p(1−p)); standard by its standard deviation; center only centres. Values: patterson (Patterson (√(p(1−p)))), standard (Standard deviation), center (Centre only).patterson
groupByNowhich column of the sample table groups the samples; empty is its first grouping column.
_subjectNoThe record to act on: exactly one of sequence, accession (+source), sample (an id from list_samples) or file ({name, text} or {name, base64}); record_index picks one record of several.
precisionNofloat64, or float16: scikit-allel's own path when handed integer genotypes, which rounds the scaled matrix to half precision. Values: float64 (Double precision), float16 (Half precision (as scikit-allel on integer genotypes)).float64
pruneSizeNopruning window, in sites. Only applies when prune is true.
pruneStepNosites the pruning window advances. Only applies when prune is true.
nComponentsNocomponents to report.
populationsNoa sample table: a header row with a `sample` column and one or more grouping columns (tab-separated, as 1000 Genomes' .panel). Samples it does not list belong to no group.
pruneThresholdNoprune the later site of a pair whose Rogers–Huff r² exceeds this. Only applies when prune is true.

Output Schema

NameRequiredDescriptionDefault
sitesYeshow many sites qualified, how many pruning kept, and their positions
coordsYesone row per sample: sample, its group, and its coordinate on each component
explainedVarianceYesthe variance each reported component explains, in the data's own units (the eigenvalues)
explainedVarianceRatioYesthe share of variance each reported component explains

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedOutput schema / properties / explainedVariance
      Added value: +{
      +  "description": "the variance each reported component explains, in the data's own units (the eigenvalues)"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "coords",
      -  "explainedVarianceRatio",
      -  "sites"
      -]New value: +[
      +  "coords",
      +  "explainedVarianceRatio",
      +  "explainedVariance",
      +  "sites"
      +]
  2. First observed

TDQS

A3.5/5.0
Behavior4/5

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

Annotations only cover the safety profile (readOnly, non-destructive, closed-world), leaving the description to add substance – and it does: it discloses the full processing chain, the default LD-pruning behaviour and its assumptions, the scaling variants, and even validation against 1000 Genomes phase 3 (2,504 samples). It also previews the returned content (per-sample coordinates with population and variance explained), which the annotations do not.

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?

Two sentences, method first and validation second, with the core operation front-loaded. The long first sentence is dense but earns its place by summarizing the whole pipeline; there is mild redundancy with the schema's parameter text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 13-parameter compute tool with an output schema and full annotation coverage, the description is nearly complete – it conveys method, defaults, assumptions and output shape. The only real gap is sibling routing, which is the missing piece an agent needs to pick this over related population-genetics tools.

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 all 13 parameters in depth (defaults, enums, min/max, scikit-allel rationale). The description restates the same concepts (minor-allele count, LD pruning, scaling) at a high level without adding format, syntax or interaction detail beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource – principal components of a call set's genotypes, decomposed via scikit-allel PCA – and gives the pipeline (biallelic filtering, LD pruning, per-site scaling). It is unmistakably a dimensionality-reduction / population-structure tool. It does not, however, name or contrast itself with close siblings such as population_ancestry, population_fst or population_site_stats.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use or when-not-to-use guidance, and no alternative tool is named despite several overlapping population-genetics siblings. The methodological detail implies the context (PCA for population structure) but the agent must infer when this beats population_ancestry or population_fst.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources