Skip to main content
Glama

Jean — Molecular Biology & Genomics

verify_construct

Read-only

Compare a sequencing RESULT against the construct you designed and say what differs, where, and what it lands in.

Input Schema

NameRequiredDescriptionDefault
matchNoalignment limit `match`, as the Verify panel's own slider sets it. Advanced.
_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.
designYesthe construct you INTENDED — wire an upstream record or name a library document. Its features come with it, and they are what turns a difference into a consequence.
resultYeswhat actually came back from sequencing — wire a record or name a document.
_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.
gap_openNoalignment limit `gapOpen`, as the Verify panel's own slider sets it. Advanced.
mismatchNoalignment limit `mismatch`, as the Verify panel's own slider sets it. Advanced.
word_sizeNoalignment limit `wordSize`, as the Verify panel's own slider sets it. Advanced.
gap_extendNoalignment limit `gapExtend`, as the Verify panel's own slider sets it. Advanced.
band_marginNoalignment limit `bandMargin`, as the Verify panel's own slider sets it. Advanced.
min_coverageNoalignment limit `minCoverage`, as the Verify panel's own slider sets it. Advanced.
confident_coverageNoalignment limit `confidentCoverage`, as the Verify panel's own slider sets it. Advanced.
min_result_fractionNoalignment limit `minResultFraction`, as the Verify panel's own slider sets it. Advanced.

Output Schema

NameRequiredDescriptionDefault
reportYesthe whole verification, including the alignment frame and band
identityYespositions where design and result agree, over the aligned length, as a PERCENTAGE — 100 for an exact match, not 1
differencesYesevery difference with its 1-based position on the design and a one-line description
largeEventsYesstructural events — a dropped cassette or a duplicated span reads as one event here rather than as hundreds of substitutions
differenceCountYessubstitutions, insertions and deletions found — NOT counting positions the sequencer could not call
affectedFeaturesYesfeatures with a real difference, missing bases or uncalled positions — worst first
worstConsequenceYesthe most severe consequence term any affected feature carries, by Ensembl's published ranking — the one value a gate should read
uncalledPositionsYespositions the result could not call. Counted apart from differences on purpose: an uncalled base is not a mutation, and folding the two together reports a clean read as a damaged one

Schema Changelog

Changes observed during successful MCP inspections.

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

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered; the description adds that the comparison surfaces location and downstream consequence ('what it lands in'), which is real value. It does not disclose scoring/alignment sensitivity, thresholds, or what happens when the result fails to align – the very behavior a verification tool hinges on.

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 with no filler, and the comparison direction (result vs. design) is stated immediately. The closing phrase 'what it lands in' is somewhat abstract and costs a little clarity for its brevity.

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?

An output schema exists, so return values need not be explained, but a 13-parameter tool with nested `_subject`/`_files` objects and ten advanced tuning sliders deserves at least a note that defaults are usually fine and that design features drive interpretation. As written it is adequate but thin for the tool's complexity.

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 every parameter, including the ten advanced alignment sliders, is already documented in structured data. The description reinforces the semantic role of `design` (its features turn a difference into a consequence) but adds no syntax, format, or default guidance 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 specific verb (compare) and both operands (a sequencing result vs. the designed construct), plus the shape of the answer: what differs, where, and what it lands in. That distinguishes it from generic siblings like compare_constructions or verify_read, though it never names an alternative.

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 only implied by 'a sequencing RESULT against the construct you designed' – i.e., call it after sequencing to check a build. There is no explicit when-to-use/when-not guidance and no routing to nearby tools such as compare_constructions, alignment_agreement, or verify_read, which an agent would need to choose correctly.

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