Jean by Melad Labs

design_barcodes

Design a set of NGS sample-index barcodes with a guaranteed minimum distance, and report what that set actually corrects — substitutions, or indels too (DNABarcodes).

Input Schema

Name	Required	Description	Default
`seed`	No	PRNG seed for a stochastic search: the same seed always gives the same set. Only applies when heuristic is sampling or ashlock.
`_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.
`length`	No	barcode length in bases. In bp.
`metric`	No	error model. A set correcting one substitution may correct zero indels, so this choice is the design, not a display option. Values: hamming (Hamming (substitutions)), seqlev (Sequence-Levenshtein (indels)), levenshtein (Levenshtein), phaseshift (Phaseshift).	seqlev
`_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.
`filter_gc`	No	keep only balanced-GC barcodes (suppressed for length ≤ 3). Advanced.
`heuristic`	No	set-construction strategy. Values: conway (Conway (greedy)), clique (Clique), sampling (Sampling), ashlock (Ashlock).	conway
`iterations`	No	random restarts of the Conway closure (sampling) or generations of the evolutionary search (ashlock); DNABarcodes' default. Only applies when heuristic is sampling or ashlock.
`population`	No	chromosomes carried per Ashlock generation; DNABarcodes' default. Only applies when heuristic is ashlock.
`min_distance`	No	required minimum distance between any two barcodes — this is what buys the error correction.
`filter_triplets`	No	reject barcodes containing a homotriplet (AAA…). Advanced.
`filter_self_complementary`	No	reject barcodes that are their own reverse complement. Advanced.

Output Schema

Name	Required	Description
`count`	Yes	how many barcodes the search actually found
`analysis`	Yes	the set's properties under EVERY metric, not just the design one
`barcodes`	Yes	the designed set
`warnings`	Yes	what the search had to say
`guarantee`	Yes	correctable / detectable errors under the design metric

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 23, 2026

addedInput schema / properties / filter_self_complementary

Added value: +{
+  "default": true,
+  "description": "reject barcodes that are their own reverse complement. Advanced.",
+  "type": "boolean"
+}

addedInput schema / properties / iterations

Added value: +{
+  "default": 100,
+  "description": "random restarts of the Conway closure (sampling) or generations of the evolutionary search (ashlock); DNABarcodes' default. Only applies when heuristic is sampling or ashlock.",
+  "minimum": 1,
+  "type": "number"
+}

addedInput schema / properties / population

Added value: +{
+  "default": 200,
+  "description": "chromosomes carried per Ashlock generation; DNABarcodes' default. Only applies when heuristic is ashlock.",
+  "minimum": 2,
+  "type": "number"
+}

addedInput schema / properties / seed

Added value: +{
+  "default": 1,
+  "description": "PRNG seed for a stochastic search: the same seed always gives the same set. Only applies when heuristic is sampling or ashlock.",
+  "type": "number"
+}

First observedOct 20, 2026

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare destructiveHint=false and openWorldHint=false, and an output schema covers the return values. The description adds one useful behavioral fact beyond that — the result reports whether the set corrects substitutions only or indels too — plus DNABarcodes provenance, but says nothing about runtime cost or how the stochastic heuristics behave.

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 reporting guarantee second; no filler. Slightly dense for a 12-parameter tool, but every clause carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 12 parameters, nested _subject/_files objects and multiple heuristic strategies, one sentence leaves the agent without any picture of the design→audit→export workflow or of default behavior trade-offs. The 100% schema coverage and output schema compensate substantially, so it is adequate rather than inadequate.

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 coverage is 100%, so the baseline is 3. The description reinforces two parameters conceptually ('guaranteed minimum distance' → min_distance, 'what that set corrects' → metric) but says nothing about seed, heuristic, iterations, population, or the three filters, all of which the schema already documents.

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 set of NGS sample-index barcodes') plus the defining constraint ('guaranteed minimum distance') and the reportable property ('what that set actually corrects'). It never names its obvious siblings (audit_barcodes, export_barcodes, design_free_codes), so an agent must infer the boundary rather than read it.

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?

There is no explicit when-to-use or when-not-to-use guidance; the closest signal is the clause about the design reporting which error types are corrected. Nothing routes the agent between this and audit_barcodes (validation) or export_barcodes (output), which are the natural downstream steps of the same workflow.

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?