Jean by Melad Labs

copy_number_regions

Read-only

Place an Affymetrix copy-number sample's own calls in ClinGen's curated regions: for each region, which gains, losses or stretches of homozygosity fall in it, at what reciprocal overlap, and how much of the region they cover between them.

Input Schema

Name	Required	Description
`file`	No	which copy-number file in this project, by name. Unset, it is the project's only one — and it refuses rather than guessing when there is more than one.
`build`	No	which assembly's curated region list to place the calls on. Unset is the build THIS FILE states about itself, and the node refuses rather than guessing when it states none — a region is a pair of coordinates, and placing a call on the wrong assembly moves every boundary by hundreds of kilobases with nothing to show it. Values: hg19 (hg19 / GRCh37), hg38 (hg38 / GRCh38).
`_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.
`regions`	No	a BED region file in this project, by name, to check against INSTEAD of ClinGen's curated list — the laboratory's own panel, which is what ChAS calls the CytoRegion file. Unset is ClinGen. A BED line states no dosage score, so with this set every hit comes back with dosage null: the list says where to look and claims nothing about what a change there means. If the file states an assembly on its track line (`track ... db=hg19`) and it is not the build being read, the node refuses rather than moving every boundary by hundreds of kilobases.
`_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.
`data_set`	No	which data set to scan, by name. Unset is the file's FIRST, which is what the panel opens on.
`min_bases`	No	ignore any call spanning fewer bases than this. Default 0, for the same reason as min_markers. Note a single-marker call spans 0 bases.
`min_markers`	No	ignore any call shorter than this many markers. The default counts everything the file called, because a reporting floor belongs to the laboratory and not to this tool — and it is the same floor copy_number_findings applies, so both doors place the same calls.

Output Schema

Name	Required	Description
`regions`	Yes	one entry per curated region containing at least one call: id (the ISCA identifier a report cites), name, cytoband, chrom, start, end (0-based half-open), covered (fraction of the region the calls cover between them, each base counted once, so it never exceeds 1), counts by finding kind, and hits — each with the finding itself, overlapBases, reciprocalOverlap (the SMALLER of the two containment fractions, so a focal call inside a whole-arm region scores low rather than 100%), regionCovered, and dosage/dosageAxis: ClinGen's score and description for the axis that speaks to that call's direction, or null for LOH and mosaic events, which change no copy number
`summary`	Yes	how many curated regions contain a call, out of how many were checked, on which build
`unplaced`	Yes	curated regions ClinGen has NOT placed on this build — it states their location as 'tbd'. They carry id, name, cytoband and their dosage scores but no coordinates, so nothing could be checked against them. They are NOT clean: they are unchecked. Empty on hg19, which places all of them
`provenance`	Yes	which region list answered: its authority, source URL, the curation date the file states, the assembly, and how many regions were placed and unplaced. A cached copy of an authority's table is only interpretable with its version beside it

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 20, 2026

TDQS

A3.5/5.0

Behavior3/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 safety is covered and the bar is lower. The description adds useful computational semantics (reciprocal overlap per region and aggregate region coverage) but says nothing about the refusals the tool performs on ambiguous input, ambiguous build, or build mismatch — those behaviours are only disclosed in the parameter schemas.

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 tight sentence, front-loaded with the verb and resource, and the colon-list of outputs earns its space by telling the agent what the answer looks like. It is dense but not padded; a slightly heavier first clause ("Affymetrix copy-number sample's own calls") is the only friction.

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, yet it usefully summarises them, and with 100% schema coverage the eight parameters are fully documented elsewhere. What remains thin is the set of guard behaviours (refusal on multiple files, on missing or conflicting build), which an agent calling with defaults would benefit from knowing up front.

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 every parameter, including the ClinGen-vs-BED override and the min_markers/min_bases floors, is already documented with unusual care. The description adds no parameter-level meaning beyond what the schema provides, so the 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: place an Affymetrix copy-number sample's own calls into ClinGen's curated regions, and even sketches the per-region result (gains, losses, homozygosity stretches, reciprocal overlap, coverage). It does not, however, name or distinguish itself from the numerous neighbouring copy-number tools (copy_number_findings, copy_number_loh, annotate_region, browse_region), so the agent still has to infer the boundary itself.

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 only implied: the description makes clear this is the tool that overlaps a sample's calls with curated regions, but it never states when to choose it over copy_number_findings or copy_number_loh, nor any prerequisites such as requiring a loaded Affymetrix file. The richer routing information (ClinGen is the default, a BED file may be substituted) lives in the schema, not the description.

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?