Skip to main content
Glama

jean — Molecular Biology & Genomics

compare_reads_to_reference

Read-only

Compare a SET of sequencing reads against one reference in ONE shared frame: align every read to the reference, vote a consensus column by column, and report the positions where the reads differ from it, each with the change it makes to the protein. This is the whole-plate answer that grading reads one at a time cannot give — a variant is accepted only when every covering read agrees, so a single bad call does not become a mutation. Reads arrive as records or bases; the reference is the record this step runs on.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
readsNothe reads to compare — wire a batch of trace RECORDS in (their names come with them, and the per-read table is keyed by name), wire plain sequences, or name project documents.
_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.
end_phredNoend trimming: the read becomes readable where three consecutive bases reach this score, and everything outside is masked. A Sanger read is unreliable at both ends by construction, which is why the ends are trimmed by RUN rather than per base. Only applies when quality_filter is true.
min_phredNomask any single base below this phred score. Only applies when quality_filter is true.
genetic_codeNoNCBI genetic-code table id, used to say what a variant does to the protein of a CDS on the reference. Advanced.
quality_filterNomask low-quality bases before the vote. Off by default, deliberately: a comparison shows what the FILES say before it shows what a filter says.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
gapsYesstretches of the reference no read covers, as 1-based inclusive runs. A clean comparison over 60% of a construct is not a verified construct, and this is the half that says so
recordYesthe consensus as a linear record, ready for any downstream step
perReadYeseach read's own coverage, identity and substitution / deletion / insertion counts, plus how often it disagrees with the accepted consensus — the row that says WHICH read is the problem
acceptedYeshow many of those the vote accepted — every covering read agreed
cautionsYesevery caution this comparison raises, each naming its own subject: uncovered stretches, reads that reach across only part of the frame, reads that dissent from the accepted consensus, insertions the reads could not resolve, mixed peaks
variantsYesone row per column where a read differs from the reference: its position, the reference base, the voted base, whether the vote ACCEPTED it, the coverage behind it and the consequence for the protein
consensusYesthe voted consensus as a sequence, gaps and unresolved insertions removed — the sequence to hand on
conclusionYesthe run's headline in one sentence, generated from THIS result and identical to the words the panel shows
derivationYesthe chain behind the numbers: what identity was measured over (and that an indel does not lower it), the unanimity rule, how one frame came out of N pairwise alignments, the quality gate, the genetic code and the inputs
coveragePctYeshow much of the reference any read covers at all
identityPctYesof the covered columns, how many match the reference

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds genuine behavioral context the annotations do not: the acceptance rule ('a variant is accepted only when every covering read agrees, so a single bad call does not become a mutation') and the deliberate default of quality_filter being off. It stops short of describing input-format handling nuances or failure modes.

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?

Three sentences, front-loaded with the core action before the rationale and input formats. Slightly over-written in places ('the whole-plate answer that grading reads one at a time cannot give'), but every sentence carries information and none is 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?

An output schema exists, so return values need not be explained, and annotations carry the safety profile. For a 7-parameter, nested-object tool the description adequately conveys the operation, its consensus semantics, and the fact that the reference is the step's subject. Missing only explicit routing against the crowded sibling set.

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 documents reads, _subject, and the phred/code/quality parameters in detail; baseline is 3. The description adds only modest framing ('Reads arrive as records or bases; the reference is the record this step runs on') without any format, ordering, or interaction detail beyond the schema.

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 precise verb and resources (compare a SET of reads against ONE reference) and even describes the mechanism — align, vote consensus column by column, report differing positions with protein effect. It implicitly separates itself from per-read tools ('grading reads one at a time cannot give'), but never names the close siblings (alignment_agreement, consensus_from_traces, variant_call_summary, map_reads) an agent must choose between.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Usage is implied by 'the whole-plate answer that grading reads one at a time cannot give', which conveys set-level consensus comparison rather than per-read checking. However there are no explicit when/when-not statements and no alternatives named, which is a real gap given the dozens of overlapping read/variant/alignment siblings.

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