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.

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

A3.7/5.0
Behavior4/5

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

Annotations already cover read-only/non-destructive/closed-world, so the description is free to add the actual pipeline: alignment, column-wise voting, and reporting of differing positions with their protein effect. That is meaningful behavioural context beyond the annotations, though it says nothing about how ties or failed alignments are handled.

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?

A single front-loaded sentence that moves from action to mechanism to output with no filler. It is dense and slightly run-on, but every clause carries information.

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?

With a full output schema, complete parameter descriptions and safety annotations, the description adds the conceptual model (shared frame, consensus vote, variant + protein effect) an agent needs to choose it. The lack of explicit alternative routing is the main remaining gap.

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 every parameter (reads, _subject, _files, phred thresholds, genetic_code, quality_filter) is documented in the schema itself. The description only implicitly ties 'the change it makes to the protein' to genetic_code and adds no format or syntax guidance of its own.

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: compare a SET of reads against one reference in one shared frame, align, vote consensus, report differing positions with protein consequences. The plural-reads/one-reference framing distinguishes it from per-read siblings like verify_read, align_read or map_reads, though none of those are named explicitly.

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 method description (needs multiple reads of the same reference to vote a consensus), but the description gives no explicit when-to-use or when-not guidance against alternatives such as consensus_from_traces, verify_read or alignment_agreement.

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