Skip to main content
Glama

Knock-in / prime-edit rate from Sanger traces

sanger_knockin_quant
Read-onlyIdempotent

Measure the rate of a SPECIFIC intended edit from a pair of Sanger traces — an unedited control and the edited pool — by decomposing the edited trace onto three things at once: the wild-type allele, the intended edited allele, and the unintended indels. Serves both readouts that need this: HDR knock-in rate (what fraction of the pool carries the donor's edit, including an insert of novel sequence), and prime editing (the pegRNA's intended substitution, insertion, deletion or replacement as the intended column, and the indel byproducts at the nick as the shift columns). This is what sanger_indel_spectrum cannot do: that tool's basis is indexed by indel LENGTH, so an intended 6 bp knock-in and an accidental 6 bp NHEJ deletion are one column there. Returns knock-in / wild-type / unintended-indel percentages, the byproduct spectrum by shift, and the R² that says whether the model fits your traces at all. Non-negative least squares, so no allele is ever assigned a negative share. For a substitution or replacement the reference allele you name is checked against the control read before anything is fitted; an insertion and a deletion name no reference bases, so there only the position can be range-checked. PREDICTED, NOT MEASURED. Every run reports its own R²: how much of the observed window the basis actually explains, measured on YOUR traces, where a low value means the model is wrong here rather than that the edit is weak. On agreement with a reference method for real samples — amplicon sequencing or clonal genotyping — none is published for this implementation. The underlying decomposition is TIDE/TIDER's, whose authors report their own concordance, and that number does not transfer to this code so it is not quoted. This implementation's near-exact recovery of synthetic mixtures is deliberately not offered as validation: a synthetic mixture is built from the same idealised one-hot peaks the basis assumes, so recovering it tests the arithmetic and cannot test the assumption. Valid for: A pool whose intended edit is known EXACTLY, read against a control amplicon of the same locus and chemistry, with both reads extending well past the edit. The novel inserted bases of a knock-in carry an assumed peak shape rather than a measured one (returned as constructedPositions) — the more of the window they occupy, the more of the fit is testing that assumption. NOT valid when the reported R² is low; nor for separating an intended pure DELETION from an unintended indel of the same net length ANYWHERE in the window, not only one at the same site (the tool reports which case it is in sameShiftByproduct: when that column is not fitted, knockinPercent is the sum of the two); nor for telling an on-target knock-in from a random integration of the same donor; nor for resolving haplotypes, since a Sanger trace of a pool has no phase information.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
offsetNoOverride the alignment offset between the reads (whole number, −40 to 40). By default it is found from the base calls upstream of the edit. upstreamIdentity is always measured AT the offset used, so an override that is wrong shows up as a failed same-amplicon check rather than borrowing the auto-detected offset's score.
editKindYesShape of the intended edit, spelled as prime_editing_design spells it. "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 two lengths differ.
maxIndelNoLargest unintended indel to fit, in bp (1-20; out of range is rejected, not clamped). Every shift from −maxIndel to +maxIndel is included except 0, which is wild-type. The intended edit's OWN net shift is included too whenever its column is measurably different from the intended-edit column — it is dropped only when the two are the same vector, which happens for a pure deletion whose cut is at the edit. See sameShiftByproduct in the result for which of the two happened.
altAlleleNoThe bases the edit installs in their place (substitution and replacement).
refAlleleNoThe control bases the edit replaces (substitution and replacement). Checked against the control read: a mismatch is rejected, because building the intended-edit column at the wrong position yields a confident, meaningless number.
cutPositionNo1-based CONTROL position where UNINTENDED indels start — the nuclease cut or the PE nick. Defaults to the edit start. Separate from editPosition because a byproduct allele is wild-type up to the cut and shifted after it, so a wrong cut position makes those columns wrong over the first part of the window.
editedBasesYesBase calls of the edited pool's read.
insertedSeqNoThe novel bases inserted (insertion only).
controlBasesYesBase calls of the UNEDITED control read.
editPositionYes1-based position of the edit in CONTROL read coordinates: 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, which names the base before an insertion. The rule is uniform across all four kinds on purpose; a spec transcribed from VCF needs +1 on an insertion.
windowLengthNoBases from the edit site downstream used for the decomposition (20-300; out of range is rejected, not clamped). Unlike sanger_indel_spectrum there is no guard region: the edited positions themselves are the only signal separating a substitution from wild-type.
deletedLengthNoHow many bases are deleted (deletion only).
editedChannelsYesPer-base [A, C, G, T] intensities of the edited read, same convention.
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).

TDQS

A4.9/5.0
Behavior5/5

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

Despite readOnlyHint=true and idempotentHint=true, the description adds substantial behavioral disclosure beyond annotations: it returns knock-in/wild-type/unintended percentages and R², uses non-negative least squares, reports predicted-not-measured fit quality, exposes that synthetic-mixture validation is deliberately not offered, and warns that constructedPositions assume peak shape. It also discloses that no concordance with amplicon sequencing/clonal genotyping is published for this implementation. 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.

Conciseness4/5

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

The description is dense and comprehensive, and every major sentence carries information, but it is one very long paragraph that mixes core purpose, return values, validation caveats, and validity exclusions. It is appropriately detailed for a complex 14-parameter analysis tool, yet not tightly structured—headings or a clearer separation of 'what it returns' and 'when not to use' would improve scannability.

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 carries the burden of explaining return values, and it does: knock-in/wild-type/unintended percentages, byproduct spectrum by shift, R², constructedPositions, sameShiftByproduct, and the meaning of a low R². It also covers the two-sided pitfalls (pure deletions vs indels, insertion anchors, reference checks) that are essential for a correct call. For a tool of this complexity, nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, yet the description adds crucial semantics beyond the schema: editPosition uses a uniform VCF/HGVS +1 convention for insertions, refAllele is checked against the control read, cutPosition defaults to edit start and independently shifts byproduct columns, maxIndel includes the intended edit's own shift unless collinear, and windowLength has no guard region unlike sanger_indel_spectrum. This materially improves correct invocation.

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 precise verb and resource: 'Measure the rate of a SPECIFIC intended edit from a pair of Sanger traces'. It names the two intended readouts (HDR knock-in rate and prime editing) and explicitly contrasts itself with sanger_indel_spectrum, calling out the dimensional difference between edit identity and indel length. An agent can immediately distinguish it from its nearest sibling.

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?

The description states exactly when to use it ('Serves both readouts that need this'), what it can do that sanger_indel_spectrum cannot, and gives an explicit validity/environment section: exact edit known, control amplicon of same locus/chemistry, reads extending past the edit. It also lists NOT-valid cases (low R², pure deletions confounded with same-length indels, random integration, haplotypes). This is model usage guidance.

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