jean — Molecular Biology & Genomics

crispr_analyze_screen

Read-only

Call HITS from a pooled CRISPR screen: per-guide read counts in, a gene-level Bayes factor and a precision/recall curve out. This is the other end of a screen from the pool designer — it reads what came back rather than deciding what to order. The estimator is BAGEL2 (Kim & Hart 2021), reproduced byte-for-byte against upstream, so a gene's Bayes factor here is the number BAGEL2 prints for the same counts. It is a COMPARISON against two reference gene sets, not an absolute fitness measure, and it reports how many of those reference genes the library actually carries, because a screen whose gene symbols do not match the reference sets trains on almost nothing and still returns a ranking. MAGeCK's alpha-RRA and drugZ are different statistics that disagree with this one on the same counts; neither is computed here, and a hit list must say which statistic produced it.

Input Schema

TableJSON Schema

Name	Required	Description
`_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.
`fdr_cut`	No	the false-discovery rate the hit list is cut at. A DISPLAY threshold read off the computed curve, not a parameter of the estimator.
`_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.
`min_reads`	No	drop a reagent whose SUMMED control count is below this (upstream's -m). Applied after the pseudocount, exactly as upstream applies it.
`read_counts`	Yes	the count table: a header line, then one row per reagent — identifier, gene, then one column per sequenced sample. Tab- or comma-separated. Counts may be written as decimals, as upstream's own files are.
`pseudo_count`	No	added to every count before normalising to 10,000,000 reads per column. Advanced.
`sample_columns`	No	which sample column names to score. Leave empty to score every column that is not a control.
`control_columns`	Yes	the T0 / plasmid column NAMES, exactly as the header spells them. Summed before the fold change, so a two-replicate T0 is one control and not two.
`essential_genes`	Yes	reference ESSENTIAL gene symbols, one per line (extra columns ignored). BAGEL2's CEGv2 is the usual choice; the editor panel ships it and the mouse set beside it.
`equalise_replicates`	No	scale every Bayes factor as if the screen had this many replicates (upstream's -p), 0 to leave it off. A BF is a SUM over replicates, so two screens of different replicate counts are not comparable until this is set. Advanced.
`non_essential_genes`	Yes	reference NON-ESSENTIAL gene symbols, one per line. BAGEL2's NEGv1 is the usual choice.

Output Schema

TableJSON Schema

Name	Required	Description
`fit`	Yes	the fitted line the Bayes factor is scored against: slope, intercept and the fold-change window
`hits`	Yes	genes at or above the Bayes factor the FDR cut lands on
`curve`	Yes	the precision/recall curve, one row per gene
`genes`	Yes	every gene with its Bayes factor, standard deviation and observation count, ranked
`hitBf`	Yes	the Bayes factor the cut lands on (0 when nothing clears the FDR)
`training`	Yes	reference essential and non-essential genes FOUND in this library, against the number supplied — the check that the symbols match

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 20, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), yet the description adds substantial behavioral context beyond them: the estimator is BAGEL2 reproduced byte-for-byte against upstream, the output is a comparison against two reference gene sets rather than an absolute fitness measure, and it discloses a real failure mode (symbol mismatch between library and reference sets yields a ranking trained on almost nothing).

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?

The purpose and input/output contract are front-loaded in the first sentence, and the remaining sentences are informative rather than filler. It is dense and somewhat long, with a few ornate phrasings ('reproduced byte-for-byte'), but nothing is pure padding.

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, the description need not describe return values, and it still covers the statistical semantics, the comparison nature of the result, and the principal failure mode. For an 11-parameter, nested-schema tool this is complete enough to call correctly.

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 documents all 11 parameters (including why fdr_cut is a display threshold, that min_reads is applied after the pseudocount, and that equalise_replicates makes Bayes factors comparable). The description adds only high-level framing (reference gene sets, read-count table) rather than new parameter semantics, so the baseline 3 applies.

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?

States a specific verb and resource (calling hits from a pooled CRISPR screen), names the concrete inputs (per-guide read counts) and outputs (gene-level Bayes factor, precision/recall curve), and explicitly contrasts itself with the pool designer sibling. An agent can tell it apart from the design-side tools 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?

Explicitly frames when to use it: 'the other end of a screen from the pool designer — it reads what came back rather than deciding what to order,' and warns that MAGeCK alpha-RRA and drugZ are different statistics not computed here. However, it does not differentiate from the other analysis-side CRISPR siblings (crispr_quantify_edits, crispr_score_deephf, crispr_score_deepspcas9), which is the remaining routing gap.

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?