Jean — Molecular Biology & Genomics

population_fst

Read-only

Differentiation between populations of a call set: Weir and Cockerham's θ over two or more populations, or Hudson's or Patterson's Fst between pairs, per site and averaged with a block-jackknife standard error (scikit-allel).

Input Schema

Name	Required	Description	Default
`vcf`	Yes	the call set as VCF text (a .vcf, or a .vcf.gz already decompressed); every record's GT is read, ploidy 2.
`_files`	No	The 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.
`compare`	No	the populations to compare, comma-separated; empty is every group of the column.
`groupBy`	No	which column of the sample table groups the samples; empty is its first grouping column.
`_subject`	No	The 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.
`estimator`	No	weirCockerham: θ from the variance components over every compared population at once. hudson: 1 − within / between pairwise differences (Bhatia 2013). patterson: F2-based, biallelic sites only. Values: weirCockerham (Weir–Cockerham θ), hudson (Hudson Fst), patterson (Patterson Fst).	hudson
`blockLength`	No	sites per jackknife block for the average's standard error; a trailing partial block is dropped, as scikit-allel does.
`populations`	Yes	a 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.

Output Schema

Name	Required	Description
`sites`	Yes	per site: pos, and per comparison the site's Fst (numerator / denominator), null where undefined
`matrix`	Yes	pairwise average Fst between every compared population (Hudson and Patterson)
`average`	Yes	per comparison: the populations, Fst over all sites, its jackknife standard error, blocks

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 20, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already cover read-only, non-destructive, and closed-world safety traits, so the description adds useful methodological behavior: the estimator family, per-site calculation, block-jackknife averaging, and scikit-allel implementation. It does not disclose operational caveats such as missing-data handling or estimator limitations, but it provides substantive behavioral context beyond the annotations.

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 a single front-loaded sentence with no filler. Every clause contributes either the computation, estimator variants, or output/uncertainty behavior.

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?

With annotations, an output schema, and full parameter description coverage, the description only needs to frame the computation and it does so well. It omits explicit estimator-selection guidance and input constraints, but those gaps are limited relative to the structured metadata already supplied.

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 explains vcf, populations, compare, groupBy, estimator, and blockLength in detail. The description reinforces that estimators operate over populations or pairs, but adds little parameter-level syntax or constraints 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 names a specific computation, population differentiation via Fst/θ, and distinguishes Weir–Cockerham from Hudson/Patterson and notes per-site plus jackknife-averaged output. It does not explicitly distinguish itself from nearby sibling tools such as population_ancestry or population_site_stats, so it is clear but not fully sibling-routing.

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

Usage Guidelines3/5

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

The description implies usage by saying Weir–Cockerham applies over two or more populations while Hudson/Patterson are between pairs, but it gives no explicit when-to-use versus when-not guidance or named alternatives. An agent must infer from the tool name and statistical terminology that this is the correct Fst calculation.

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

All Jean — Molecular Biology & Genomics tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?