jean — Molecular Biology & Genomics

rank_strategies

Read-only

Compare EVERY assembly chemistry this engine has against one set of parts, and say what each one costs and risks. It runs them all, keeps the ones that really produce a construct, and reports the rest with the refusal the chemistry itself gave — so 'Golden Gate is the only way to build this, and its overhangs ligate correctly 99.8% of the time' is one step rather than six runs and a spreadsheet. There is deliberately no single 'best' score: combining the criteria needs weights nobody has settled, and the one criterion every published ranking leads with (cost) has no price this app can honestly cache. So the comparison is the answer, and the sort is by whichever criterion you name.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`parts`	No	the parts to assemble, in order — order is meaningful for Type-IIS. Wire records in, or name project documents.
`_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.
`enzyme`	No	Type-IIS enzyme for the chemistries that use one. `auto` is DnaCauldron's own default: it picks the enzyme from the sites the parts carry.	auto
`_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.
`order_by`	No	which criterion to order the feasible strategies by. Every criterion is reported for every strategy whichever one you pick. Values: steps (Steps (lower is better)), junctions (Junctions (lower is better)), primers (Primers (lower is better)), overhangFidelity (Overhang fidelity (higher is better)), weakestJunctionTm (Weakest junction Tm (higher is better)), framesBroken (Frames broken (lower is better)), diagnosticCutters (Diagnostic cutters (higher is better)), cost (Cost (lower is better)).	junctions
`digest_enzymes`	No	the enzymes a verification digest may use. Left unset the run uses your active enzyme collection; with neither, the diagnostic-digest criterion is reported as unavailable rather than guessed, because a digest is only meaningful against enzymes you have.

Output Schema

TableJSON Schema

Name	Required	Description
`best`	Yes	the chemistry at the top of the order you asked for — a position in that order, not a verdict. Null when no chemistry built these parts
`ranked`	Yes	every feasible strategy in order, each with every criterion and the reason for any it could not score
`refused`	Yes	the chemistries that produced nothing, each with the refusal it gave. Never dropped: 'this cannot be built that way, and here is why' is half the answer
`criteria`	Yes	the criteria themselves: what each one means and which direction is better
`feasible`	Yes	how many chemistries produced a construct from these parts
`notScored`	Yes	criteria NO strategy could score, with the reason — so an empty column says why it is empty

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 20, 2026

TDQS

A4/5.0

Behavior4/5

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

The annotations already establish read-only, non-destructive behavior. The description adds valuable operational context: it runs every chemistry, keeps only strategies that produce a construct, reports refusals from the chemistry itself, and deliberately avoids a single 'best' score because weights are unsettled and cost cannot be cached.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with its purpose, but it spans five sentences with an illustrative example and a philosophical rationale for the lack of a single score. Some of this elaboration could be tightened, making it less concise than optimal.

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?

Given the complex schema and the presence of an output schema, the description covers the tool's purpose, execution behavior, and ranking limitations well. It does not need to explain return values, and parameter defaults are left to the schema, so it is largely complete though it could state prerequisites more explicitly.

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 including the order_by enum. The description adds little parameter-level meaning beyond noting that the sort is by whichever criterion is named, which is already conveyed by the schema.

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 uses a specific verb ('Compare') and resource ('EVERY assembly chemistry this engine has') and states the scope ('against one set of parts') and outputs ('costs and risks'). This clearly differentiates it from siblings that design, simulate, or check a single assembly route.

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 provides a clear context for use: comparing all assembly chemistries in one step instead of six runs and a spreadsheet. However, it names no specific alternative tool and gives no explicit when-not-to-use conditions.

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?