Skip to main content
Glama

screen_oligo_structure

Read-only

Fold a set of oligos and check them against each other: every oligo's hairpin, its self-dimer anywhere and its self-dimer at the 3' end, plus the cross-dimer with every other oligo in the set, at any position and at a 3' end. This is primer3's thal — the same engine the Tm columns elsewhere use — so a pool can be screened before it is ordered rather than explained after a gel. The 3'-end measures are the ones that matter for a primer-dimer BAND, because only a paired 3' end extends. Works on any oligo: primers, probes, ssODN donors, guides, adapters.

Input Schema

NameRequiredDescriptionDefault
namesNooptional labels, in the same order as `oligos` — what the pair table calls each one. Missing or short, the rest are numbered. 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.
oligosYesthe oligos to screen, 5'→3'. One is a valid pool: it still gets its hairpin and self-dimer. Wire the primers out of a design run, or list them.
dv_concNodivalent cations (Mg²⁺), mM. In mM.
mv_concNomonovalent cations (Na⁺ + K⁺ + Tris⁺), mM. In mM.
_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.
dna_concNooligo strand concentration, nM — it moves a DIMER's Tm and leaves a hairpin's alone, because a hairpin is unimolecular. In nM.
max_loopNolargest internal loop the alignment will span (primer3's MAX_LOOP). Advanced.
dntp_concNototal dNTPs, mM — subtracted from the divalent term, because dNTPs chelate Mg²⁺. In mM.
temperatureNothe temperature ΔG is evaluated at. It does NOT move any Tm — Tm is the structure's own melting point — so change it to read ΔG at your annealing temperature. In °C. Advanced.

Output Schema

NameRequiredDescriptionDefault
cleanYesthe oligos that broke no limit of their own AND appear in no flagged pair — the ones to order. An oligo is dropped from here for a partner's sake, which is the point of screening a POOL
pairsYesevery unordered pair INCLUDING the self diagonal, with the any-position and 3'-end cross-dimer and which oligo's 3' end the reported end measure belongs to
limitsYesthe five primer3 cutoffs every verdict here was made against, and the settings file they come from — a verdict whose threshold is not stated is not checkable (§10a)
flaggedYesonly the oligos and pairs that broke a limit, with which limit — the list to act on. Empty is a real result and means every measure sat under primer3's cutoffs
perOligoYesper oligo: its hairpin, its self-dimer anywhere and its 3'-end self-dimer, each with ΔG, ΔH, ΔS, Tm, the limit it was graded against and whether it exceeds it — plus primer3's own drawing of the pairing, so a number can be checked rather than trusted
conditionsYesthe buffer every number here was computed in, including the values left at their default — so a result carries its own reaction rather than an unstated one
provenanceYeswhich primer3 this engine IS, and which one a user comparing against primer3web or bioconda `ntthal` is holding. The two generations disagree on about 3% of primer-length oligos
worstAnyTmCYesthe highest any-position dimer melting temperature in the set, self-dimers included
worstEndTmCYesthe highest 3'-end dimer melting temperature in the set — the single number that predicts a primer-dimer band. Self-dimers count, because an oligo dimerising with itself makes a band too. 0 means no 3'-anchored alignment was found at all, not that the set is safe
worstHairpinTmCYesthe highest hairpin melting temperature across the oligos — a hairpin melting above the annealing temperature competes with the template
incompatibleCountYeshow many DISTINCT pairs broke a limit — the self diagonal excluded, because a single oligo's self-dimer is not a pair problem and counting it makes a one-oligo run report an incompatibility. Branch a workflow on this rather than re-deriving it from `pairs`; read `flagged` for the self-structures

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedOutput schema / properties / worstAnyTmC / x-unit
      Added value: +"°C"
    • addedOutput schema / properties / worstEndTmC / x-unit
      Added value: +"°C"
    • addedOutput schema / properties / worstHairpinTmC / x-unit
      Added value: +"°C"
  2. First observed

TDQS

A4/5.0
Behavior4/5

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

With readOnlyHint=true and destructiveHint=false already covering safety, the description adds meaningful behavioral context: it identifies the underlying primer3 'thal' engine, explains that 3'-end measures matter because only a paired 3' end extends, and notes the tool works on any oligo type. It does not describe runtime behavior or limitations, but the annotations and output schema cover the main safety and return-shape concerns.

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 front-loaded with the core action and structure, then adds rationale for the 3'-end focus and scope of acceptable oligo types. Every sentence contributes to understanding what the tool does and why it matters, with no wasted filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 10 parameters, nested project references, and an output schema, the description covers the essential purpose, computation, and usage context. The _files/_subject parameters are left to their schema descriptions, which is reasonable given they are generic project-record arguments.

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 already documents all parameters thoroughly. The description itself adds little parameter-level detail beyond implying a set of oligos and noting that it works on any oligo type; it does not explain the concentration or temperature parameters beyond what the schema provides.

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 gives a specific verb and resource: 'Fold a set of oligos and check them against each other', then enumerates exactly which structures are checked (hairpin, self-dimer anywhere, self-dimer at 3' end, cross-dimer with every other oligo). It is very clear about scope, but it does not explicitly name or differentiate from sibling tools such as primer_check or melting_temperature.

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?

It provides a clear usage context: 'a pool can be screened before it is ordered rather than explained after a gel.' This tells the agent when the tool is useful, but it does not state when-not to use it or point to alternative tools for related checks.

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