jean — Molecular Biology & Genomics

domesticate_part

Silently recode the internal Type-IIS sites inside a part's coding sequence so the part can be used in a Golden Gate assembly — same protein, no recognition site. Only occurrences the given CDS covers can be fixed this way; any outside it are reported untouched rather than skipped quietly, because a site in a promoter needs a different answer.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`table`	No	the codon-usage table to guide the synonymous choice, BY NAME, as the Codon Usage panel lists it. This is the way to pass a table: it resolves against the tables loaded in this project, so the numbers come from one someone built or fetched. Leave unset and the active table is used.
`_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	the Type-IIS enzyme whose sites must go.	BsaI
`cds_end`	Yes	0-based end of the coding sequence (exclusive).
`_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 part to domesticate — wire a record, name a library document, or leave unset to use the open record.
`cds_start`	Yes	0-based start of the coding sequence within the part.
`table_tsv`	No	ONLY for a table you are pasting yourself, measured elsewhere — prefer `table`, which names one this project already has. Do NOT write a table out from memory: codon frequencies are measured data, and a typed one is indistinguishable from a real one in the result. TSV: codon<TAB>count. Advanced.
`cds_strand`	No	1 for the top strand, -1 for the bottom. Values: 1 (Top strand), -1 (Bottom strand).

Output Schema

TableJSON Schema

Name	Required	Description
`fixes`	Yes	one line per synonymous swap, as the engine logs it
`sequence`	Yes	the part with every reachable internal site recoded
`fixedCount`	Yes	how many internal occurrences were actually fixed
`outsideCds`	Yes	internal sites the CDS does NOT cover — left untouched, and yours to solve another way

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 20, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations (readOnlyHint=false, destructiveHint=false) tell the agent this writes but is non-destructive; the description adds meaningful context the annotations don't carry: the change is silent (same protein), only CDS-covered occurrences are fixed, and out-of-range sites are reported untouched rather than quietly skipped. It stops short of saying whether the record is mutated in place or a new sequence is returned.

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 sentences, front-loaded with the action and result, then the scope caveat. No filler or restatement of the name; every clause carries information.

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 nine-parameter mutating tool with an output schema (so return values needn't be described), the description covers what is changed, what is preserved, and the key limitation. Only the in-place-versus-new-sequence behavior is left unstated, a minor gap given the schema richness.

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?

With 100% schema description coverage, the schema already documents all nine parameters, so the baseline is 3. The description reinforces the meaning of the CDS bounds ('only occurrences the given CDS covers') and the enzyme scope (Type-IIS), but adds no syntax or format detail beyond the schema.

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?

States a specific verb (recode/domesticate) and resource (internal Type-IIS sites within a part's coding sequence), plus the outcome (Golden Gate compatibility, silent/same protein). It implicitly scopes itself apart from broader restriction-site tools by limiting work to the CDS, but it never names a sibling such as scrub_restriction_sites or check_golden_gate_parts to route the agent explicitly.

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 'so the part can be used in a Golden Gate assembly' implies the context, and the boundary about sites outside the CDS needing 'a different answer' hints at scope limits, but there is no explicit when-to-use versus when-to-use-something-else guidance. The agent must infer which sibling handles non-CDS or non-Type-IIS cases.

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?