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.

Input Schema

Name	Required	Description	Default
`_files`	No	The 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.
`_subject`	No	The 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.
`document`	No	the first read: its name or its project file id.
`min_conf`	No	the confidence a base must clear to be called rather than written as a code. SeqTrace range 1-61.
`algorithm`	No	Bayesian 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_window`	No	how 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_match`	No	the 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_trim`	No	trim the consensus's own ends by quality. Note this is the stage primer trimming lives inside, so primer trimming does nothing without it.
`trim_primers`	No	cut the primers off the consensus ends. It runs INSIDE the quality-trim stage, so turning it on turns that stage on too.
`trim_end_gaps`	No	also 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_good`	No	how 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_primer`	No	the forward primer to cut, 5→3. Only applies when trim_primers is true.
`reverse_primer`	No	the reverse primer to cut, 5→3. Only applies when trim_primers is true.
`second_document`	No	the 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_second`	No	reverse-complement the second read before merging. A reverse read of the same amplicon needs this; two forward reads do not.

Output Schema

Name	Required	Description
`length`	Yes	its length in bases
`reading`	Yes	the same sentence the editor shows for this run, generated from it
`consensus`	Yes	the consensus, compact (no spacers) — what you would export or align
`readsUsed`	Yes	how many reads went in. With 1, an ambiguity is low confidence; with 2, it is disagreement
`trimmedFromEnds`	Yes	positions the consensus's own trimming stage removed
`ambiguousPositions`	Yes	positions 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.

First observedOct 20, 2026

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already establish read-only, non-destructive, closed-world behaviour, so the description's job is interpretive, and it delivers: it explains exactly what an IUPAC ambiguity code means in each of the two modes, which is a result an agent could otherwise misread. It does not discuss trimming side effects or primer-cutting interactions, but those are covered in the parameter descriptions.

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?

Two sentences, front-loaded with the action, with no filler. The second sentence is long and depends on an em-dash and a semicolon to carry two contrasting cases, which is compressed but still parseable.

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

Completeness3/5

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

With an output schema present, the description need not explain return values, and the IUPAC note is a useful bonus for interpretation. However, for a 15-parameter tool with interacting trimming options, the description gives no guidance on caller choice (Bayesian vs legacy) or on when the second read ought to be supplied beyond the schema's own wording.

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 coverage is 100%, so the baseline is 3; the description adds no parameter-level detail beyond what the per-parameter descriptions already say. Its IUPAC explanation maps onto the second_document / single-read distinction but only indirectly, so it does not clearly exceed the schema's own documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/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 with the ported SeqTrace caller.' It distinguishes the one-read and two-read cases, which separates it from pure base-calling tools, but it never names or contrasts sibling tools such as call_bases_from_trace or call_mixed_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 Guidelines2/5

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

There is no explicit when-to-use or when-not-to-use guidance and no named alternatives among the many trace-related siblings (call_bases_from_trace, call_mixed_bases_from_trace, trim_trace, adopt_trace_calls). Only an implicit hint that a single read is 'a different question' appears, and that phrasing lives in the schema, not the description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Jean — Molecular Biology & Genomics tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?