Jean — Molecular Biology & Genomics

check_flow_cytometry_quality

Read-only

Acquisition quality over time for an FCS file, by flowAI (flow rate, signal acquisition and dynamic range checks), PeacoQC (peak trajectories, isolation tree and MAD) or flowCut (deviant and low-density segments).

Input Schema

Name	Required	Description	Default
`A`	No	additional negative decades. Only applies when scale is logicle or hyperlog or flowcore-logicle or fasinh.
`M`	No	decades of the full scale. Only applies when scale is logicle or hyperlog or flowcore-logicle or fasinh.
`T`	No	top of scale; empty means the file's largest fluorescence $PnR.
`W`	No	linear width in decades. Only applies when scale is logicle or hyperlog or flowcore-logicle.
`tool`	No	the method. Values: flowai (flowAI), peacoqc (PeacoQC), flowcut (flowCut).	flowai
`scale`	No	the display scale of the fluorescence channels (scatter and time stay linear): used for the plot, the threshold and, with `stats_on: scaled`, the statistics. Values: logicle (Logicle (Gating-ML 2.0, Moore & Parks)), fasinh (ArcSinh (Gating-ML 2.0 fasinh)), arcsinh (ArcSinh with a cofactor (asinh(x / c), Cytobank and CyTOF)), hyperlog (Hyperlog (Gating-ML 2.0, Bagwell)), flowcore-logicle (Logicle on a 0–M axis (flowCore)), wsp-biex (Biex (FlowJo 10, channels 0–4096)), flin (Linear (Gating-ML flin)).	logicle
`_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.
`gating`	No	a Gating-ML 2.0 document in the project, by name or id; empty for no gating (every statistic is then of all events).
`plot_x`	No	channel (PnN or PnS) on the density plot's x axis; empty for no plot.
`plot_y`	No	channel on the plot's y axis.
`derived`	No	derived parameters, `name = expression` separated by `;` (FlowJo's vocabulary: channels by name or [name], + − * / % ^, abs ceil floor neg round max min pow exp ln log sqrt and the trig functions); each becomes a channel of the run.
`_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.
`cofactor`	No	the c in asinh(x / c): 5 is the CyTOF convention, 150 a common one for fluorescence. Only applies when scale is arcsinh.
`document`	No	the FCS file, by name or id; may be left empty when the project holds exactly one.
`peaco_mad`	No	PeacoQC MAD. Only applies when tool is peacoqc.
`biex_width`	No	FlowJo biex width basis (negative; FlowJo's default -10). Only applies when scale is wsp-biex.
`compensation`	No	`auto`: the file's own $SPILLOVER/$SPILL when it has one, else none; `file`: that, refusing a file without one; `none`: leave the values as acquired. Values: auto (automatic), file (file's own matrix), none (none).	auto
`biex_negative`	No	FlowJo biex extra negative decades. Only applies when scale is wsp-biex.
`peaco_it_limit`	No	PeacoQC isolation tree limit. Only applies when tool is peacoqc.
`flowcut_segment`	No	flowCut segment (events). Only applies when tool is flowcut.
`plot_population`	No	the population plotted; empty for all events.
`peaco_consecutive`	No	PeacoQC consecutive bins. Only applies when tool is peacoqc.
`flowai_remove_from`	No	flowAI: which checks remove events. Only applies when tool is flowai.	all
`compensation_method`	No	which published algorithm: FlowKit's solve(Sᵀ, Xᵀ) or flowCore's X · S⁻¹. They agree to ~1e-15 of full scale. Values: flowkit (solve(Sᵀ, Xᵀ) (FlowKit)), flowcore (X · S⁻¹ (flowCore)). Only applies when compensation is auto or file.	flowkit
`flowcut_max_perc_cut`	No	flowCut MaxPercCut. Only applies when tool is flowcut.
`flowcut_max_valley_hgt`	No	flowCut MaxValleyHgt. Only applies when tool is flowcut.

Output Schema

Name	Required	Description
`kept`	Yes	events kept
`table`	Yes	the method's own result table
`causes`	Yes	per cause: events flagged, whether it removes, and flagged events per time bin
`channels`	Yes	the per-channel table (changepoints, MAD contribution, margins)

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

B3.2/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 the safety profile is covered. The description adds useful method-level behavior (flow rate, signal acquisition, dynamic range checks; peak trajectories and isolation tree; deviant and low-density segments) but says nothing about gating/compensation side effects or what the result contains beyond what the output schema supplies.

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 parentheticals efficiently pack the algorithm-specific detail. It is dense but readable; slightly more structure would help an agent scanning 26 parameters.

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

Completeness3/5

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

With 26 parameters, a nested _subject object, full schema coverage, annotations and an output schema, the structured fields carry most of the load. The description covers the purpose and method taxonomy but omits the acquisition-quality workflow context (what a failure means, what to do next), leaving it minimally adequate for a tool of this complexity.

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% across all 26 parameters, so the schema already documents the method-specific knobs and scale options in detail. The description only contributes the high-level mapping of the three method names, which the `tool` enum description already provides; baseline 3 applies.

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 verb-resource pair (acquisition quality over time for an FCS file) and enumerates the three algorithms with what each checks. That distinguishes it reasonably well from siblings like analyze_flow_cytometry or cluster_flow_cytometry_flowsom, though it never names those alternatives explicitly.

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 guidance on when to run a quality check versus the other flow cytometry tools, and no advice on choosing between flowAI, PeacoQC and flowCut beyond restating what each examines. The agent must infer the decision rule entirely.

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?