Skip to main content
Glama

Sanger indel spectrum (editing efficiency without NGS)

sanger_indel_spectrum
Read-onlyIdempotent

Quantify CRISPR editing from a pair of Sanger traces — an unedited control and the edited pool — by decomposing the edited trace onto shifted copies of the control. Returns the indel spectrum (how much of the pool carries each insertion or deletion size), the unedited fraction, and the R² of the decomposition, which is the number that says whether the model fits your traces at all. Non-negative least squares, so no allele is ever assigned a negative share. Does not work for base editing, which makes a mixed base rather than a shift. PREDICTED, NOT MEASURED. Every run reports its own R²: how much of the observed window the shifted-control basis actually explains. That is a measured adequacy of the model on YOUR traces, and a low value means the assumption is wrong here rather than that the edit is weak. On accuracy against a reference method for real samples, none is published for this implementation — the underlying decomposition is TIDE's, whose authors report their own concordance with amplicon sequencing, and that number does not transfer to this code so it is not quoted. This implementation's exact recovery of synthetic mixtures is deliberately not offered as validation either: it tests the arithmetic, not whether the model fits a real trace. Valid for: A pool of alleles that differ from one control read by simple insertions or deletions at a known cut site, where both reads come from the same amplicon and chemistry and both extend well past the cut. NOT valid for substitution-only edits — base editing produces a mixed base, not a shift, and this model cannot see it — nor for a knock-in whose insert is novel sequence rather than a frame shift of the control, nor for any run whose R² comes back low.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
guardNoBases skipped immediately after the cut, where the trace is least reliable.
offsetNoOverride the alignment offset between the reads. By default it is found from the base calls upstream of the cut, which is reported back along with the identity achieved.
maxIndelNoLargest indel to include in the basis, in bp (max 20). Every shift from −maxIndel to +maxIndel is fitted.
cutPositionYes1-based position of the expected cut, in CONTROL read coordinates.
editedBasesYesBase calls of the edited pool's read.
controlBasesYesBase calls of the UNEDITED control read.
windowLengthNoBases downstream of the cut used for the decomposition (20-300). Longer is better conditioned but needs more clean read.
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.3/5.0
Behavior5/5

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

This description goes far beyond the readOnlyHint and idempotentHint annotations. It discloses the model's exact method (non-negative least squares on shifted-control copies), that results are 'PREDICTED, NOT MEASURED', how to interpret R² ('a low value means the assumption is wrong here rather than the edit is weak'), and explicitly states that synthetic recovery tests are not offered as validation. This is rich, honest behavioral disclosure.

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

Conciseness3/5

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

The description is front-loaded with a clear purpose but is probe-heavy and repetitious, repeating the base-editing limitation at least twice and the phrase 'PREDICTED, NOT MEASURED' multiple times. While the details are valuable, the same content could be edited into a tighter structure.

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?

For a model with 9 params, a detailed algorithm, and no output schema, the description captures all necessary context: what the tool returns (indel spectrum, unedited fraction, R²), what R² means, when the model is expected, and explicit validity-limitation sections. It also explains the lack of external validation clearly, making the tool safe to invoke in a research context.

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?

The input schema has 100% description coverage—each of the 9 params has its own detailed description, including data formats and defaults. The main tool description adds no param-specific detail beyond the schema, so it stays at the baseline 3 rather than pushing higher.

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 'Quantify CRISPR editing from a pair of Sanger traces... by decomposing the edited trace onto shifted copies of the control', which is a specific verb + resource + method. It clearly distinguishes this tool from siblings by explicitly stating it handles simple indels at a cut site and does not work for base editing, preventing confusion with other CRISPR design 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 an explicit when/where-not scope: 'VALID for' and 'NOT valid for' clauses covering base editing, knock-ins, and low R² runs. However, it does not name an alternative sibling tool to use in those cases (e.g., base editing tools or sanger_vs_reference), so it falls short of the full explicit- alternatives 5 level.

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