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.

Input 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

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/5.0
Behavior4/5

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

Annotations only declare the safety profile (not read-only, not destructive, closed-world). The description adds genuinely non-obvious behavior: the output is context-dependent, so per-gene RBS results will not match, which is the main source of misuse. It does not say whether the operon is written into the project or merely returned, leaving some construction-side behavior unstated.

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 tight sentences with zero filler, front-loaded on the action and then the differentiator. The ALL-CAPS emphasis reads as shouting and is slightly informal for a tool definition, but it directs attention to the correct concept.

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?

This is a complex 9-parameter tool with nested objects, yet an output schema exists so return values needn't be described. The description omits any mention of the advanced optional inputs (promoter, terminator, leader, target_strengths) and of the minimum viable call (one CDS array), so an agent knowing only the description would miss much of the tool's surface.

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% and every parameter (cds, leader, promoter, terminator, target_strength(s), include_subject, _subject) is already documented in the schema, so the baseline is 3. The description reinforces the ordering/context semantics of `cds` but adds no syntax, ranges, or defaults beyond structured fields.

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 concrete verb+resource ('Stack several CDSs into one contiguous operon') plus the distinctive mechanic (fresh RBS designed in front of each gene against real upstream context). It explicitly distinguishes itself from the sibling design_rbs, so an agent can choose between them without opening either schema.

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 design_rbs contrast implicitly tells the agent when to prefer this tool: when multiple CDSs share a transcript and RBS choice depends on upstream sequence. There is no explicit 'use X instead when' for the related assembly tools (gibson_assemble, golden_gate_assemble, assemble_multiple_inserts), and no stated prerequisites such as annotated CDS boundaries.

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