Skip to main content
Glama

Editing quantification across a plate (one control, many wells)

editing_plate_quantify
Read-onlyIdempotent

Quantify a whole plate of edited samples against ONE untreated control trace and return a single sortable table — the plate-scale form of sanger_indel_spectrum, base_edit_quant and sanger_knockin_quant, chosen with mode. Each sample gives one row keyed by its id, carrying the headline number for that mode (edited fraction / editing at the target base / intended knock-in percentage), the fit-quality numbers behind it (R², or the background n and noise floor for base mode), and fitAdequate — the single-sample tool's own gate verdict on that row, so the plate cannot drift from the per-well answer. Failure is isolated per well: a sample whose read is short, mismatched or unfittable becomes a failed ROW with its error message and the other 95 still come back, while an error about the control trace, the mode or the work ceilings throws, because it is wrong for every row. Duplicate sample ids are suffixed (against the whole plate, so the suffix never lands on another well's name) rather than merged. Arguments are strict: an argument belonging to another mode, an unknown argument, an out-of-range limit, and an offset override (which is a property of one pair of reads, not of a plate) are all rejected rather than ignored or clamped, because at plate scale a substituted setting rewrites every row identically and nothing in the table looks odd. Returns the rows in input order, a tally, and a CSV. Comparing two wells' percentages is only meaningful when both rows are fitAdequate, which is why the plate summary is computed over those rows alone. PREDICTED, NOT MEASURED. None is published for this implementation, and being a batch does not soften that: each row is exactly the claim the corresponding single-sample tool makes. What every row instead reports is what it rests on — R² for the indel and knock-in modes, the background n, sd and noise floor for base mode — plus fitAdequate, which is the single-sample tool's OWN gate verdict on that row rather than a threshold re-invented here. Recovery of known synthetic mixtures is deliberately NOT offered as validation: it tests the arithmetic and the plate plumbing, not whether the model fits a real capillary trace, and for a knock-in with novel inserted bases it is circular, because a synthetic trace is built from the same idealised peaks the basis assumes. Quoting it would be the mistake rbs_predict made when it shipped a calibration residual as held-out skill. Valid for: One control read and a set of edited reads that are all the SAME amplicon, chemistry and primer as that control, with each read extending well past the edit site. COMPARING TWO WELLS' PERCENTAGES IS ONLY MEANINGFUL WHEN BOTH ROWS ARE fitAdequate: a percentage from a badly fitting well is not a smaller number than one from a well that fitted, it is a different kind of statement, and the plate summary here is therefore computed over the adequate rows only. Ranking wells also assumes they differ only in the variable under test — the same control is subtracted from all of them, so a well whose read started 30 bases later or whose reaction was dirty carries that difference into its number. Mode-specific limits carry over unchanged: indel mode is blind to substitutions, base mode is blind to indels and its percentages run low by roughly the crosstalk fraction, and knock-in mode cannot separate an intended pure deletion from an NHEJ deletion of the same length at the same site.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNobase mode: the base it converts to, as READ on the control strand.
fromNobase mode: the base the editor converts, as READ on the control strand.
modeYesWhich quantifier to run on every well. "indel" = sanger_indel_spectrum (NHEJ efficiency and the indel spectrum; needs cutPosition; blind to substitutions). "base" = base_edit_quant (CBE/ABE conversion; needs an editor id + protospacer, or an explicit window with from/to; blind to indels). "knockin" = sanger_knockin_quant (a specific intended edit against its byproducts; needs editKind + editPosition). Arguments belonging to another mode are rejected, not ignored.
guardNoindel mode: bases skipped immediately after the cut, where the trace is least reliable. A whole number >= 0; a negative value is rejected, not clamped to 0.
editorNobase mode: base editor id (be3, be4max, abe7.10, abe8e) — fixes the converted bases and the activity window in protospacer coordinates. Requires "protospacer". Mutually exclusive with windowStart/windowEnd/from/to.
samplesYesThe plate's edited wells, in the order you want them tabulated. Up to 384 samples (96 is the natural plate) and 400,000 trace positions across the whole call, control included — that is already an 8-10 MB request body, so split a plate of untrimmed reads rather than sending one call.
editKindNoknockin mode (required): shape of the intended edit. "substitution" replaces bases one for one; "insertion" adds novel bases and replaces none; "deletion" removes bases and adds none; "replacement" is the general case where the lengths differ.
maxIndelNoindel and knockin modes: largest indel to fit, in bp — a whole number, 1-20. Out of range is rejected, not clamped.
altAlleleNoknockin mode: the bases installed in their place.
refAlleleNoknockin mode: the control bases the edit replaces (substitution and replacement). Checked against the control read once, before any well is fitted.
windowEndNobase mode: explicit window end, 1-based inclusive. Window length is capped at 40.
zThresholdNobase mode: significance threshold in standard deviations of each well's own background (1-10; out of range is rejected, not clamped). Raising it raises the reported noise floor with it.
cutPositionNoindel mode (required): 1-based position of the expected cut, in CONTROL read coordinates. knockin mode (optional): 1-based CONTROL position where UNINTENDED indels start — the nuclease cut or the PE nick; defaults to the edit start.
insertedSeqNoknockin mode: the novel bases inserted (insertion only).
protospacerNobase mode: the 20-nt spacer, located in the CONTROL read (either strand; must match exactly once).
windowStartNobase mode: explicit window start, 1-based in CONTROL coordinates. Requires windowEnd, from and to.
controlBasesYesBase calls of the ONE untreated control read (raw or FASTA).
editPositionNoknockin mode (required): 1-based CONTROL position of the first base the edit replaces. An insertion replaces nothing, so there it is the base the insert lands immediately BEFORE — one MORE than the VCF/HGVS anchor.
windowLengthNoindel and knockin modes: bases downstream used for the decomposition — a whole number, 20-300. Out of range is rejected, not clamped.
deletedLengthNoknockin mode: how many bases are deleted (deletion only).
targetPositionNobase mode: 1-based CONTROL position of the intended edit. Give it for a plate. Without it each well's headline is its OWN most-edited significant position, so two rows can be reporting two different bases and the column is not one measurement.
controlChannelsYesPer-base [A, C, G, T] intensities of the control read, one row per called base, read at that base's peak location (trace arrays are indexed by scan, not by base). Raw peak heights: every intensity must be >= 0, because negatives are clamped to zero during normalisation and a baseline-subtracted trace would silently lose its minor peaks and read as unedited.
targetProtospacerPositionNobase mode: 1-based protospacer position of the intended edit (PAM-distal = 1). Editor mode only.

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses a great deal: per-well failure isolation, duplicate-id suffixing, strict rejection of cross-mode/unknown/out-of-range arguments and offset overrides, row ordering, return of tally and CSV, PREDICTED NOT MEASURED status, and mode-specific blind spots. This is far more transparency than the annotations alone provide.

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 description is long but front-loaded with the tool's core purpose and the key alternative/mode relationship. It earns most of its length by covering failure modes, validation warnings, and caveats. Minor redundancy exists—the fitAdequate warning appears twice—but given 23 parameters and the complexity of the plate behavior, the length is justified.

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 no output schema, the description adequately explains what is returned: one row per sample, headline metric, fit-quality numbers, fitAdequate, input order, tally, and CSV. It also covers failure isolation, duplicate handling, strict argument validation, valid experimental conditions, and mode-specific limitations. Nothing critical is missing for an agent to invoke this correctly.

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 coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining cross-cutting parameter behavior: arguments belonging to another mode are rejected, `targetPosition` should be given for a plate or each row reports a different base, duplicate sample ids are suffixed, and the offset override is invalid at plate scale. It does not enumerate every parameter, but it clarifies the semantics that matter most.

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 opens with a specific verb and resource: 'Quantify a whole plate of edited samples against ONE untreated control trace and return a single sortable table.' It also explicitly ties the tool to three named sibling tools (sanger_indel_spectrum, base_edit_quant, sanger_knockin_quant) and explains they are selected via `mode`, making it impossible to confuse this with the single-sample tools.

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?

