Skip to main content
Glama

verify_read

Read-only

Grade a sequencing read against a reference (✓ verified / ⚠ near / ~ partial / ✗ divergent) from an alignment.

Input 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.
read_nameNowhat to call the read in the report row.read
target_lenYesreference length in bp. In bp.
aligned_refYesgapped reference (target) row.
target_nameNowhat to call the reference in the report row.reference
aligned_readYesgapped read (query) row.
near_coverage_pctNoreference coverage required to grade a read near. In %.
near_ungapped_pctNoungapped identity required to grade a read near — NOT the gap-inclusive `identity` output. In %.
verified_max_gapsNogaps tolerated in a verified alignment.
verified_coverage_pctNoreference coverage required to grade a read verified. In %.
verified_ungapped_pctNoungapped identity required to grade a read verified — NOT the gap-inclusive `identity` output. In %.

Output Schema

NameRequiredDescriptionDefault
reportYesthe row that goes in the record: target, read, grade, ungapped identity, coverage, mismatches and indel events
resultYesthe full alignment result (matches, mismatches, gaps, identities)
statusYesthe grade: verified / near / partial / divergent
identityYesgap-inclusive identity % (BLAST convention)
mismatchesYesmismatch count
coveragePctYeshow much of the reference the read actually covers — a perfect identity over 20% of the target is not a verified clone
indelEventsYesinsertion/deletion EVENTS, not bases — one 12 bp deletion is one event

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedOutput schema / properties / coveragePct / x-unit
      Added value: +"%"
    • addedOutput schema / properties / identity / x-unit
      Added value: +"%"
  2. First observed

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is fully covered structurally. The description adds the grading vocabulary (verified/near/partial/divergent), which is real behavioral context, but it doesn't say what determines those grades, that the cutoffs are adjustable via the near_*/verified_* params, or how ties/boundary cases resolve.

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?

A single front-loaded sentence with the action first and the outcome legend compactly parenthesized. Nothing superfluous and nothing buried.

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 12 parameters, nested objects, and 9 grading-threshold knobs, the description is thinner than ideal: it never notes that the default thresholds can be relaxed/tightened, nor how the tool relates to the align/compare siblings that would normally produce the input. An output schema exists, so return-value explanation is legitimately absent, which keeps this at minimum-viable rather than poor.

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 already explains every parameter, including the important 'ungapped identity, NOT gap-inclusive identity' caveat. The description contributes nothing parameter-specific, so baseline 3 applies.

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 — grade a sequencing read against a reference from an alignment — and enumerates the four grade outcomes (✓/⚠/~/✗), so the agent knows exactly what the tool produces. It does not, however, distinguish itself from nearby siblings such as compare_reads_to_reference or alignment_agreement, which an agent could plausibly confuse it with.

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?

The phrase 'from an alignment' implies the prerequisite (pre-gapped read/ref rows) but gives no explicit condition for choosing this over compare_reads_to_reference or alignment_agreement. No when-not guidance and no mention that thresholds are tunable to shift the grade boundaries.

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