Jean — Molecular Biology & Genomics

copy_number_read

Read-only

Read an Affymetrix copy-number container (CNCHP/CYCHP/OSCHP/CHP) in this project and say what is in it: the algorithm and array that produced it, its data sets and their graphs, the per-chromosome marker index the file carries, and — for one chromosome — each graph decimated to a summary with its real range.

Input Schema

Name	Required	Description
`end`	No	last base of the region to summarize. Unset is the chromosome's last marker. Given with `start`, the graphs are decimated over that window instead of the whole chromosome: the same thing the panel's Region field does.
`bins`	No	how many buckets to decimate each graph into. The panel uses one per pixel column of its plot; a smaller number here is a coarser summary of the same data.
`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.
`start`	No	first base of the region to summarize, on the selected chromosome. Unset is the chromosome's first marker. Clamped to what the file's markers actually cover, because a locus is a position in the assembly and an array's coverage stops where it stops.
`_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.
`compare`	No	a SECOND copy-number file in this project, by name, to read over the SAME chromosome, the same window and the same buckets — the overlay the canvas draws, as numbers. Its chromosome is matched by LABEL and not by number, because each file states its own numbering, and its graphs are matched by COLUMN NAME, so a file carrying a different set of them reports which it has rather than answering from whatever sits at that position. Unset, nothing of a second file is read.
`_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 read, by name. Unset is the file's FIRST, which is what the panel opens on.
`chromosome`	No	which chromosome's markers to summarize, as THE FILE numbers them. The autosomes are 1-22; which numbers are X and Y is stated by the file's own header (`xChromosome`/`yChromosome`, which both bundled arrays give as 24 and 25) and read from it rather than assumed. Unset is the first the index carries, which is what the panel selects.

Output Schema

Name	Required	Description
`lanes`	Yes	the tracks above drawn as the canvas draws them: one lane per graph over the same window, the bucket min-max envelope with its mean over it, the compared sample's envelope behind it where `compare` named a second file, and the marker lane underneath, because a gap in the probes is not a deletion. Null when no graph was decimated — no chromosome was selected, or none of its markers carried a value
`tracks`	Yes	the selected chromosome decimated: per graph, its fitted range, the bucket minima/maxima/means, and how many markers carried no value
`summary`	Yes	the file in one sentence, generated from this run — the panel's own facts
`compared`	Yes	null unless `compare` named a second file. Otherwise: file, dataSet, chromosomeLabel and chromosomeInThatFile (matched by LABEL, so the number may differ), markersOnChromosome and markersInWindow (ITS markers — a different array covers a chromosome at a different density), bins and binnedOver (the SAME buckets and the same extent as `tracks`, which is what makes the two comparable at a coordinate), and tracks: one entry per graph of the PRIMARY file, each with that graph's buckets in the compared sample, or `absent` naming the column the compared file does not carry. A `refused` field instead of the rest means the comparison could not be made and says why — never an empty list, which would read as the two samples agreeing
`data_sets`	Yes	every data set, with its row count, its columns and which of them are graphs
`provenance`	Yes	the header chain the file states about itself: algorithm, version, array, and the annotation release it was analyzed against
`chromosomes`	Yes	the file's OWN per-chromosome index — start row, marker count and display flag each. This is what makes a chromosome one ranged read rather than a whole-file scan. A CNCHP states it in the data set's parameters and a CYCHP as rows in Chromosomes/Summary; both are read, and `index_source` says which one answered
`index_source`	Yes	where the per-chromosome index above came from, because the two container shapes keep it in different places and a reader comparing two files should not have to guess which

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 23, 2026

addedOutput schema / properties / lanes

Added value: +{
+  "description": "the tracks above drawn as the canvas draws them: one lane per graph over the same window, the bucket min-max envelope with its mean over it, the compared sample's envelope behind it where `compare` named a second file, and the marker lane underneath, because a gap in the probes is not a deletion. Null when no graph was decimated — no chromosome was selected, or none of its markers carried a value",
+  "type": [
+    "string",
+    "null"
+  ]
+}

changedOutput schema / required

Previous value: -[
-  "summary",
-  "provenance",
-  "data_sets",
-  "compared",
-  "chromosomes",
-  "index_source",
-  "tracks"
-]New value: +[
+  "summary",
+  "provenance",
+  "data_sets",
+  "compared",
+  "chromosomes",
+  "index_source",
+  "tracks",
+  "lanes"
+]

First observedOct 20, 2026

TDQS

B3.2/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. The description does add real behavioral context beyond them: graphs are reduced ('decimated') to a summary but carry their 'real range', and only one chromosome is summarized at a time, which signals a lossy, single-chromosome-scoped read. It still says nothing about cost, size of the marker index, or what an empty/absent graph yields.

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 opening with the verb and the file formats, with no filler sentences. It is dense with em-dash appositives that make the payload list harder to parse on first read, but every clause carries information about what is returned.

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?

Nine parameters, nested _subject/_files objects, and an output schema exist; the description correctly focuses on what is read and returns, leaving return structure to the output schema and parameter detail to the 100%-covered schema. For a multi-parameter, zero-required inspection tool the coverage is solid, though it omits any mention of the second-file compare overlay, which is the most behaviorally distinctive parameter.

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 schema already explains file, chromosome, data_set, start/end, bins and compare in detail. The description only restates at a high level that one chromosome is summarized and decimation produces a summary with its real range; it adds no syntax or selection semantics beyond what per-parameter text already provides. Baseline 3 is appropriate.

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?

Names a specific verb ('Read') and a precisely scoped resource (an Affymetrix copy-number container in CNCHP/CYCHP/OSCHP/CHP form) and enumerates what it reports: producing algorithm/array, data sets and graphs, per-chromosome marker index, and a decimated per-chromosome summary. An agent can tell this is an inspection/overview tool rather than an analysis tool, but no sibling (copy_number_regions, copy_number_compare, copy_number_segment) is named to sharpen that distinction.

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

Usage Guidelines2/5

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

The description gives no when-to-use or when-not-to-use guidance and never points at an alternative tool. Nothing tells the agent whether to reach for this versus copy_number_compare (which the `compare` parameter overlaps) or the region/segment tools. The only routing hints, such as refusing to guess when multiple files exist, live in the schema rather than 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 — Molecular Biology & Genomics 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?