The description gives clear context: it is the plate-scale form of three single-sample tools, the mode selects which quantifier runs, and a 'Valid for' block states the required experimental setup. It does not explicitly say 'use the single-sample tools when you have one sample,' but the distinction is strongly implied and the eligibility constraints are concrete.

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.

TDQS

A3.6/5.0
Disambiguation4/5

Most tools have highly specific purposes (e.g., crispr_grna_design vs base_editing_design vs prime_editing_design). However, there is some overlap in sequence analysis tools (characterize_sequence, sequence_report) and plasmid annotation tools (plasmid_annotate vs plasmid_deep_annotate) which could cause confusion.

Naming Consistency3/5

The naming pattern is largely consistent with snake_case verb_noun or noun_descriptor (e.g., primer_design, plasmid_annotate, fastq_trim). However, there are exceptions like 'batch', 'workflow', 'gc_content', and 'cloning_diagnose' which don't follow the verb_noun pattern consistently. Also, some names are phrases like 'golden_gate_from_parts'.

Tool Count2/5

With 101 tools, this server is extremely large and likely overwhelming for agents. Even for a comprehensive bioinformatics toolkit, this exceeds a manageable scope, risking agent confusion and inefficient tool selection. A more modular approach would be advisable.

Completeness4/5

The tool surface covers a wide range of bioinformatics workflows including sequence analysis, primer design, cloning, CRISPR, NGS, expression analysis, and data export. There are minor gaps such as lack of a dedicated protein structure prediction tool and limited off-target genome coverage, but overall the set is impressively complete for its domain.

Resources