Skip to main content
Glama

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

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

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
alignmentFigureYesthe reference and every read in the shared frame, 80 columns around the first ACCEPTED change (else the first difference, else the start), shaded by column identity; draw_alignment draws any other window of `alignedReads`

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedOutput schema / properties / coveragePct / x-unit
      Added value: +"%"
    • addedOutput schema / properties / identityPct / x-unit
      Added value: +"%"
  2. Changed2 schema fields changed
    • addedOutput schema / properties / alignmentFigure
      Added value: +{
      +  "description": "the reference and every read in the shared frame, 80 columns around the first ACCEPTED change (else the first difference, else the start), shaded by column identity; draw_alignment draws any other window of `alignedReads`",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "consensus",
      -  "variants",
      -  "accepted",
      -  "coveragePct",
      -  "identityPct",
      -  "perRead",
      -  "gaps",
      -  "conclusion",
      -  "cautions",
      -  "derivation",
      -  "record"
      -]New value: +[
      +  "consensus",
      +  "alignmentFigure",
      +  "variants",
      +  "accepted",
      +  "coveragePct",
      +  "identityPct",
      +  "perRead",
      +  "gaps",
      +  "conclusion",
      +  "cautions",
      +  "derivation",
      +  "record"
      +]
  3. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the readOnlyHint and destructiveHint annotations, the description discloses meaningful behavior: it aligns every read, votes column by column, and accepts a variant only when every covering read agrees. That consensus logic is behavioral context that annotations and schema do not provide.

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?

The description is front-loaded with the core action and then adds the key consensus rationale and input shape in two compact follow-up sentences. Every sentence contributes useful information without repetition or filler.

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?

Given the existing output schema, annotations, and full schema description coverage, the description covers what the tool does, how consensus works, and what inputs look like. No essential calling information is missing for an agent to invoke it correctly.

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 parameter meanings are already well documented. The description adds only the high-level note that reads arrive as records or bases and the reference is the record being operated on, which largely duplicates schema text rather than adding new parameter semantics.

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 states a specific verb and resource: comparing a set of sequencing reads against one reference, aligning every read, voting a consensus, and reporting protein-level differences. It also distinguishes this whole-plate consensus approach from grading reads one at a time, making its role clear 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?

The description provides clear context for when to use it: when the whole set must be considered together so a variant is accepted only when every covering read agrees. It stops short of naming explicit alternative tools or stating when not to use it, but the comparison to per-read grading is a strong usage signal.

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