Skip to main content
Glama

jean — Molecular Biology & Genomics

gate_droplets

Read-only

Two-channel ddPCR droplet-amplitude exports to a template concentration, by CLASSIFYING the raw droplets rather than trusting a count the instrument already made. Four steps in a fixed order, each of which needs the previous one's output: a k-means quality check marks wells whose two droplet clusters are not separable, a plate-wide 1%-slice IQR cutoff marks outlier droplets, a two-component Gaussian mixture per well per channel sets the empty-droplet cutoff on the droplets that survive, and the empty fraction inverts through the Poisson zero term to copies/uL. Reports the cluster the droplets landed in and the reason any well was rejected, so a failed well reads as rejected rather than as a concentration. This is the counterpart of quantify_dpcr, not a duplicate: that one starts from per-well positive COUNTS an instrument already classified, this one starts from the amplitudes and does the classifying.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filesYesthe droplet exports, as `<filename>` and its CSV body. QuantaSoft writes one `<name>_<well>_Amplitude.csv` per well with columns `Assay1 Amplitude, Assay2 Amplitude, Cluster`; the well id is read from the FILE NAME because the body does not carry it. Separate files with a line containing only `---`, and start each with `# <filename>`.
x_varNoname for the X channel, which is the file's SECOND amplitude column. Bio-Rad's Ch2 is usually HEX or VIC.HEX
y_varNoname for the Y channel, which is the file's FIRST amplitude column. Bio-Rad's Ch1 is usually FAM.FAM
_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.
_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.
cutoff_sdNohow many standard deviations above the LOWER mixture component's mean the empty cutoff sits. This is the knob that decides which droplets are empty, and therefore the concentration.
cutoff_iqrNohow many interquartile ranges above the third quartile of that slice a droplet must sit to be an outlier.
random_seedNore-seeded before EVERY k-means and EVERY mixture fit, not once per run. Neither has a deterministic start, so this value IS part of the answer: a different seed lands the mixture on a different local optimum and moves the empty cutoff. Upstream's default is 8.
top_percentNothe top slice of droplets, pooled across the SUCCESSFUL wells, that the outlier cutoff is computed on. One cutoff per axis for the whole plate, not one per well.
total_drops_tNofewer accepted droplets than this and the well is rejected before it is clustered at all.
empty_lambda_lowNosmallest empty-droplet fraction a well may have. Below it the smaller k-means cluster is too small to be the empty population, which means the run did not separate.
droplet_volume_ulNomean volume of ONE droplet, in µL. A per-platform constant: 0.85e-3 µL (0.85 nL) for the Bio-Rad QX200, which is what the QuantaSoft export comes from.
empty_lambda_highNolargest empty-droplet fraction a well may have. Above it almost every droplet is empty, so there is no positive population to quantify and a concentration would be an extrapolation.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countYeshow many wells were read
wellsYesone row per well: droplet counts by cluster, the empty fraction, the per-well cutoffs, and the concentration in copies/uL — null for a rejected well, never a number
paramsYesevery parameter the run used, including the ones left at their defaults: the seed and the two cutoff multipliers change the concentration, so a reading without them is not comparable
rejectedYeshow many wells were rejected by the quality check and so carry no concentration
verdictsYeswhy each well passed or was rejected, with the k-means the verdict was taken from: both cluster centres, their sizes, their distances to the origin and the gap between them
outlierCutoffYesthe two plate-wide outlier cutoffs, echoed because they were computed from the successful wells only and so depend on which wells passed
totalDropletsYesevery droplet read, across every well — the denominator the cluster counts account for

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare this read-only and non-destructive, so the bar is lower, but the description adds rich behavioral context: a fixed four-step order with dependencies, rejection reasons, output shape for failed wells, and the critical non-determinism warning that random_seed is re-seeded before every k-means and mixture fit and is part of the answer. This is well beyond what annotations provide.

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 front-loaded with the core operation, then methodically lists the four ordered steps, and closes with the key sibling distinction. Despite its length, the complexity of the tool justifies it, and no sentence reads as filler or repetition.

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?

With an output schema present, annotations covering safety, and 100% input-schema description coverage, the description only needs to add process and routing context. It does so thoroughly by covering algorithm order, rejection behavior, non-determinism, and the alternative tool, leaving no major gap for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/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 detail. The description adds value by explaining how the parameters interact as a pipeline (k-means separation, plate-wide IQR outlier removal, per-well mixture cutoff, Poisson inversion), giving the numeric knobs a coherent algorithmic role.

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 states a specific process (two-channel ddPCR droplet-amplitude exports to template concentration via classifying raw droplets) and explicitly distinguishes it from quantify_dpcr. An agent can tell what this tool does and how it differs from the closest named alternative without opening the schema.

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

Usage Guidelines4/5

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

It gives an explicit selection rule against quantify_dpcr: that tool starts from per-well positive counts an instrument already classified, this one starts from amplitudes and does the classifying. However, it does not address the similarly named sibling classify_droplets, leaving a potential routing gap for an agent deciding between the two.

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