Skip to main content
Glama

jean — Molecular Biology & Genomics

consensus_from_traces

Read-only

Merge one or two Sanger reads into a consensus with the ported SeqTrace caller. With two reads (typically a forward and a reverse of the same amplicon) an IUPAC ambiguity code marks a position the two DISAGREE about; with one read there is nothing to disagree with and a code marks a position where no single base cleared the confidence bar. Returns the consensus, how many positions are ambiguous, and how many the consensus's own trimming stage cut from the ends.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
_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.
documentNothe first read: its name or its project file id.
min_confNothe confidence a base must clear to be called rather than written as a code. SeqTrace range 1-61.
algorithmNoBayesian converts each base's Phred to a posterior and combines the reads position by position; legacy lets the higher-confidence base win each position outright. They are different callers, not settings of one.Bayesian
trim_windowNohow many consensus bases the quality-trim mean is taken over. Wider is more forgiving of a single bad base and slower to stop at a genuinely bad end. Advanced.
primer_matchNothe fraction of a primer that must match for it to be cut. 1 is exact; lower tolerates the mismatches a real read carries at its noisy start. Only applies when trim_primers is true. Advanced.
quality_trimNotrim the consensus's own ends by quality. Note this is the stage primer trimming lives inside, so primer trimming does nothing without it.
trim_primersNocut the primers off the consensus ends. It runs INSIDE the quality-trim stage, so turning it on turns that stage on too.
trim_end_gapsNoalso cut the gap runs at each end, where only one read reached. With two reads those stretches are single-read consensus and read as agreement when they are not. Advanced.
trim_min_goodNohow many of those bases must clear `min_conf` for the window to be kept. It cannot exceed `trim_window` and is clamped to it rather than refused. Advanced.
forward_primerNothe forward primer to cut, 5→3. Only applies when trim_primers is true.
reverse_primerNothe reverse primer to cut, 5→3. Only applies when trim_primers is true.
second_documentNothe second read, usually the reverse of the same amplicon. Leave empty for a single-read consensus, which is a different question and is reported as one.
reverse_complement_secondNoreverse-complement the second read before merging. A reverse read of the same amplicon needs this; two forward reads do not.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
lengthYesits length in bases
readingYesthe same sentence the editor shows for this run, generated from it
consensusYesthe consensus, compact (no spacers) — what you would export or align
readsUsedYeshow many reads went in. With 1, an ambiguity is low confidence; with 2, it is disagreement
trimmedFromEndsYespositions the consensus's own trimming stage removed
ambiguousPositionsYespositions written as an IUPAC code. Wire it into a gate — but read `readsUsed` first, because the number means two different things

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: what an IUPAC code means in each mode, that trimming cuts bases from the consensus ends, and the interdependency between primer trimming and the quality-trim stage.

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

Conciseness5/5

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

Three front-loaded sentences with no filler: the operation, the mode-dependent meaning of ambiguity codes, and the return summary. Every sentence carries information an agent needs.

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?

An output schema exists, so return values need not be enumerated, and the description still summarizes them. For a 15-parameter tool with nested objects the schema carries the parameter burden, and the description covers the mode semantics and trimming dependencies well; only explicit sibling routing is missing.

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% and the schema itself documents every parameter in depth (defaults, ranges, dependencies). The description adds little parameter-specific syntax beyond restating the ambiguity/trimming concepts, so the baseline of 3 is appropriate.

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 ('Merge one or two Sanger reads into a consensus') and names the underlying caller (ported SeqTrace). The single-vs-two-read explanation makes the operation's scope unambiguous and separates it from single-trace callers like call_bases_from_trace.

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?

Gives clear context for when each mode applies: two reads for a forward/reverse amplicon pair, one read when there is nothing to disagree with, and explicitly tells the agent to leave second_document empty for a single-read consensus. It does not, however, name alternative sibling tools to prefer for other trace tasks.

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