Jean — Molecular Biology & Genomics

design_knockout_package

The complete build package for a knockout or knock-in, as one object: guides inside the target, an off-target census for the chosen one within this molecule, a repair template with real homology arms, a screening PCR whose primers sit OUTSIDE the arms, the protocol in order, the fragments and oligos to buy, and every coordinate ready for the map.

Input 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.
`guides`	No	how many guides to carry into the package, best-scoring first. The rest are the alternatives, not filler.
`insert`	No	sequence to place at the cut (a tag, a selection cassette). Leave empty for a scarless rejoin — the package then WARNS that the two screening products are the same length.
`subject`	No	the molecule to edit — wire a record or name a library document; leave unset to edit the open record.
`_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.
`nuclease`	No	the nuclease (PAM + spacer length) to scan the target for. Values: SpCas9 (SpCas9: NGG (3')), SpCas9-NG (SpCas9-NG: NG (3')), SpG (SpG: NGN (3')), SpRY (SpRY: NRN (3')), xCas9 (xCas9: NG (3')), SaCas9 (SaCas9: NNGRRT (3')), SaCas9-KKH (SaCas9-KKH: NNNRRT (3')), AsCas12a (AsCas12a: TTTV (5')), LbCas12a (LbCas12a: TTTV (5')), enAsCas12a (enAsCas12a: TTTV (5')).	SpCas9
`primer_tm`	No	target melting temperature for the screening primers [°C] — follows your polymerase and buffer. In °C. Advanced.
`arm_length`	Yes	homology-arm length on EACH side of the cut, in bp. A protocol decision that follows the delivery method, so there is no default: state what yours needs. The published working range is 100-800 (100-400 nt synthetic, up to ~800 bp cloned). In bp.
`target_end`	Yes	end of the gene to knock out (0-based, exclusive). In bp.
`insert_name`	No	what the insert is called in the protocol and on the order form.
`target_name`	No	what the target is called, so every mark, primer and order line names its subject.	target
`screen_flank`	Yes	how far OUTSIDE the arms the screening primers must bind, in bp. Not decoration: a primer inside the arms amplifies the repair template as readily as the locus, so the assay cannot tell an edited colony from plasmid carry-over. In bp.
`target_start`	Yes	start of the gene to knock out (0-based, inclusive). In bp.
`max_mismatches`	No	mismatch ceiling for the off-target search within this molecule. Advanced.
`replace_target`	No	replace the WHOLE target region with the insert, arms flanking the target — the gene-replacement donor. Off (default): the arms sit on the cut and the target's own sequence is kept on both sides of the insert (a point insertion), so this must be ON to knock one CDS in for another. Empty insert + this = a clean deletion of the target. Advanced.
`restriction_enzymes`	No	cloning enzymes whose recognition site must NOT appear in a spacer. Advanced.

Output Schema

Name	Required	Description
`donor`	Yes	the repair template: both arms with their genomic spans, the insert, and the junctions to sequence across
`marks`	Yes	every span this package names, ready for the map
`order`	Yes	the fragments and oligos to buy, each with the design decision it comes from
`steps`	Yes	the protocol in the order it is done
`chosen`	Yes	the guide the package was built around
`guides`	Yes	every guide inside the target, scored, best first
`record`	Yes	the repair template as a sequence record, so the run leaves the user holding the thing to order
`report`	Yes	the whole package as Markdown — protocol, order form, guides, template, screening and marks — so it survives outside the transcript
`screening`	Yes	the screening PCR: the pair, the two product lengths, and the span they cover
`offTargets`	Yes	the off-target census for the chosen spacer WITHIN this molecule, with the scope stated

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 20, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already tell the agent this is a non-read-only, non-destructive, closed-world design operation. The description adds the composition of the result, which is useful, but says nothing about cost, whether anything is written to the project/notebook, or failure modes; with an output schema present, the return-content list is partly redundant.

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?

One front-loaded sentence opens with the deliverable before listing components, so the key information lands first. The list is long and comma-chained, but given 16 parameters and a multi-part output, the length is largely earned.

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?

For a 16-parameter, nested-object tool with full schema coverage and an output schema, the description conveys the scope of the package adequately and need not explain return values. The remaining gap is routing guidance relative to the narrower CRISPR/design siblings.

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 parameter meaning is already carried by the schema, which sets the baseline at 3. The description only loosely corroborates a few parameters ('guides inside the target', 'real homology arms', 'primers sit OUTSIDE the arms') without adding constraints or formats beyond them.

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 names a specific deliverable — a complete build package for a knockout or knock-in — and enumerates its parts (guides, off-target census, repair template with homology arms, screening PCR, protocol, order fragments, coordinates). It is unambiguous what the tool produces, though it never names a sibling such as crispr_design_guides or design_mutagenesis_primers to sharpen the contrast.

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?

The phrase 'the complete build package ... as one object' implies this is the composite, all-in-one option, but there is no explicit when-to-use/when-not or pointer to the narrower design tools. Call-selection guidance that does exist (empty insert, replace_target on/off) lives in parameter descriptions rather than the description itself.

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?