Skip to main content
Glama

jean — Molecular Biology & Genomics

assemble_operon

Stack several CDSs into one contiguous operon, designing a fresh ribosome-binding site in front of each one AGAINST ITS REAL UPSTREAM CONTEXT — which is why the RBS for gene 2 is not the RBS design_rbs would give it in isolation. Returns the assembled sequence, its layout, and each gene's achieved strength.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cdsYesthe coding sequences to stack, in order — wire upstream `record` outputs here, or name library documents.
_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.
leaderNoleader placed before the FIRST ribosome-binding site (defaults to the design leader). Advanced.
_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.
promoterNopromoter sequence to place in front of the operon (optional). Advanced.
terminatorNoterminator sequence to place after the last gene (optional). Advanced.
include_subjectNoput the node's subject first, as the first gene.
target_strengthNorelative initiation strength to aim for at every gene, on the model's own scale — 1 is as strong as its reference site. Overridden per gene by `target_strengths`.
target_strengthsNoper-gene target strengths, aligned to `cds` — the Operon panel gives every row its own, and a run through this door could not say the same thing. Shorter than `cds` falls back to `target_strength` for the rest. Advanced.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
genesYesper gene: the RBS designed for it, its spacing, the strength achieved and whether it hit the target
layoutYesevery element in order — promoter, each RBS, each CDS, terminator — with its start and end
recordYesthe assembled operon as a record
onTargetYestrue when EVERY gene reached its target strength — the number to check before ordering
sequenceYesthe assembled operon sequence

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already establish readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is known. The description adds meaningful behavioral context: RBSs are designed against real upstream context, and the output includes sequence, layout, and per-gene achieved strength.

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?

Two tightly written sentences front-load the core action and the key distinction from design_rbs. The parenthetical em-dash clause earns its place by explaining the context-aware design behavior, and there is no filler.

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

Completeness5/5

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

With 100% schema coverage, an output schema, and annotations covering safety, the description provides sufficient high-level purpose, behavior, and sibling differentiation. It does not need to restate parameter details or return values.

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 adds conceptual framing around RBS context and target strength but does not provide additional syntax, defaults, or constraints beyond what the schema states.

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?

The description states a specific verb ('Stack'), resource ('several CDSs into one contiguous operon'), and key differentiator (context-aware RBS design). It distinguishes this from design_rbs by explicitly noting that the RBS for gene 2 is not the isolated RBS design_rbs would produce.

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 clearly implies when to use this tool versus design_rbs by contrasting context-aware operon assembly with isolated RBS design. However, it does not explicitly state when-not to use it or name other assembly alternatives like golden_gate_assemble or gibson_assemble.

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