Jean — Molecular Biology & Genomics

design_codehop

Design CODEHOP hybrid oligos from a block of aligned PROTEIN - for homologues too diverged for nucleotide-level design to see at all.

Input Schema

Name	Required	Description	Default
`table`	Yes	the codon-usage table to back-translate the clamp through, BY NAME as the Codon Usage panel lists it. REQUIRED and deliberately without a default: a CODEHOP designed under the wrong organism's usage is wrong in a way nothing downstream can detect, so picking one here would silently pick a host (§1).
`_files`	No	The 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.
`strand`	No	which strand to design on. `both` returns forward and reverse sets, which is what a PCR needs.	both
`max_run`	No	longest single-base run allowed; 2003's stated polynucleotide run limit. A primer exceeding it is rejected. In nt. Advanced.
`_subject`	No	The 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.
`clamp_tm`	No	target melting temperature for the non-degenerate 5' clamp (Rose 2003 step 8: "the current default is 60 °C, which usually provides a clamp of ~20 nucleotides"), measured as nearest-neighbour Tm in the buffer `conditions` names. In °C.
`alignment`	No	the ALIGNED PROTEIN rows, each { name, sequence } in one-letter amino acids with gaps preserved - wire an upstream protein alignment here. At least 3 sequences: the clamp is a CONSENSUS, and two have none worth the name.
`weighting`	No	how the alignment's rows are weighted before the core's consensus is read. Values: pb (Position-based (Henikoff & Henikoff 1994)), none (None — every row counts once). Advanced.	pb
`conditions`	No	salt, magnesium, dNTP and oligo concentrations plus the salt-correction method and any additives the clamp Tm is measured in. Left unset it is filled from your reaction-conditions settings, and falls back to pydna's Taq defaults (SantaLucia & Hicks 2004 table, 250 nM primer, Owczarzy 2008 salt correction) when there are none. Advanced.
`base_cutoff`	No	minimum predicted probability for a base to enter the degenerate core. Advanced.
`block_index`	No	which gapless block to design in, 0-based, ordered as `gaplessBlocks` returns them (blocks of at least 8 ungapped columns). Unset = the first.
`core_lengths`	No	core lengths the scan tries, in residues — every length here is scanned and the best-scoring core kept. Advanced.
`alignment_fasta`	No	an aligned PROTEIN FASTA, when there is no upstream alignment to wire.
`genetic_code_id`	No	NCBI `transl_table` id for the codon-to-residue map. Advanced.
`max_clamp_length`	No	ceiling on clamp growth, so an unreachable Tm REFUSES instead of consuming the whole block. Ours, and a stop condition rather than a published criterion - 40 nt is already twice the ~20 the paper expects. In nt. Advanced.
`max_core_degeneracy`	No	degeneracy ceiling for the 3' core (Rose 2003 step 7: "a maximum degeneracy of 128").

Output Schema

Name	Required	Description
`table`	Yes	which codon table the clamp was back-translated through, named so a design is never unattributable
`forward`	Yes	the first forward oligo, clamp + core
`primers`	Yes	the designed oligos: each with its degenerate 3' core, its consensus 5' clamp, the residues it covers and its degeneracy
`reverse`	Yes	the first reverse oligo
`blockCount`	Yes	how many gapless blocks the alignment offers, so a caller can see there were others to choose
`rejections`	Yes	why each candidate position was rejected - degeneracy, run length, or a clamp that could not reach the Tm
`primerCount`	Yes	how many oligos were designed

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 23, 2026

addedInput schema / properties / conditions / properties / selfcomp

Added value: +{
+  "description": "both strands are one self-complementary oligo (the concentration term becomes dnac1 rather than dnac1 − dnac2/2).",
+  "type": "boolean"
+}

First observedOct 20, 2026

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already declare this is a non-destructive, closed-world but non-read-only designer, and an output schema exists, so the description's burden is lighter. Beyond that it only implies a hybrid clamp+degenerate-core product, without stating refusal behaviour (e.g. unreachable Tm, too few sequences) or that the answer is a primer set rather than a sequence. Adequate but thin for a 16-parameter design tool.

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?

One sentence, front-loaded with the action and resource, with the second clause doing real work as a use-case discriminator. No filler and nothing redundant with the schema.

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?

With an output schema and fully documented parameters, the description only needs to carry selection and intent, and it does state intent. However, for a tool this complex it omits the key input constraint emphasised in the schema (a protein alignment of at least 3 rows, or a FASTA fallback) and does not disambiguate against the many other primer-design siblings, leaving an agent to infer routing from parameter names alone.

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 every parameter already carries detailed semantics (codon table rationale, block_index, clamp_tm, degeneracy ceilings). The description adds only the notion of designing 'from a block', which maps loosely to alignment/block_index but introduces nothing the schema does not already say better. Baseline 3 applies.

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?

Names a specific verb and resource ('Design CODEHOP hybrid oligos') plus the input substrate ('a block of aligned PROTEIN'), which is enough to distinguish it from generic primer designers like design_primers or design_degenerate_primers. It stops short of naming the nearest sibling explicitly, so it is clear but not maximally differentiating.

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 clause 'for homologues too diverged for nucleotide-level design to see at all' gives a concrete selection criterion: use this when nucleotide-level design fails. It does not name which alternative tool to fall back on when the target is NOT diverged (e.g. design_degenerate_primers), so the routing is one-directional.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Jean — Molecular Biology & Genomics tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?