Skip to main content
Glama

Verify a full assembly recipe

verify_assembly
Read-onlyIdempotent

Deterministic self-check: given the same method/parts cloning_simulate would use (restriction-ligation, Gibson, Golden Gate, LIC, SLIC or In-Fusion/CPEC — optionally deriving a part by in-silico PCR first), re-derive the expected WHOLE product and diff it against a claimed final sequence. Returns pass/fail plus the exact position and nature of any discrepancy — not an opinion, the same deterministic simulation SeqBench already runs, run a second time as a check. A recipe that can give more than one molecule is checked against ALL of them and matchedCandidate names the one the claim matched: a non-directional ligation really does put the insert in both ways round (half the plate carries each), a vector cut more than twice offers more than one backbone, and a Gibson junction whose fragments already share terminal sequence has two honest readings (one homology arm, or a tandem repeat present twice). See verify_construct for a narrower, insert-only check that doesn't require declaring the vector/enzymes/method.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
namesNoOptional labels for each fragment.
codingNoReport amino-acid effects of any mismatch, assuming claimedConstruct is (or contains) a coding sequence.
enzymeNoType IIS enzyme for Golden Gate — one of BsaI, BbsI, Esp3I (BsmBI); "BsmBI" also resolves to Esp3I, and NEB's variant names (BsaI-HFv2, BbsI-HF, BsmBI-v2) fold to the parent enzyme. Any other name fails the verification outright rather than being substituted.BsaI
insertNoInsert sequence (restriction and lic methods). Omit if insertPcr is given.
methodYesAssembly method used. restriction/gibson/goldengate are the primer-and-enzyme methods; lic and slic re-run the T4-polymerase chew-back (sequence-defined and time-stopped respectively) and infusion is In-Fusion/CPEC. Anything else is refused rather than substituted — see the note on "topo".
vectorNoVector sequence (restriction and lic methods; for lic, the LINEARISED vector). Omit if vectorPcr is given.
enzyme3NoInsert 3′ enzyme (restriction method).BamHI
enzyme5NoInsert 5′ enzyme (restriction method).EcoRI
circularNoTreat the product/claimed construct as circular (most plasmids are).
fragmentsNoFragments (5′→3′), assembled head-to-tail (gibson/goldengate/slic/infusion). BARE parts only — for gibson do NOT include the homology arms, which are added by the assembly primers and merged (so the product is fragment1+…+fragmentN). The convention is the OPPOSITE for slic and infusion: there the homology must already BE on the fragments (it arrived on the PCR primer tails), and infusion derives the ORDER from those homologies, so the order listed here is ignored. Use "" as a placeholder for any fragment supplied instead via the matching fragmentPcrs[i].
insertPcrNoDerive the insert by PCR instead: {template, forwardPrimer, reversePrimer, maxMismatches? (0-10), circular?}.
vectorPcrNoDerive the vector by PCR instead: {template, forwardPrimer, reversePrimer, maxMismatches? (0-10), circular?}.
frameStartNo1-based reading-frame start on claimedConstruct, used when coding is true.
overlapLenNoGibson homology-arm length (bp) that the assembly PRIMERS add at each junction. Since the fragments themselves must not carry their arms, this describes the junction/primer design only — it does not change the predicted product length or the verdict.
armTmTargetNoTarget annealing Tm (°C) for primer arms.
chewBackLenNoslic method: nucleotides removed from each 3′ end. A SLIC chew-back has no dNTP to arrest it and is stopped by time, so this is an input rather than a property of the sequence. 0 (default) models the intended reaction — chewed to the full homology and no further.
homologyLenNoinfusion method: terminal homology required at every junction, in bp. At least 15 — the junction is annealed and extended by a polymerase with no exonuclease to widen it and no ligase to seal it, so a shorter overlap is a different chemistry rather than a weaker version of this one.
fragmentPcrsNoParallel to fragments, same length: null (or omit) to use fragments[i] directly, or a PCR spec {template, forwardPrimer, reversePrimer, maxMismatches? (0-10), circular?} to derive that fragment instead.
vectorEnzyme3NoVector 3′ enzyme (restriction method); defaults to enzyme3.
vectorEnzyme5NoVector 5′ enzyme (restriction method); defaults to enzyme5. Set a different, compatible enzyme (e.g. BglII for a BamHI insert) to verify heterologous-overhang cloning.
claimedConstructYesThe sequence you claim you ended up with.
insertNucleotideNolic method: the single dNTP the INSERT's chew-back was run with. Normally the COMPLEMENT of vectorNucleotide (the classic pair is dTTP on the vector, dATP on the insert).
vectorNucleotideNolic method: the single dNTP the VECTOR's chew-back was run with (T for dTTP…). Required — T4 pol's exonuclease stops at the first occurrence of this base reading inward from each 3′ end, so there is no product to check against without it.
mergePreAddedArmsNoGibson only. When two fragments already share terminal sequence, count that share ONCE (the default — the fragments already carry their arm) or set false to concatenate it twice, which is the right reading when the shared block is a genuine tandem repeat. You should rarely need this: the check tries BOTH readings and reports which one matched in `matchedCandidate`. Setting it restricts the check to one.
dephosphorylateVectorNoThe linearised vector was CIP/rSAP-dephosphorylated (restriction method). Affects the self-ligation background warnings, not the product.

