Skip to main content
Glama

Jean — Molecular Biology & Genomics

design_ligation_independent_primers

Read-only

Design the PCR primers a ligation-independent reaction needs — LIC, SLIC, In-Fusion, CPEC or USER: a Tm-matched pair per amplified fragment, in the order given.

Input Schema

NameRequiredDescriptionDefault
eklicNoLIC only: use the Ek/LIC vectors' own fixed extensions (Novagen TB163) instead of designing an arm. One insert only, and the vector is supplied cut.
_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.
arm_ntNothe homology arm on ONE primer, which is the unit every one of these authorities states. Left unset, the method's own recommended arm. Does not apply to USER, which finds its extension instead. In nt.
methodNothe cloning method, which decides what the tail is: LIC's arm is the Ek/LIC vectors' fixed overhang, SLIC's and CPEC's are ranges, In-Fusion widens its own for more than one insert, and USER's is a complementary dU pair whose length the search finds. Values: lic (LIC), slic (SLIC), in-fusion (In-Fusion), cpec (CPEC), user (USER).in-fusion
_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.
backboneNowhether the first fragment is amplified with the others (pydna splits each junction across the two neighbouring primers, so the junction is twice the arm) or supplied already cut (the whole arm goes on its neighbour's primer, and the junction is the arm). Values: amplified (Amplified), linearized (Linearized).amplified
circularNoclose the ring: the last fragment also overlaps the first. USER does not wrap on its own, so a USER ring needs a vector named below.
eklic_tagNoEk/LIC only: keep the C-terminal tag, or close the insert with the in-frame stop TB163 gives for a construct that omits it. Only applies when eklic is true. Advanced.
fragmentsNothe fragments to join, IN ASSEMBLY ORDER, the first being the backbone — wire upstream `record` outputs here, or name library documents.
target_tmNotarget annealing Tm for each primer's 3' footprint. In °C.
conditionsNosalt, magnesium, dNTP and oligo concentrations plus the salt-correction method the target Tm is measured in. Left unset it is filled from your reaction-conditions settings, and falls back to pydna's Taq defaults when there are none. Advanced.
user_vectorNoUSER only: join the two outer ends to a vector that already carries fixed 3' extensions, which is how a USER construct closes a ring. pNEB206A is the vector the method's own paper uses. Values: none (None (linear chain)), pNEB206A (pNEB206A). Only applies when method is user.none
min_footprintNoshortest annealing footprint the designer may settle for (pydna's `limit`). In nt. Advanced.
include_subjectNoput the node's subject first, as the backbone.
user_vector_endNoUSER with a vector: which of its two DIFFERENT extensions the first fragment's forward primer matches, which is what sets the insert's orientation in the vector. Values: left (Left (GGAGACAU)), right (Right (GGGAAAGU)). Only applies when user_vector is pNEB206A. Advanced.left

Output Schema

NameRequiredDescriptionDefault
armNtYesthe arm on one primer
primersYesper amplified fragment: the tailed amplicon its primers make, that amplicon's length, and both primers with tail, footprint, length and footprint Tm
summaryYeswhat was designed, naming the method and its chemistry
reactantsYesthe molecules that actually react, as sequence RECORDS: the amplicons where primers were designed, and any fragment supplied cut as itself. THIS is what to wire into `ligation_independent_clone.fragments`, not the untailed fragments
armVerdictYeswhether that arm is one the method's authority stands behind, in its own words
extensionsYesUSER only: per junction, the two fragments it joins, the single-stranded 3' extension each side gets (which is also where the dU sits), both tails, and whether that length is one the authority stands behind
junctionBpYesthe homology the design creates at each junction — the number `ligation_independent_clone.arm_nt` needs for the reaction to be predicted as designed
vectorEndsYesUSER with a vector: the two FIXED extensions that close the ring, which tail went on which outer primer, and where they come from. Not designed, because the vector was manufactured with them. Null when no vector is named, since a linear chain has no fixed ends to close on
primerCountYesoligos to order (two per amplified fragment)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / eklic_tag / description
      Previous value: -"Ek/LIC only: keep the C-terminal tag, or close the insert with the in-frame stop TB163 gives for a construct that omits it. Advanced."New value: +"Ek/LIC only: keep the C-terminal tag, or close the insert with the in-frame stop TB163 gives for a construct that omits it. Only applies when eklic is true. Advanced."
    • changedInput schema / properties / user_vector / description
      Previous value: -"USER only: join the two outer ends to a vector that already carries fixed 3' extensions, which is how a USER construct closes a ring. pNEB206A is the vector the method's own paper uses. Values: none (None (linear chain)), pNEB206A (pNEB206A)."New value: +"USER only: join the two outer ends to a vector that already carries fixed 3' extensions, which is how a USER construct closes a ring. pNEB206A is the vector the method's own paper uses. Values: none (None (linear chain)), pNEB206A (pNEB206A). Only applies when method is user."
    • changedInput schema / properties / user_vector_end / description
      Previous value: -"USER with a vector: which of its two DIFFERENT extensions the first fragment's forward primer matches, which is what sets the insert's orientation in the vector. Values: left (Left (GGAGACAU)), right (Right (GGGAAAGU)). Advanced."New value: +"USER with a vector: which of its two DIFFERENT extensions the first fragment's forward primer matches, which is what sets the insert's orientation in the vector. Values: left (Left (GGAGACAU)), right (Right (GGGAAAGU)). Only applies when user_vector is pNEB206A. Advanced."
  2. Added

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered and the bar is lower. The description adds genuine behaviour beyond that — one Tm-matched pair is produced per amplified fragment and fragment order matters — but says nothing about the constraints that really shape behaviour (branching by method, USER vector requirements, Ek/LIC single-insert limit), and an output schema is present so returns need not be described.

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 the verb, resource, method list and output shape in that order, and no filler. The em-dash/colon nesting makes it dense, but nothing is redundant.

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?

For a 15-parameter tool with nested objects, four enums, an output schema and full schema coverage, the description is adequate but thin at the edges: it never signals that behaviour branches on `method`, that USER requires `user_vector` to close a ring, or that Ek/LIC restricts input to one insert. Those are the facts an agent most needs before committing, and they live only in the schema.

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 per-parameter descriptions are unusually rich (method-dependent tails, arm_nt units, salt-correction range), so the schema carries the semantic load. The description only reinforces fragment ordering ('in the order given') and the per-fragment output pairing; it adds no parameter 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?

The description states a specific verb and resource ('Design the PCR primers a ligation-independent reaction needs') and enumerates the exact chemistries covered (LIC, SLIC, In-Fusion, CPEC, USER), so an agent can tell it apart from neighbouring primer-design tools. It stops short of naming an explicit sibling (e.g. design_gibson_primers, design_fusion_site_primers) and saying how it differs.

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: the phrase 'a ligation-independent reaction needs' signals the scenario, and the method list signals scope, but there is no when-to-use/when-not statement and no alternative tool is named. An agent must infer from the method list that this is the right designer rather than design_gibson_primers.

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