Jean by Melad Labs

analyze_flow_cytometry

Read-only

A flow cytometry list-mode file (FCS 2.0, 3.0 or 3.1) from the project, end to end: read and linearize every event ($PnE anti-log, $PnG gain, $TIMESTEP), compensate it with the spillover matrix the file declares, apply a Gating-ML 2.0 gating strategy from the project, and report every population with its event count, percent of parent and percent of all events, the mean, median, SD and CV of every channel in every population, a binned two-channel density for a plot, and a density-valley threshold on any channel (flowDensity deGate).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "analyze_flow_cytometry"
  }
}

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.
`bins`	No	bins per axis of the density.
`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.
`stats_on`	No	statistics on linear compensated values (MFI) or on the display scale. Values: linear (linear values (MFI)), scaled (display scale).	linear
`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.
`plot_population`	No	the population plotted; empty for all events.
`threshold_channel`	No	channel to find a density-valley threshold on (flowDensity deGate on the display scale); empty for none.
`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
`threshold_population`	No	the population thresholded; empty for all events.

Output Schema

Name	Required	Description
`file`	Yes	version, event count, every channel with its role, range, gain and decades
`stats`	Yes	per population and channel: count, mean, median, SD (n − 1), CV, min, max
`events`	Yes	events in the file
`density`	Yes	the two-channel density, events per bin, rows from the top of the plot
`threshold`	Yes	every density-valley cut on the display scale and as scale values, and how many events lie at or above
`populations`	Yes	every population: id, parent, event count, percent of parent and of all events
`compensation`	Yes	the spillover matrix used, its detectors and the algorithm, or null when the file has none

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 7, 2026

addedInput schema / properties / derived

Added value: +{
+  "default": "",
+  "description": "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.",
+  "type": "string"
+}

AddedNov 6, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations only declare it a safe, read-only, closed-world operation; the description adds real behavioral detail beyond that: the exact processing order (linearize via $PnE/$PnG/$TIMESTEP, then compensate, then gate), the source of the compensation matrix, and precisely what is reported (event counts, percent of parent and of all, mean/median/SD/CV per channel, binned density, deGate threshold). It stops short of stating limits such as how large a file can be handled or how populations are named.

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?

No filler and no repetition of the title or schema; every clause contributes a distinct pipeline stage or output. However, it is delivered as one very long run-on sentence with a heavily parenthesized tail, which makes it harder to scan than a short ordered list would be.

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 22 parameters, nested _subject/_files objects, four enums, and an output schema, the description correctly concentrates on the pipeline and the reported statistics while leaving parameter detail to the schema. The main gap is that it does not clarify how the tool relates to the sibling flow-cytometry tools or what happens when a file lacks a spillover matrix (only the compensation parameter's schema notes the refusal behaviour).

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%, including per-parameter explanations of scale, cofactor, compensation_method, stats_on, and the plot/threshold channels, so the schema does the heavy lifting. The description's prose adds no meaning beyond it — it does not mention any parameter by name or explain how gating, plot_population, and threshold_population interact when several are set.

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 chain and resource: read an FCS 2.0/3.0/3.1 list-mode file, linearize events, compensate with the spillover matrix, apply Gating-ML 2.0 gating, and report per-population statistics, density, and a deGate threshold. An agent can tell this is the full end-to-end flow cytometry pipeline. It never names the near siblings (auto_gate_flow_cytometry, check_flow_cytometry_quality, compare_flow_cytometry_populations) so the boundary is not drawn for the agent.

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 'from the project, end to end' implies this is the complete pipeline rather than a partial one, and the optional parameters (empty gating, empty plot_x, empty threshold_channel) hint at reduced modes. But there is no explicit statement of when to choose this over auto_gate_flow_cytometry or cluster_flow_cytometry_flowsom, and no prerequisites or exclusions are given.

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

All Jean by Melad Labs 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?