Skip to main content
Glama

Base editing quantification from Sanger traces (EditR equivalent)

base_edit_quant
Read-onlyIdempotent

Quantify CBE/ABE base editing from a pair of Sanger traces — an unedited control and the edited pool — without NGS. At each editable position in the activity window the edited trace is treated as a mixture of the unedited and converted peaks, and the control's OWN alt-channel signal at that same position is subtracted as background, because dye crosstalk is position- and context-dependent and a global constant would be wrong per position. Significance comes from a null built from the same sample (every control position outside the window carrying the same base), so the threshold adapts to the run's chemistry instead of being hardcoded. Returns per-position percentages with z-scores, the target and its bystanders, the background distribution (including a robust estimate of its spread and a count of its outliers), and the noise floor — the percentage the background alone reaches, or null when the run's own null has no spread to derive one from. A window position whose control already carries the converted base is reported but not quantified, because the (1 − b) rescale amplifies error by 1/(1 − b) and turns a 0.1-point wobble into half the pool. Locate the window with an editor id plus the protospacer, or give it explicitly. Blind to indels, which shift the trace rather than mixing a base. PREDICTED, NOT MEASURED. None is published for this implementation. Every run instead reports what it rests on: the background mean, sd, robust (MAD-based) sd, outlier count and n, and a noiseFloorPercent that says how much apparent editing the background alone reaches at the significance threshold — null, rather than 0, when the run has no null with any spread to derive a limit from. This implementation's recovery of known synthetic mixtures (to under a percentage point) is deliberately NOT offered as validation — it tests the arithmetic and the coordinate handling, not whether the linear mixture model fits a real capillary trace. Two properties ARE characterised. The bias is directional and one-sided: the (1 − b) rescale assumes a fully converted position would read as alt fraction 1.0, which real chemistry does not reach, so percentages run low by roughly the crosstalk fraction (order 5-10% relative at typical 3% bleed). The variance is not constant across positions: dividing by (1 − b) amplifies the error in a and b by 1/(1 − b), so the variance of the estimate goes as 1/(1 − b)². Positions whose control alt fraction b exceeds 0.25 are therefore reported but NOT quantified, which bounds that amplification at 1.33x on everything the tool does quantify. Valid for: A pool edited by a cytosine or adenine base editor, read on the same amplicon and chemistry as an unedited control that starts within ±40 bases of it, where the editing is a SUBSTITUTION. Not valid for indels — a base editor also makes them, and an indel-bearing allele shifts the downstream trace so that it degrades the fit at every window position rather than showing up anywhere. Not valid where the control read already carries the alt base at a window position (a pre-existing variant, or the wrong control), since then there is nothing left to correct against — that condition is DETECTED rather than only described: a window position whose control alt fraction exceeds 0.25 is reported with an excludedReason and an editedPercent of 0 instead of a number, warned about, and failed by the hard control-supports-the-window-base-calls gate check. Reported percentages are pool-level: Sanger sees the superposition, so which allele carries which combination of bystander edits is not recoverable from it at all.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoExplicit-window mode: the base it converts to, as READ on the control strand.
fromNoExplicit-window mode: the base the editor converts, as READ on the control strand (C for a CBE read forward, G for one read reverse).
editorNoBase editor id (be3, be4max, abe7.10, abe8e) — fixes the converted bases and the activity window in protospacer coordinates. Requires "protospacer". Mutually exclusive with the explicit window arguments.
offsetNoOverride the alignment offset between the reads (edited position p matches control position p + offset). Whole numbers only. By default it is found from the base calls outside the window; either way the identity reported back is the identity AT THE OFFSET USED, so overriding it does not hide a bad alignment behind the best-scoring one.
windowEndNoExplicit window end, 1-based inclusive, in CONTROL coordinates. Window length is capped at 40.
zThresholdNoSignificance threshold in standard deviations of the sample's own background. Must be between 1 and 10 — a value outside that range is REJECTED, not clamped, because a run silently retested at a threshold the caller did not choose looks exactly like one that was. Raising it raises the reported noise floor with it.
editedBasesYesBase calls of the edited pool's read.
protospacerNoThe 20-nt spacer, located in the CONTROL read. Found on either strand; a reverse-complement match numbers the protospacer right-to-left along the read and complements the converted bases (a CBE's C→T reads as G→A), which is handled. Must match exactly once.
windowStartNoExplicit window start, 1-based in CONTROL read coordinates. Requires windowEnd, from and to.
controlBasesYesBase calls of the UNEDITED control read.
editedChannelsYesPer-base [A, C, G, T] intensities of the edited read, same convention.
targetPositionNo1-based CONTROL position of the intended edit. Give it when you know it: without it the most-edited significant position is labelled the target and the rest become bystanders, which relabels a bystander-dominant result as a clean one.
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).
targetProtospacerPositionNo1-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?

Annotations only declare readOnlyHint and idempotentHint, but the description adds substantial behavioral context: 'PREDICTED, NOT MEASURED', no published validation, directional one-sided bias, non-constant variance, the noise floor semantics, and pool-level interpretation. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely long and repetitive, covering the same caveats multiple times ('reported but not quantified', crosstalk background, indel blindness, validation status). Important information is buried in dense prose rather than structured with bullets or section headers, making it harder for an agent to extract actionable guidance.

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?

Despite lacking an output schema, the description thoroughly explains return values: per-position percentages, z-scores, target/bystanders, background distribution, robust sd, outlier counts, and noiseFloorPercent with null semantics. It also covers coordinate conventions, failure conditions, and the excludedReason behavior, making it complete for a complex 14-parameter tool.

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 further meaning beyond the schema: it explains that targetPosition prevents bystander relabeling, that offset reports identity at the offset used, that raising zThreshold raises the noise floor, and the explicit-window from/to semantics on the control strand.

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: 'Quantify CBE/ABE base editing from a pair of Sanger traces'. It distinguishes itself from indels ('Blind to indels') and NGS-free quantification, differentiating it from sibling tools like sanger_indel_spectrum and sanger_knockin_quant.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly specifies when the tool is valid ('substitution', 'unedited control that starts within ±40 bases') and when it is not ('Not valid for indels', 'Not valid where the control read already carries the alt base'). It also describes the two window-location modes (editor id + protospacer, or explicit arguments), giving clear selection criteria.

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