TDQS

A4.7/5.0
Behavior5/5

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

Beyond annotations (readOnly, idempotent), the description discloses deterministic behavior, handling of ambiguous assemblies (checks against ALL possible molecules and reports matchedCandidate), and the nature of output (pass/fail plus exact position and nature of discrepancy). It also describes edge cases like non-directional ligation and Gibson junction ambiguity, adding substantial behavioral context.

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 dense but front-loaded: it opens with purpose, then behavior, then the alternative. Every sentence adds value—no filler. The length is justified given the complexity (25 params, nested objects), and the structure guides an agent from core action to caveats to sibling differentiation.

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?

For a tool with 25 params and no output schema, the description covers the core behavior, return type, ambiguity handling, and relationships to siblings (cloning_simulate, verify_construct). It provides sufficient context for an agent to invoke it correctly, with remaining details in the schema. Nothing critical is missing.

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% with detailed parameter descriptions (e.g., fragments, method enum, chewBackLen, homologyLen), so the baseline is 3. The tool description adds little beyond the schema; it mentions high-level conventions (e.g., fragments for gibson vs slic/infusion) but these are already in the param comments. It does not introduce additional param 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 clearly states a deterministic verification tool that re-derives the expected whole product and diffs it against a claimed sequence, returning pass/fail with discrepancy details. It explicitly distinguishes from verify_construct by scope (whole vs insert-only) and references cloning_simulate as the basis, making it easy for an agent to know what it does.

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

Usage Guidelines5/5

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

It explicitly names verify_construct as a narrower alternative and the condition for choosing it ('insert-only check that doesn't require declaring the vector/enzymes/method'). It also frames the tool as a second run of cloning_simulate for verification, implying when to use it (checking a claimed construct). No ambiguity.

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.

TDQS

A3.6/5.0
Disambiguation4/5

Most tools have highly specific purposes (e.g., crispr_grna_design vs base_editing_design vs prime_editing_design). However, there is some overlap in sequence analysis tools (characterize_sequence, sequence_report) and plasmid annotation tools (plasmid_annotate vs plasmid_deep_annotate) which could cause confusion.

Naming Consistency3/5

The naming pattern is largely consistent with snake_case verb_noun or noun_descriptor (e.g., primer_design, plasmid_annotate, fastq_trim). However, there are exceptions like 'batch', 'workflow', 'gc_content', and 'cloning_diagnose' which don't follow the verb_noun pattern consistently. Also, some names are phrases like 'golden_gate_from_parts'.

Tool Count2/5

With 101 tools, this server is extremely large and likely overwhelming for agents. Even for a comprehensive bioinformatics toolkit, this exceeds a manageable scope, risking agent confusion and inefficient tool selection. A more modular approach would be advisable.

Completeness4/5

The tool surface covers a wide range of bioinformatics workflows including sequence analysis, primer design, cloning, CRISPR, NGS, expression analysis, and data export. There are minor gaps such as lack of a dedicated protein structure prediction tool and limited off-target genome coverage, but overall the set is impressively complete for its domain.

Resources