Skip to main content
Glama

jean — Molecular Biology & Genomics

plan_thermocycler_program

Read-only

Plan the cycling programme for an amplicon on a NAMED enzyme, and check the reaction against that manufacturer's own published limits. The extension rate and the denaturation step come from the product's datasheet and protocol manual; the annealing temperature is yours (from design_primers or pcr_amplify), and anything the manufacturer does not publish comes from the pydna-faithful Taq or Phusion/Q5 preset — the result says which numbers came from where. The check reports the product as a percentage of the vendor's stated maximum, the extension time its rate implies, the substitutions expected per molecule and the fraction of molecules that should be error-free, each finding quoting the specification line it rests on.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
stepsNo3-step keeps a separate annealing stage; 2-step merges it into the extension, which is what a high-Tm pair allows. `auto` lets the builder decide from the primer Tms. Advanced.auto
_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.
cyclesNocycles in the main block.
enzymeNothe cataloged product to plan on, or `generic` for the preset alone. Its datasheet supplies the extension rate and, where its manual states one, the denaturation step. Values: generic (Generic preset (no datasheet)), takara-taq (Takara Bio · TaKaRa Taq / EmeraldAmp GT), takara-ex-taq (Takara Bio · TaKaRa Ex Taq / EmeraldAmp MAX), takara-la-taq (Takara Bio · TaKaRa LA Taq), takara-ex-premier (Takara Bio · TaKaRa Ex Premier), primestar-gxl (Takara Bio · PrimeSTAR GXL DNA Polymerase), primestar-hs (Takara Bio · PrimeSTAR HS DNA Polymerase), primestar-max (Takara Bio · PrimeSTAR Max DNA Polymerase Ver.2), primestar-longseq (Takara Bio · PrimeSTAR LongSeq DNA Polymerase), cloneamp-hifi (Takara Bio · CloneAmp HiFi PCR Premix), speedstar-hs (Takara Bio · SpeedSTAR HS DNA Polymerase), terra-direct (Takara Bio · Terra PCR Direct Polymerase Mix), titanium-taq (Takara Bio · Titanium Taq DNA Polymerase), advantage-hd (Takara Bio · Advantage HD Polymerase Mix), qiagen-taq (QIAGEN · Taq DNA Polymerase), qiagen-hotstartaq (QIAGEN · HotStarTaq DNA Polymerase).generic
_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.
anneal_cYesannealing temperature [°C] for the pair — the Ta the Tm model gave you, not a guess this tool makes. In °C.
touchdownNostart with a touchdown block: the annealing temperature starts high and drops each cycle to the Ta, so early cycles favor the specific product (Korbie & Mattick 2008).
gc_percentYesproduct GC [%], which decides whether the vendor's GC window is cleared. In %.
polymeraseNowhich annealing convention and which preset supplies whatever the datasheet does not. Values: taq (Taq), dbd (Phusion / Q5 (DNA-binding domain)).taq
amplicon_bpYesproduct length [bp] — pcr_amplify and design_primers both emit it.
touchdown_cyclesNotouchdown cycles before the main block (they add to `totalCycles`). Only applies when touchdown is true.
touchdown_delta_cNohow far the annealing temperature drops per touchdown cycle. In °C. Only applies when touchdown is true.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
programYesthe planned programme as a thermocycler would take it, stage by stage
findingsYesthe reaction check: each finding with its severity, its sentence and the vendor line it quotes. Empty for a reaction inside every published limit, and absent entirely for `generic`, which has no limits to check.
denatureCYesper-cycle denaturation temperature [°C] actually planned
denatureSecYesper-cycle denaturation time [s] actually planned
totalCyclesYescycles including any touchdown block
extensionSecYesextension time [s] this amplicon needs at the enzyme's published rate
fromDatasheetYeswhich of the planned numbers came from the product (the rest are the preset’s) — the same list the panel turns into its sentence

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: provenance rules (datasheet vs pydna-faithful Taq/Q5 preset, and that the result says which is which) and the content of the check (percentage of vendor maximum, extension time, substitutions per molecule, error-free fraction, each finding quoting a spec line).

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?

Two sentences, purpose front-loaded before the sourcing/check detail, with no filler. It is dense and slightly long, but every clause carries information (provenance, fallback presets, check outputs).

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?

With a full output schema and complete annotations, the description needn't explain return values, and it still spells out what the check reports and where each number originates. It stops short of describing failure modes or the interaction between the required amplicon_bp/gc_percent inputs and the vendor windows, but nothing essential to calling it 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%, so the schema already documents all 12 parameters, including enum value explanations and the _subject/_files shapes. The description reinforces the semantics of anneal_c and the enzyme datasheet sourcing but adds no parameter-level detail the schema lacks; baseline 3 applies.

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?

States a specific verb+resource ('Plan the cycling programme for an amplicon on a NAMED enzyme') and a second function ('check the reaction against that manufacturer's own published limits'). This is clearly distinguishable from siblings like pcr_amplify (which produces the amplicon) and melting_temperature (which computes Tm).

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 situates the tool in a workflow by telling the agent where its inputs come from — the annealing temperature is 'yours (from design_primers or pcr_amplify)' and is explicitly 'not a guess this tool makes'. That is clear context for when to call it, but it names no exclusions or alternate tools for the same job.

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