Skip to main content
Glama

Cloning simulator

cloning_simulate
Read-onlyIdempotent

Assemble fragments by Gibson/overlap, Golden Gate (Type IIS), restriction–ligation (sticky or blunt), TOPO/TA, LIC or SLIC (T4-polymerase chew-back) or In-Fusion/CPEC, returning the product, the junctions and — for the primer-design methods — the junction primers. Each method is modelled as its own chemistry rather than as one product model with different labels: LIC's chew-back stops at the first occurrence of the single dNTP supplied, so a tail carrying that base stops it early and a tail without one lets it run past the junction, and both are refused with the offending base and position named.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
namesNoOptional labels for each fragment.
enzymeNoType IIS enzyme for Golden Gate — one of BsaI, BbsI, Esp3I (BsmBI); "BsmBI" also resolves to Esp3I. Any other name is rejected rather than substituted.BsaI
insertNoInsert sequence (restriction, topo and lic methods).
methodYesAssembly method. gibson/goldengate design the junction primers for bare fragments; restriction and topo build a product from a vector and an insert; lic and slic model T4-polymerase chew-back (sequence-defined and time-stopped respectively); infusion is In-Fusion/CPEC, 15 bp terminal homology with no exonuclease, and works out the fragment ORDER for itself.gibson
vectorNoVector sequence (restriction, topo and lic methods; for lic, the LINEARISED vector).
enzyme3NoInsert 3′ enzyme (restriction method).BamHI
enzyme5NoInsert 5′ enzyme (restriction method).EcoRI
circularNoProduce a circular product.
topoModeNoTOPO chemistry (topo method): TA (Taq 3′-A), blunt, or directional (pENTR/D-TOPO, needs 5′-CACC on the insert).ta
fragmentsNoFragments (5′→3′). Used by gibson/goldengate/slic/infusion. gibson and goldengate assemble them head-to-tail in the order given and add the junctions by primer; slic needs the homology already ON the fragments and keeps the order given; infusion needs it on the fragments too but derives the order from the homologies, so the order listed here is ignored. slic and infusion take at most 24.
overlapLenNoGibson homology-arm length (bp).
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; any positive value is checked against each junction's own homology, and both overrunning it and falling short of meeting the chew-back coming the other way are reported.
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.
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 model heterologous-overhang cloning.
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) — with the same base for both, each junction's shared block would have to avoid that base and its complement at once.
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 answer without it.
mergePreAddedArmsNoGibson only. When two fragments already share terminal sequence, count that share ONCE (the default — it is a homology arm the fragments already carry) or set false to concatenate it twice. The second reading is the right one when the shared block is a genuine tandem repeat, e.g. a 2x tag or enhancer split between its copies: nothing in the two fragments can tell the two apart, so the choice belongs to the caller. Either way the share is reported in preAddedArms and both readings are returned in `readings`.
dephosphorylateVectorNoCIP/rSAP-dephosphorylate the vector to suppress self-ligation background (restriction method).

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows calling this is safe and repeatable; the description does not repeat that but goes beyond the annotations by explaining failure modes and edge-case rules (LIC chew-back refusal with 'the offending base and position named', slice chew-back overrun/shortfall reporting, mergePreAddedArms returning 'both readings'). The description adds meaningful detail about outputs ('returning the product, the junctions and... junction primers'). However, it doesn't disclose things like the maximum fragment count (24, which is in the schema), runtime behavior, or the fact that output is always a simulation with no persistence. The bar is lower because annotations cover the safety/idempotency profile, and the description does add real behavioral context, so a 3 is fair but on the higher edge.

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?

The description is a single, information-dense sentence with a useful dash-separated expansion for the LIC edge case. The purpose statement is front-loaded and the chemistry model principle is stated up front. However, it runs long and packs several concepts into one sentence; an agent may need to re-read to parse the LIC clause. It is efficient but could be lightly broken into two sentences to improve scannability. It earns its length.

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 20-parameter, multi-chemistry simulation tool, the description is remarkably complete. It identifies the methods, the return values, the per-method data requirements (insert vs fragments), edge cases and defaults. The output is described (product, junctions, primers) even though there is no output schema. The long per-method schema descriptions carry the detailed parameter semantics, and the description handles the cross-cutting behavioral rules. Nothing an agent needs in order to select and call the tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents every parameter in detail. The description nonetheless adds critical meaning beyond the schema: it explains the semantic difference between methods that order fragments head-to-tail (gibson/goldengate) vs. those that derive order from homology (infusion), and it explains the significance of the mergePreAddedArms flag with a concrete example (2x tag). It also provides the conceptual logic behind lic's insertNucleotide/vectorNucleotide complement rule and the chewBackLen check. The description ties the parameters to the chemistry model rather than just restating the schema, exceeding the baseline 3.

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 opens with a specific verb ('Assemble fragments by') and an exhaustive list of the assembly chemistries the tool models, and it explicitly distinguishes the tool's core design principle ('Each method is modelled as its own chemistry...'). It clearly names the resource (fragments/vector → assembled product with junctions/primers). Against the sibling list, this stands apart from cloning_diagnose (diagnosis vs simulation), construct_autofix, verify_assembly, and golden_gate_fidelity/from_parts, and the opening sentence makes that differentiation clear without needing to read any 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 explains what the tool returns ('product, the junctions and — for the primer-design methods — the junction primers') and gives a working example of the LIC chemistry's behavior, which signals when a user should expect refusal. However, it does not explicitly state when NOT to use this tool or name alternative tools (e.g., when a user should reach for cloning_diagnose, golden_gate_fidelity, or construct_autofix instead). The usage context is clear but the exclusion criteria to siblings are absent. The long method enum descriptions in the schema add a lot of per-method usage guidance, which partly compensates.

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