Jean by Melad Labs

audit_barcodes

Read-only

Check an index set you ALREADY have, rather than designing a new one: the minimum distance between any two, how many errors that guarantees correcting, the full distance matrices, and — optionally — the subset that survives pruning to a stricter error budget. This is the question asked of a set inherited from a kit or a previous experiment.

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.
`metric`	No	error model to audit against — a set safe under substitutions may be unsafe under indels. Values: hamming (Hamming (substitutions)), seqlev (Sequence-Levenshtein (indels)), levenshtein (Levenshtein).	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.
`barcodes`	Yes	the index sequences to audit.
`prune_to_errors`	No	also report the subset that would survive pruning to a free code correcting this many errors. 0 = do not prune. Advanced.
`required_distance`	No	the minimum distance the set is supposed to have — the audit says whether it does.

Output Schema

Name	Required	Description
`kept`	Yes	the barcodes surviving `prune_to_errors` (the whole set when pruning is off)
`audit`	Yes	the verdict: the set's real minimum distance, what it guarantees, and every pair that falls short
`dropped`	Yes	how many the prune removed
`analysis`	Yes	per-metric analysis of the whole set
`matrices`	Yes	the pairwise distance matrix under each metric
`statistics`	Yes	the whole-set statistics the four charts above are drawn from, which a min-distance figure hides: GC mean, spread and range, Shannon entropy per cycle, the fraction reading each base at each cycle, groups sharing a prefix in the first cycles read, duplicates, and the per-metric distance distributions
`distanceMap`	Yes	the pairwise distance matrix under the chosen metric, as a heatmap
`gcHistogram`	Yes	how many barcodes sit at each GC percentage
`baseComposition`	Yes	the fraction of the set reading each base at each cycle
`distanceHistogram`	Yes	how many PAIRS sit at each distance under the chosen metric: the shape behind the minimum
`neighbourHistogram`	Yes	how many BARCODES have each nearest-neighbour distance: where the weak links are

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 23, 2026

addedOutput schema / properties / baseComposition

