Jean — Molecular Biology & Genomics

design_expression_variants

The expression-design deliverable: several coding sequences for one protein, each variant following a different published strategy (maximise codon adaptation, match the host's codon usage, harmonise with the native host, or preserve the initiation region), each scored by an engine — CAI, GC, the folding energy of the Kudla -4..+37 initiation window, and rare codons.

Input Schema

Name	Required	Description	Default
`cds`	No	the coding sequence to redesign, in frame and start-codon first. Unset falls back to THE SELECTION, on the strand the selection or its matching annotation states, then to the whole open record.
`seed`	No	seed for the solver's random draws, so a listed variant can be regenerated exactly. Advanced.
`_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.
`gc_max`	No	maximum GC fraction (0-1); set with gc_min. Advanced.
`gc_min`	No	minimum GC fraction (0-1); set with gc_max. Advanced.
`feature`	No	redesign this annotated CDS or gene by NAME instead of the selection, exactly as `codon_usage_analysis` takes one. Its own strand is used. Takes precedence over the selection; `cds` still wins over both.
`_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.
`postures`	Yes	which strategies to design, in order. max_cai = every amino acid takes the target host's single most-used codon; match_usage = reproduce the target host's synonymous-codon distribution rather than its single best codon, so rare codons stay at their natural rate; harmonize = put each codon at the same relative adaptiveness it had in the gene's native host, so the elongation rhythm (and any pause the protein folds around) survives the transfer; native_initiation = leave nt +1…+37 of the coding sequence exactly as they are and match the host's codon usage only downstream, so the redesign cannot add secondary structure to the window Kudla found dominant. The set IS the deliverable — asking for one gets one, and there is no hidden default of three.
`upstream`	No	the bases immediately 5' of the CDS (the 5'UTR/RBS region). Kudla's window starts 4 nt BEFORE the start codon, so without this the folding energy is reported over a truncated window and says so.
`gc_window`	No	window in bp the GC bounds apply over (whole sequence when unset). Advanced.
`host_table`	No	the TARGET host's codon-usage table, BY NAME, as the Codon Usage panel lists it. This is the way to pass a table: it resolves against the tables loaded in this project, so the numbers come from a table someone built or fetched. Leave unset and the active table is used.
`rare_below`	No	within-family frequency below which a codon counts as RARE, for the report only — it adds no constraint. Omit and no rare-codon count is reported, which is the honest answer: "rare" has no host-independent definition.
`native_table`	No	the gene's NATIVE host codon table, BY NAME from this project's loaded tables — required only for the `harmonize` posture, which matches relative adaptiveness BETWEEN two hosts. It must be a DIFFERENT table from `host_table`: harmonising a host against itself is a difference of zero.
`genetic_table`	No	genetic code for the translation constraint (default Standard). Advanced.	Standard
`avoid_patterns`	No	literal patterns (restriction sites, homopolymers) every variant must not contain.
`host_table_tsv`	No	ONLY for a table you are pasting yourself, measured elsewhere — prefer `host_table`, which names one this project already has. Do NOT write a table out from memory: codon frequencies are measured data, and a typed one is indistinguishable from a real one in the result. TSV: codon<TAB>count. Advanced.
`host_table_name`	No	how to name that table on every score it produced (e.g. "E. coli K-12, Kazusa"), so a reported CAI is attributable.
`native_table_tsv`	No	ONLY for a native table you are pasting yourself — prefer `native_table`. Do not write one out from memory (see `host_table_tsv`). TSV: codon<TAB>count. Advanced.

Output Schema

Name	Required	Description
`region`	Yes	what was actually redesigned — the selection when there is one, otherwise the whole open record, naming the STRAND and where it came from. Empty when the caller passed `cds` outright, because then there is no region, only a sequence they named
`report`	Yes	the whole comparison as Markdown — table, what each design trades, the provenance of every number, and the sequences — so it survives outside the transcript
`protein`	Yes	the protein every variant encodes — asserted per variant, not assumed
`records`	Yes	the variants as sequence RECORDS, so the run leaves the user holding the designs it describes
`skipped`	Yes	postures that were asked for and could not run, each with the reason
`best_cai`	Yes	the posture reaching the highest CAI — a ranking on ONE axis, never a recommendation
`distinct`	Yes	how many of the variants are DIFFERENT sequences
`variants`	Yes	one entry per posture: its sequence, what it was optimising for, what it trades away, and every score with the engine that produced it
`least_structured`	Yes	the posture whose initiation window folds least tightly (the highest, least-negative dG)

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 20, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is already given. The description adds real behavioral context beyond that: what engine scores each variant, that rare-codon counting is report-only and absent unless rare_below is set, and that requesting one posture yields one variant. It does not say whether results are persisted as a new record or simply returned, which is the main remaining gap for a non-read-only tool.

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?

It is a single dense sentence, but it is front-loaded with the deliverable and the strategy axis before the scoring list. The em-dash enumeration and parenthetical strategy glosses are justified, though they do make it more sprawling than needed.

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 18 parameters fully documented in the schema, a real output schema, and annotations present, the description only needs to orient the agent — and it does so by explaining the multi-variant design model and the scoring engine. The one thing an agent might still want, whether this writes to the project or just returns sequences, is not covered.

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 description coverage is 100%, so the schema already carries parameter meaning and a 3 would be the floor. The description still adds value by spelling out the four postures as strategies and by making clear that the posture list itself is the deliverable rather than being padded with a default third variant.

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 and product: producing several coding sequences for one protein, each following a named published strategy and each scored by CAI/GC/Kudla-window folding energy/rare codons. That is concrete enough to distinguish it from single-sequence tools like optimize_sequence or back_translate, but it never names an alternative, so the differentiation is implicit rather than explicit.

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

Usage Guidelines3/5

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

Usage is implied by framing it as 'the expression-design deliverable' that returns a set rather than one sequence, and the 'set IS the deliverable ... no hidden default of three' line clarifies expected scope. However, there is no explicit statement of when to choose this over sibling designers (optimize_sequence, back_translate, design_gene_fragment_order) or any precondition such as needing a loaded codon table.

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?