Jean by Melad Labs

design_genetic_circuit

Read-only

Design a genetic circuit that computes: give it a logic function and it synthesizes a NOR/NOT netlist, assigns real characterized repressor gates from a Cello UCF library, predicts the dynamic range between ON and OFF, and emits the construct's DNA.

Input Schema

Name	Required	Description	Default
`logic`	No	the function the circuit computes: a named gate (NOT, AND, OR, NAND, NOR, XOR, XNOR, AND3, OR3, MAJORITY-3), or a truth table as one bit per input combination with the first input most significant (AND is `0001`).	AND
`_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.
`groups`	No	comma-separated repressor groups the search may draw on. Narrowing this is how a large search is made tractable — and how a gate you cannot obtain is kept out of the design. Advanced.
`library`	No	the characterized gate library to build from. Each was measured in one host under one growth condition, and the prediction inherits both.	Eco1C1G1T1
`sensors`	No	comma-separated input sensors the search may use. Leave unset to consider every sensor the library carries. Advanced.
`_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.
`reporters`	No	comma-separated output reporters the search may use. Leave unset to consider all of them. Advanced.
`max_assignments`	No	refuse rather than search past this many assignments. A ceiling, not a target: the search is EXHAUSTIVE, so it is never sampled — a best-of-some reported as a best-of-all is a wrong answer rather than a slow one. Advanced.

Output Schema

Name	Required	Description
`dna`	Yes	the construct broken into devices and parts, each with its own sequence, plus the solved device order and every placement constraint the library declares
`score`	Yes	the predicted dynamic range: the dimmest ON output divided by the brightest OFF, across every input combination
`curves`	Yes	each assigned gate's transfer function sampled around its own midpoint, with this design's operating points on it — one curve per physical gate that won a row, so a group won by two gates gives two curves
`netlist`	Yes	the NOR/NOT netlist synthesized from the logic function, and the table it was checked to compute
`sequence`	Yes	the construct's DNA, the devices concatenated in the order the library's placement rules put them
`toxicity`	Yes	what the circuit costs the host: relative growth per truth-table row, the worst row, and per-gate detail — plus how many of the assigned gates actually carried a measured growth table, because a growth of 1.00 means something different when nothing was measured
`libraries`	Yes	every shipped library with its host, growth conditions and gate count, so a caller can choose one
`placement`	Yes	how the device order was solved: the arrangement including the library's landing pads, how many of its placement constraints bound this construct, and any rule whose operator is not implemented
`assignment`	Yes	which sensors, gate groups and reporters the winning design uses
`truthTable`	Yes	every input combination with its logic values and its analog levels in RPU, per node
`explanation`	Yes	the derivation chain: conclusion, interpretation, earned cautions and machinery, generated from this run
`curvesFigure`	Yes	the curves above drawn as the panel draws them: one panel per gate, all on the same log-log axes, the response as a line and this design's operating points on it, ON in bluish green and OFF in vermillion

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 23, 2026

addedOutput schema / properties / curvesFigure

Added value: +{
+  "description": "the curves above drawn as the panel draws them: one panel per gate, all on the same log-log axes, the response as a line and this design's operating points on it, ON in bluish green and OFF in vermillion",
+  "type": [
+    "string",
+    "null"
+  ]
+}

changedOutput schema / required

Previous value: -[
-  "score",
-  "assignment",
-  "truthTable",
-  "sequence",
-  "dna",
-  "placement",
-  "toxicity",
-  "curves",
-  "netlist",
-  "explanation",
-  "libraries"
-]New value: +[
+  "score",
+  "assignment",
+  "truthTable",
+  "sequence",
+  "dna",
+  "placement",
+  "toxicity",
+  "curves",
+  "curvesFigure",
+  "netlist",
+  "explanation",
+  "libraries"
+]

First observedOct 20, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: that this is a multi-stage pipeline (netlist synthesis → gate assignment → dynamic-range prediction → DNA emission) using real characterized parts rather than idealized ones. It omits cost/runtime characteristics of the exhaustive search, which only the max_assignments parameter reveals.

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?

A single front-loaded sentence with the action first and the pipeline stages following in execution order; every clause carries information. It is dense and long-ish but not padded, and no sentence is wasted.

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 an eight-parameter, nested-schema tool with an output schema and full annotation coverage, the description supplies the conceptual model (what a logic function becomes) and notes that predictions inherit the library's host and growth condition. What is missing is routing guidance relative to sibling design/verification tools, which matters in this large toolset.

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 all eight parameters are already documented in detail, including the truth-table encoding for `logic` and the exhaustive-search semantics of `max_assignments`. The description only echoes `logic` and `library` at a high level and says nothing about groups, sensors, reporters, or _subject/_files, so it adds little beyond the schema. Baseline 3 applies.

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 and resource ("Design a genetic circuit") and enumerates the concrete sub-steps it performs: NOR/NOT netlist synthesis, repressor-gate assignment from a Cello UCF library, dynamic-range prediction, and DNA output. An agent can tell this is a circuit-design tool, not a primer/assembly tool. It does not, however, name any sibling (e.g. assemble_operon, verify_construct, design_codehop) to disambiguate in a 200-tool namespace.

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?

Usage is implied by "give it a logic function" — the agent infers it is for logic-gate circuit construction from a boolean specification. There is no explicit when-to-use, when-not-to-use, or alternative named, and no statement of prerequisites such as needing a characterized library or which outputs should be routed to verify_construct afterwards.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Jean by Melad Labs 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?