jean — Molecular Biology & Genomics

design_split_sites

Read-only

Decide where to CUT one sequence into Golden Gate fragments, optimising the split positions and the overhangs they create together. Where design_overhang_set proposes junctions for parts you already have, this fragments a sequence you are about to order: it searches every legal arrangement of fragments in your length window and ranks them by the measured ligation efficiency and fidelity of the overhangs each arrangement produces. Ported from OOGGA (Mukundan & Madhusudhan 2025) and scored against the same Potapov 2018 T4 ligase data the fidelity tools use.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`_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.
`traces`	No	how many ranked alternatives to return. The best arrangement is rarely the only acceptable one, and the runner-up often avoids a site you care about.
`dataset`	No	the measured ligation matrix to score against. OOGGA's own published choice is the T4 18 h 37 C set. Values: BsaI-HFv2 (BsaI-HFv2, Golden Gate cycling (4 nt)), BsmBI-v2 (BsmBI-v2, Golden Gate cycling (4 nt)), Esp3I (Esp3I, Golden Gate cycling (4 nt)), BbsI-HF (BbsI-HF, Golden Gate cycling (4 nt)), SapI (SapI, Golden Gate cycling (3 nt)), T4-01h-25C (T4 DNA ligase, 1 h at 25 C (4 nt)), T4-01h-37C (T4 DNA ligase, 1 h at 37 C (4 nt)), T4-18h-25C (T4 DNA ligase, 18 h at 25 C (4 nt)), T4-18h-37C (T4 DNA ligase, 18 h at 37 C (4 nt)). Advanced.	T4-18h-37C
`_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.
`sequence`	No	the sequence to fragment, in one piece. Leave it empty to fragment the open record.
`fragments`	No	pin the number of fragments instead of letting the search choose. Leave empty to take whatever the length window allows.
`exclude_to`	No	end of that span, exclusive. Only applies when exclude_from is set. Advanced.
`max_length`	No	longest allowed fragment, in bases — the vendor's upper limit, or the length you can sequence in one read.
`min_length`	No	shortest allowed fragment, in bases — usually what your synthesis vendor will accept.
`exclude_from`	No	start of a span no cut may fall in — a feature you need kept intact. Use with exclude_to. Advanced.
`alien_overhangs`	No	junctions already committed elsewhere in the assembly (a fixed vector's own ends), which this set must not collide with. Advanced.
`fidelity_weight`	No	exponent on the running FIDELITY — raise it to favour junctions that ligate to the right partner rather than a mismatched one. Advanced.
`efficiency_weight`	No	exponent on the running ligation EFFICIENCY — raise it to favour junctions that ligate readily. Efficiency and fidelity are different failure modes: a junction can ligate eagerly and promiscuously. Advanced.
`max_overhang_identity`	No	most positions two overhangs in the set may share before they are treated as confusable. Lower is stricter and rules out more arrangements. Advanced.

Output Schema

TableJSON Schema

Name	Required	Description
`score`	Yes	the objective for the winning arrangement: net efficiency^w x net fidelity^w
`breaks`	Yes	the winning arrangement's cut positions, in reading order
`report`	Yes	the whole result, every arrangement in full
`dataset`	Yes	the measured matrix actually scored against
`fragments`	Yes	the fragments to order: sequence, span, length and the overhang at each end. Consecutive fragments overlap by exactly the four-base junction
`overhangs`	Yes	the junctions the winning arrangement creates — wire this straight into score_overhang_fidelity to grade the set it chose
`candidates`	Yes	how many arrangements were feasible at all under these constraints
`alternatives`	Yes	the other ranked arrangements, each with its own breaks, score and junctions — the best is rarely the only acceptable one
`net_fidelity`	Yes	net fidelity across every junction, 0-1
`fragment_count`	Yes	how many fragments the winning arrangement needs
`net_efficiency`	Yes	net ligation efficiency across every junction, 0-1

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 20, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: it discloses the search strategy ('searches every legal arrangement'), the ranking basis (measured ligation efficiency and fidelity), and the scoring provenance (OOGGA / Potapov 2018 T4 ligase data). It does not cover runtime or result-size expectations, keeping it short of a 5.

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?

Front-loaded with the action and scope, then the sibling distinction, then provenance. Three dense sentences with little waste, though the closing OOGGA/Potapov citation is credence-building rather than operational and could be trimmed.

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?

An output schema exists, so return values need no explanation, and all 14 parameters are documented in the schema at 100% coverage. The description supplies purpose, alternative routing and scoring basis, which is sufficient for a read-only design tool; only runtime/result-volume expectations are absent.

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 carries full parameter meaning (length window, traces, weights, exclusions). The description only alludes to the length window and overhang quality in prose and adds no syntax or format detail beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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 resource ('Decide where to CUT one sequence into Golden Gate fragments') plus the optimisation objective. It also names the sibling it is not — design_overhang_set — and the differentiating condition, so an agent can distinguish it 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 Guidelines5/5

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

Explicitly routes between alternatives: 'Where design_overhang_set proposes junctions for parts you already have, this fragments a sequence you are about to order.' The when-to-use condition is stated, not implied, and the alternative tool is named.

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?