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.

Input 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

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

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description contributes one genuinely non-obvious behavioral fact: the result is recomputed by classifying droplets, so it can disagree with the instrument's reported count. It says nothing else about behavior — that wells may be rejected, that cutoffs are pooled per plate, or that the run is stochastic — even though those are the traits an agent would most need to anticipate.

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?

A single front-loaded sentence with no filler, and the key contrast (classify vs. trust the instrument) is placed early. It is slightly compressed to the point of awkwardness — the main clause lacks an explicit verb for the input-to-output mapping, and the capitalized 'CLASSIFYING' does rhetorical rather than informational work.

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?

This is a 13-parameter, nested-schema tool with a full output schema, and the structured fields carry the pipeline detail (input packing, channel ordering, gate knobs). With annotations covering the safety profile and the schema covering inputs and outputs, the description's remaining job is to state the purpose and the recompute-vs-instrument distinction, which it does.

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% and the parameter docs are exceptionally rich (seed semantics, per-platform droplet volume, empty-fraction bounds), so baseline 3 applies. The description adds no parameter meaning beyond the schema and never mentions the file-packing format or the channel-naming arguments that dominate a correct call.

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?

States a specific transformation: two-channel ddPCR droplet-amplitude exports in, template concentration out, via classification of raw droplets. The verb is elliptical ('gates/classifies exports to a concentration') but the resource and output are clear. It does not distinguish itself from close siblings like classify_droplets or quantify_dpcr, so an agent cannot tell from the description alone which of the three to pick.

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 phrase 'rather than trusting a count the instrument already made' implies you use this when you want a recomputed concentration from raw amplitudes instead of the QuantaSoft call, which is useful implicit context. But no sibling is named, no exclusion is given, and there is no statement of prerequisites (per-plate file set, well naming convention) to guide the choice.

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