Jean by Melad Labs

design_codehop

Design CODEHOP hybrid oligos from a block of aligned PROTEIN - for homologues too diverged for nucleotide-level design to see at all. Each primer is a 3' DEGENERATE core over a few conserved residues fused to a 5' non-degenerate consensus clamp, back-translated through a codon-usage table. A different algorithm from the degenerate designer, not a variant of it.

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

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnly/destructive/openWorld flags, and the description adds genuinely non-obvious behavior: the clamp grows until an unreachable Tm REFUSES rather than consuming the block (max_clamp_length as a stop condition), and the required table has no default because a silent host pick is undetectable downstream. It does not describe the returned oligo set, but an output schema exists.

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?

Three sentences, front-loaded with the verb and resource, then the mechanism, then the sibling disambiguation. No filler; the last sentence is the highest-value routing cue and closes the definition.

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 16-parameter nested-schema tool, the description supplies the conceptual model (core+clamp, codon-table back-translation) needed to call it sensibly, and an output schema covers returns. Minor gap: it doesn't state the minimum-alignment-size requirement or the block selection behavior, leaving those to the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description earns above that by explaining the architecture the parameters drive — degenerate 3' core over conserved residues, non-degenerate 5' consensus clamp grown to a target Tm, back-translated through a codon table — which gives meaning to table, clamp_tm, core_lengths and max_core_degeneracy.

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 and product ('Design CODEHOP hybrid oligos from a block of aligned PROTEIN') and scopes it to a case ('homologues too diverged for nucleotide-level design'). It explicitly separates itself from the closest sibling: 'A different algorithm from the degenerate designer, not a variant of it.'

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

Usage Guidelines5/5

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

Gives the selecting condition directly — use when homologues are too diverged for nucleotide-level design — and names the alternative (the degenerate designer) while ruling it out as a variant. An agent has a clear routing rule without opening any schema.

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

All Jean by Melad Labs 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?