Added value: +{
+  "description": "the fraction of the set reading each base at each cycle",
+  "properties": {
+    "mark": {
+      "enum": [
+        "line",
+        "bar",
+        "point"
+      ],
+      "type": "string"
+    },
+    "rules": {
+      "items": {
+        "properties": {
+          "label": {
+            "type": "string"
+          },
+          "y": {
+            "type": "number"
+          }
+        },
+        "required": [
+          "y",
+          "label"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "series": {
+      "items": {
+        "properties": {
+          "name": {
+            "type": "string"
+          },
+          "y": {
+            "items": {
+              "type": [
+                "number",
+                "null"
+              ]
+            },
+            "type": "array"
+          }
+        },
+        "required": [
+          "name",
+          "y"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "title": {
+      "type": "string"
+    },
+    "x": {
+      "items": {
+        "type": "number"
+      },
+      "type": "array"
+    },
+    "xLabel": {
+      "type": "string"
+    },
+    "yLabel": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "x",
+    "series",
+    "xLabel",
+    "yLabel"
+  ],
+  "type": [
+    "object",
+    "null"
+  ]
+}

addedOutput schema / properties / distanceHistogram

Added value: +{
+  "description": "how many PAIRS sit at each distance under the chosen metric: the shape behind the minimum",
+  "properties": {
+    "mark": {
+      "enum": [
+        "line",
+        "bar",
+        "point"
+      ],
+      "type": "string"
+    },
+    "rules": {
+      "items": {
+        "properties": {
+          "label": {
+            "type": "string"
+          },
+          "y": {
+            "type": "number"
+          }
+        },
+        "required": [
+          "y",
+          "label"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "series": {
+      "items": {
+        "properties": {
+          "name": {
+            "type": "string"
+          },
+          "y": {
+            "items": {
+              "type": [
+                "number",
+                "null"
+              ]
+            },
+            "type": "array"
+          }
+        },
+        "required": [
+          "name",
+          "y"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "title": {
+      "type": "string"
+    },
+    "x": {
+      "items": {
+        "type": "number"
+      },
+      "type": "array"
+    },
+    "xLabel": {
+      "type": "string"
+    },
+    "yLabel": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "x",
+    "series",
+    "xLabel",
+    "yLabel"
+  ],
+  "type": [
+    "object",
+    "null"
+  ]
+}

addedOutput schema / properties / gcHistogram

Added value: +{
+  "description": "how many barcodes sit at each GC percentage",
+  "properties": {
+    "mark": {
+      "enum": [
+        "line",
+        "bar",
+        "point"
+      ],
+      "type": "string"
+    },
+    "rules": {
+      "items": {
+        "properties": {
+          "label": {
+            "type": "string"
+          },
+          "y": {
+            "type": "number"
+          }
+        },
+        "required": [
+          "y",
+          "label"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "series": {
+      "items": {
+        "properties": {
+          "name": {
+            "type": "string"
+          },
+          "y": {
+            "items": {
+              "type": [
+                "number",
+                "null"
+              ]
+            },
+            "type": "array"
+          }
+        },
+        "required": [
+          "name",
+          "y"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "title": {
+      "type": "string"
+    },
+    "x": {
+      "items": {
+        "type": "number"
+      },
+      "type": "array"
+    },
+    "xLabel": {
+      "type": "string"
+    },
+    "yLabel": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "x",
+    "series",
+    "xLabel",
+    "yLabel"
+  ],
+  "type": [
+    "object",
+    "null"
+  ]
+}

addedOutput schema / properties / neighbourHistogram

Added value: +{
+  "description": "how many BARCODES have each nearest-neighbour distance: where the weak links are",
+  "properties": {
+    "mark": {
+      "enum": [
+        "line",
+        "bar",
+        "point"
+      ],
+      "type": "string"
+    },
+    "rules": {
+      "items": {
+        "properties": {
+          "label": {
+            "type": "string"
+          },
+          "y": {
+            "type": "number"
+          }
+        },
+        "required": [
+          "y",
+          "label"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "series": {
+      "items": {
+        "properties": {
+          "name": {
+            "type": "string"
+          },
+          "y": {
+            "items": {
+              "type": [
+                "number",
+                "null"
+              ]
+            },
+            "type": "array"
+          }
+        },
+        "required": [
+          "name",
+          "y"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "title": {
+      "type": "string"
+    },
+    "x": {
+      "items": {
+        "type": "number"
+      },
+      "type": "array"
+    },
+    "xLabel": {
+      "type": "string"
+    },
+    "yLabel": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "x",
+    "series",
+    "xLabel",
+    "yLabel"
+  ],
+  "type": [
+    "object",
+    "null"
+  ]
+}

addedOutput schema / properties / statistics

Added value: +{
+  "description": "the whole-set statistics the four charts above are drawn from, which a min-distance figure hides: GC mean, spread and range, Shannon entropy per cycle, the fraction reading each base at each cycle, groups sharing a prefix in the first cycles read, duplicates, and the per-metric distance distributions"
+}

changedOutput schema / required

Previous value: -[
-  "audit",
-  "analysis",
-  "matrices",
-  "distanceMap",
-  "kept",
-  "dropped"
-]New value: +[
+  "audit",
+  "analysis",
+  "matrices",
+  "distanceMap",
+  "distanceHistogram",
+  "neighbourHistogram",
+  "gcHistogram",
+  "baseComposition",
+  "statistics",
+  "kept",
+  "dropped"
+]

First observedOct 20, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare this as a non-destructive, closed-world read-only operation, so the safety profile is clear. The description adds meaningful behavioral context: it reports minimum pairwise distance, guaranteed error correction, full distance matrices, and optionally the surviving subset after pruning. It does not discuss performance or computational cost, but that is not essential for this read-only audit.

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?

The description is two sentences and front-loads the key distinction: check an existing set rather than design a new one. Every clause adds useful information about the audit outputs or the optional pruning behavior, with no filler.

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

Completeness5/5

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

Given the presence of an output schema, the description does not need to enumerate return fields, and it still summarizes the main outputs. It also provides the key usage context and distinguishes the tool from its design siblings. Nothing critical is missing for an agent to decide when and how to call it.

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 input schema already explains barcodes, metric, required_distance, prune_to_errors, _subject, and _files in detail. The description adds conceptual framing around auditing an inherited set and pruning to a stricter error budget, but it does not map those ideas to specific parameter names or add syntax beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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, 'Check,' applied to a clearly defined resource: an existing index set. It immediately distinguishes the task from designing a new set by naming the alternative and explaining that this is for sets inherited from kits or previous experiments. The listed outputs (minimum distance, error correction, distance matrices, pruning subset) make the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says to use this tool when you already have an index set rather than designing a new one, which routes the agent away from design_barcodes/design_free_codes. The inherited-kit/previous-experiment framing gives a concrete usage context. No important when-not guidance is missing.

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?