Skip to main content
Glama

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. Values the analysis left undefined are counted and reported, never plotted as zero. NO GENOME BUILD IS ASSUMED: positions are the file's own, because these files name an annotation release and not an assembly.

Input Schema

NameRequiredDescriptionDefault
endNolast 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.
binsNohow 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.
fileNowhich 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.
startNofirst 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.
_filesNoThe 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.
compareNoa 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.
_subjectNoThe 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_setNowhich data set to read, by name. Unset is the file's FIRST, which is what the panel opens on.
chromosomeNowhich 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

NameRequiredDescriptionDefault
lanesYesthe 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
tracksYesthe selected chromosome decimated: per graph, its fitted range, the bucket minima/maxima/means, and how many markers carried no value
summaryYesthe file in one sentence, generated from this run — the panel's own facts
comparedYesnull 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_setsYesevery data set, with its row count, its columns and which of them are graphs
provenanceYesthe header chain the file states about itself: algorithm, version, array, and the annotation release it was analyzed against
chromosomesYesthe 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_sourceYeswhere 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.

  1. Changed2 schema fields changed
    • 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"
      +]
  2. First observed

TDQS

A3.9/5.0
Behavior5/5

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

Annotations already declare readOnly, non-destructive, and closed-world behavior, but the description adds substantial non-obvious context: undefined values are counted and reported rather than plotted as zero, no genome build is assumed, positions are the file's own, and it refuses rather than guessing when multiple files exist and none is specified.

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?

The description is three dense sentences with the purpose front-loaded and no obvious filler. The middle sentence packs several details and is somewhat complex, but every part contributes useful 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?

Given the output schema and annotations, the description covers what is read, what is reported, and key caveats such as undefined values and no assumed genome build. It is largely complete for invocation, though it lacks explicit sibling routing guidance for such a feature-rich copy-number tool.

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%, and the schema already documents start, end, bins, chromosome, compare, and other parameter semantics in detail. The description adds only general scope such as 'for one chromosome' and decimated summaries, not meaningfully beyond what the schema provides.

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?

The description states a specific verb ('Read') and resource ('Affymetrix copy-number container') and enumerates the outputs: algorithm, array, data sets, graphs, marker index, and decimated summaries. It is clear what the tool does, but it does not explicitly differentiate itself from sibling copy-number tools such as copy_number_compare or copy_number_regions.

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 implied: read a container and summarize one chromosome, and the file parameter notes behavior when unset. However, the description never states when to choose this tool over sibling tools or gives explicit exclusions, so the agent must infer routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources