Skip to main content
Glama

jean — Molecular Biology & Genomics

multiplex_pcr

Read-only

Screen a primer POOL against one or more templates: every predicted product, per-primer off-target binding, the pairs that tell templates apart on a gel, and the all-against-all primer-dimer matrix a pool actually lives or dies by (pydna primer_screen + primer3 thal).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
poolNoalso partition the screened reactions into compatible tubes (MultiPLX grouping), judged by the preset and cutoffs below.
limitNominimum 3' footprint match for a primer to be considered bound (pydna's own default is 16). In bp.
_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.
primersNothe primer pool — literal sequences, or wire primer outputs from upstream design nodes.
_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.
max_sizeNolargest product to report. In bp.
min_sizeNosmallest product to report. In bp.
templatesNoextra templates to screen against — wire records or name library documents (the subject is included by default).
conditionsNothe reaction buffer every temperature here is computed in - Na+/K+/Tris/Mg2+/dNTPs, the primer concentration, the salt-correction method and the melting model. Left unset it is filled from your reaction-conditions settings, so this node and the PCR panel describe ONE tube; with neither it falls back to pydna's Taq defaults, which is what every golden was captured under. Advanced.
max_groupsNomost tubes the pool may be split into. Only applies when pool is true.
cutoffs_offNocutoffs to switch off (not applied at all), whatever the preset says. Only applies when pool is true. Advanced.
pool_presetNowhich authority's limits a tube is judged by: MultiPLX's three stringencies, or primer3's own structural limits (calibrated for the ΔG engine computing the scores). Only applies when pool is true.normal
max_per_groupNomost reactions one tube may hold. Only applies when pool is true.
include_subjectNoscreen against the node's subject as a template.
cutoff_max_tm_diffNoPrimer Tm spread [°C]: Largest primer Tm difference allowed inside a tube: one annealing temperature has to work for every reaction in it. Unset keeps the preset's value. In °C. Only applies when pool is true. Advanced.
cutoff_prim_prim_anyNoPrimer–primer, anywhere [kcal/mol]: Any duplex between two primers. Not extendable on its own, but it takes primer out of the reaction. Unset keeps the preset's value. In kcal/mol. Only applies when pool is true. Advanced.
cutoff_prim_prod_anyNoPrimer–product, anywhere [kcal/mol]: Any duplex between a primer and another reaction’s amplicon. Unset keeps the preset's value. In kcal/mol. Only applies when pool is true. Advanced.
cutoff_prim_prim_end1NoPrimer–primer, one 3′ end [kcal/mol]: One primer's 3′ end anneals anywhere on the other. Extendable, so it competes with the template. Unset keeps the preset's value. In kcal/mol. Only applies when pool is true. Advanced.
cutoff_prim_prim_end2NoPrimer–primer, both 3′ ends [kcal/mol]: A blunt 3′–3′ dimer: each primer can extend on the other, so the pair consumes itself and makes a short artefact band. Unset keeps the preset's value. In kcal/mol. Only applies when pool is true. Advanced.
cutoff_prim_prod_end1NoPrimer–product, 3′ end [kcal/mol]: A primer's 3′ end annealing inside another reaction's amplicon: it primes on the wrong molecule. Unset keeps the preset's value. In kcal/mol. Only applies when pool is true. Advanced.
cutoff_max_prod_len_diffNoBand spread (range) [bp]: Products in one tube must differ by no more than this, so one extension time suits them all. Unset keeps the preset's value. In bp. Only applies when pool is true. Advanced.
cutoff_min_prod_len_diffNoBand separation (ladder) [bp]: Products in one tube must differ by at least this much, or the bands co-migrate and you cannot tell which reaction worked. Unset keeps the preset's value. In bp. Only applies when pool is true. Advanced.
cutoff_max_prim_prim_any_tmNoCross-dimer Tm, anywhere [°C]: primer3's own limit, on the scale our ΔG engine is calibrated for. A dimer melting above this competes with template annealing. Unset keeps the preset's value. In °C. Only applies when pool is true. Advanced.
cutoff_max_prim_prim_end_tmNoCross-dimer Tm, 3′ end [°C]: primer3's limit for the 3′-end dimer: the configuration that extends. Unset keeps the preset's value. In °C. Only applies when pool is true. Advanced.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
poolsYeswith `pool` on: the tubes, the per-tube verification, and a refusal naming the limit and pair that forced it when no partition fits
dimerMapYesthe all-against-all dimer ΔG as a heatmap, the most stable structure each pair forms anywhere along the oligos
ampliconsYesevery predicted product (which pair, which template, what size)
poolCountYeswith `pool` on: how many tubes the partition needed (0 when it refused)
crossDimersYesall-against-all primer-dimer matrix, or null with fewer than two primers
diagnosticsYespairs that discriminate the templates by product size
primerStatsYesper-primer binding counts, including off-target
ampliconCountYesnumber of predicted products

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.2/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. The description adds useful algorithmic context (pydna primer_screen + primer3 thal) and output content, but does not disclose permissions, rate limits, or other behavioral traits beyond what the annotations and output schema already provide.

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, front-loaded sentence beginning with the core action. It is dense and slightly run-on, and the parenthetical '(pydna primer_screen + primer3 thal)' could be seen as implementation detail, but every clause contributes to describing the tool's output scope.

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?

Given the tool's complexity (24 parameters, nested objects) and the presence of a rich output schema, the description is minimally adequate. It omits any mention of the major 'pool' grouping mode, subject inclusion, and most parameter semantics, relying entirely on the schema for those details.

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%, so the schema fully documents all 24 parameters, including cutoffs and conditions. The description itself adds no parameter-level meaning beyond what is already in the schema, making the baseline score of 3 appropriate.

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 (Screen) and resource (a primer POOL against one or more templates) and enumerates the computed outputs: predicted products, off-target binding, gel-distinguishing pairs, and primer-dimer matrix. It clearly identifies a multiplex screening operation, though it does not explicitly distinguish itself from sibling tools like check_primer_specificity or primer_check.

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

Usage Guidelines2/5

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

There is no explicit guidance on when to use this tool versus alternatives, nor any when-not-to-use condition. The phrase 'a pool actually lives or dies by' is colorful justification, not operational guidance for selecting this tool over siblings such as design_primer_pairs or pcr_amplify.

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