Jean by Melad Labs

enzyme_collection

Read-only

Resolve one of your saved enzyme collections to the enzyme names in it, so a later step can scan, digest or design with 'my Golden Gate set' by name instead of whatever happens to be selected. Names the collection, says which of its enzymes the cut catalog can resolve and which it cannot, and — when a record is open — how many times each one cuts it. Left unnamed it answers for the collection that is currently active, and says that is what it did.

Input Schema

Name	Required	Description
`name`	No	the collection to resolve, by the name it has in the Enzyme Collections panel. Left unset, the active collection is used; with none active, the whole catalog is in scope and this says so rather than returning an empty set.
`_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.
`_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.

Output Schema

Name	Required	Description
`count`	Yes	how many enzymes resolved — branch on this rather than counting the array
`census`	Yes	what this collection does to the open record, counted once: bases scanned, whether the scan wrapped the origin, names asked and resolved, total cuts, and how many enzymes cut it once, twice or more. Absent when nothing is open. This is the collection panel's own reading, so the sentence the door returns and the numbers it returns cannot disagree
`cutting`	Yes	per enzyme, how many times it cuts the OPEN record — absent when nothing is open, because a cut count with no molecule behind it is a number nobody asked for
`enzymes`	Yes	the enzyme names in the collection, ready to wire into any tool's `enzymes` parameter — the resolvable ones only, so a downstream digest never refuses on a name this step already knew was unusable
`available`	Yes	every collection you have, by name, with its size and whether it is the active one — so a run that named the wrong collection can say what the right names were
`collection`	Yes	the collection this answered for, or 'the whole catalog' when nothing is scoped
`unresolved`	Yes	names in the collection that the bundled cut catalog does not carry, usually a custom enzyme defined in the panel or a supplier spelling. Reported rather than dropped: a set that silently shrinks is the reason a digest comes back short
`singleCutters`	Yes	the enzymes cutting the open record exactly once — the ones a linearization or a directional clone can use. Empty when nothing is open

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 23, 2026

addedOutput schema / properties / census

Added value: +{
+  "description": "what this collection does to the open record, counted once: bases scanned, whether the scan wrapped the origin, names asked and resolved, total cuts, and how many enzymes cut it once, twice or more. Absent when nothing is open. This is the collection panel's own reading, so the sentence the door returns and the numbers it returns cannot disagree"
+}

changedOutput schema / required

Previous value: -[
-  "enzymes",
-  "collection",
-  "count",
-  "unresolved",
-  "cutting",
-  "singleCutters",
-  "available"
-]New value: +[
+  "enzymes",
+  "collection",
+  "count",
+  "unresolved",
+  "census",
+  "cutting",
+  "singleCutters",
+  "available"
+]

First observedOct 20, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly, non-destructive, closed-world behavior, and the description adds genuinely new context: which enzymes the catalog can and cannot resolve, that cut counts appear only when a record is open, and that an unnamed call falls back to the active collection and reports having done so. It does not cover failure behavior for an unknown collection name.

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?

Three dense sentences, front-loaded with the core action, with no filler. The closing clause about saying which collection it used is slightly wordy but carries real 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?

With an output schema present, the description need not explain return values, and it still covers the important edge cases: unnamed name, no active collection, and record-open cut counts. Only error behavior for a nonexistent collection is unaddressed.

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 all three parameters are already documented, including the name fallback and the _subject record-shape guidance. The description restates the default-collection behavior and adds the notion that record context affects the cut counts, but gives no additional syntax or selection detail beyond the schema.

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?

States a specific verb and resource (resolve a saved enzyme collection to its enzyme names) plus what the result contains: catalog-resolvable vs unresolvable enzymes and per-enzyme cut counts when a record is open. This clearly separates it from save_enzyme_collection, enzyme_cut_counts and get_selection.

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

Usage Guidelines4/5

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

Gives a concrete usage context: so a later scan, digest or design step can refer to 'my Golden Gate set' by name rather than the incidental current selection. It does not explicitly name alternatives (save_enzyme_collection, enzyme_cut_counts) or state when not to use it, so it stops short of full routing guidance.

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?