Skip to main content
Glama

jean — Molecular Biology & Genomics

quantify_base_editing

Read-only

Quantify BASE EDITING from a single Sanger trace, with no control read — the EditR method (Kluesner et al. 2018), ported and graded against the authors' own R. A base editor makes no double-strand break and no indel, so it is invisible to ICE and TIDE: the edit is a C→T or A→G inside the protospacer that shows up only as a second peak under the called base. This models the trace's OWN background from the positions outside the guide, then p-values every base of the guide against it. Emits the significant calls, so a pipeline can gate on whether editing happened and at which position.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
guideYesthe protospacer, 5'→3', without the PAM. Matched exactly against the read's own base calls; the coordinates it lands on come back in the result.
trim3Nolast base of the read the background model may be fitted on, 1-based inclusive. Pair it with `trim5`.
trim5Nofirst base of the read the background model may be fitted on, 1-based inclusive. GIVE BOTH BOUNDS OR NEITHER — upstream errors on a lone one rather than filling the other in. Left unset, upstream's automatic rule runs: drop the first 20 bases, then drop every base whose total peak height is under a tenth of the mean of what is left. The window is an INPUT to the answer, not a view: it is what the noise is estimated from, so tightening it lowers the cut-off.
_filesNoThe 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.
_subjectNoThe 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.
documentNowhich trace file to read: its name (`read_F.ab1`) or its project file id. LEAVE IT EMPTY to run on the chromatogram tab that is open. A file id is project-specific, so a template ships this unset.
guide_endNothe other end of an explicit placement, 1-based inclusive. Pair it with `guide_start`.
guide_startNoplace the guide yourself, 1-based inclusive in the read's own base calls, instead of matching it exactly. GIVE BOTH BOUNDS OR NEITHER. This is what a read carrying a sequencing error inside the protospacer needs: the analysis tests the bases you point at rather than refusing the read.
p_value_cutoffNoa base is called as edited when its share of the position's signal clears this trace's own noise model at this probability. EditR's own default is 0.01.
guide_is_reverse_complementNosearch for the guide's reverse complement. A C→T edit on the guide strand then reads as G→A in the result.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
callsYesevery significant call: { guidePosition, index, guideBase, base, percent, pValue }, biggest first
editedYeswhether ANY base of the guide carries a non-reference signal above this trace's own noise. Wire it into a gate
reportYesthe whole run: every guide position with all four base percentages and p-values, the four fitted noise models and their cut-off lines. This is what makes a negative checkable — 'no editing' and 'the model could never have fired' look identical without it
topChangeYesthe biggest call as `reference→edited`, e.g. `C→T`. Empty when there is none
guideStartYes1-based position in the read's own base calls where the guide was found — what a canvas needs to draw it
topPercentYesits share of that position's total peak height, 0–100
topPositionYesthe guide position (1-based) of the biggest call, or 0 when there is none

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations cover the safety profile (readOnly, non-destructive), so the bar is lower, but the description adds real behavior: it models the trace's own background from outside the guide, p-values each base, and emits significant calls so a pipeline can gate. It does not cover failure modes or what happens on an ungradeable read, but the analytical behavior is well disclosed.

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?

Front-loaded with the core method and scope, then the biological rationale, then the output behavior—a sensible ordering. It is somewhat dense across four sentences, but each carries information rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter tool with a rich schema and an output schema, the description supplies the method, the biological premise, and the emitted result without redundantly re-explaining return values. What it omits—edge cases and prerequisite file handling—is largely covered by the schema and annotations.

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 carries the parameter burden and a 3 is the baseline. The description adds only marginal meaning (the no-control premise, guide matching), while the genuinely useful parameter nuance—the trim window as a noise input that lowers the cut-off—lives in the schema, not the description.

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 base editing from a single Sanger trace') and pins the exact method (EditR, Kluesner et al. 2018). It distinguishes itself from adjacent tools like tide_quantify_indels and detect_trace_indel by explaining that base edits make no DSB or indel. An agent can identify the tool's niche 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?

Clearly sets the usage context ('single Sanger trace, with no control read') and explains that base edits are invisible to ICE/TIDE, which implicitly tells the agent when this tool is the right one. However, it never names a sibling tool to use instead in the control-bearing or indel case, so routing is inferential rather than explicit.

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.

Resources