Skip to main content
Glama

jean — Molecular Biology & Genomics

copy_number_compare

Read-only

Join two Affymetrix copy-number samples' own calls and report which events they share and which only one of them carries: for every pair, the chromosome both files resolved to, the kind, the bases they overlap and their reciprocal overlap; and separately each sample's unshared calls. Kind is part of the match, so a gain in one sample and a loss in the other at one locus are reported as two unshared calls rather than as agreement. Chromosomes only one file indexes are listed apart and are NOT reported as differences: nothing about them was compared. NO OVERLAP THRESHOLD IS APPLIED — every pair comes back with its numbers, and which agreement counts as agreement is a laboratory's judgement.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fileNowhich copy-number file in this project is the first sample, by name. Unset, it is the project's only one — and it refuses rather than guessing when there is more than one.
_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.
compareYeswhich copy-number file in this project is the second sample, by name — the same parameter copy_number_read.compare takes. Required: there is no default second sample, and a file compared with itself answers one question twice.
_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 of the first file to scan, by name. Unset is the file's FIRST, which is what the panel opens on.
min_basesNoignore any call spanning fewer bases than this, on BOTH sides. Default 0, for the same reason as min_markers. Note a single-marker call spans 0 bases.
min_markersNoignore any call shorter than this many markers, on BOTH sides. The default counts everything either 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.
compare_data_setNowhich data set of the second file to scan. Unset is that file's FIRST.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
sharedYesone entry per PAIR of overlapping calls of the same kind: chrom (the name BOTH files resolved to, never either file's raw chromosome number), kind, a and b (the two calls, each with its own start, end, marker count and value), overlapBases, and reciprocalOverlap — the SMALLER of the two containment fractions, so a focal call inside a whole-arm one scores low rather than 100%. A call that overlaps several on the other side appears once per pair, which is how the reference application's own overlap table behaves
summaryYeshow many of each sample's own calls are shared and in how many overlapping pairs (a call can overlap several on the other side, so the two differ), how many each carries alone, over how many chromosomes both files index, and which floors were applied
comparedYesthe chromosome names both files index — what this comparison actually covers, so a caller can tell a clean result from a narrow one
provenanceYeswhich two files and data sets answered, how each side’s calls were read (the producer’s own segment calls, or the per-marker state columns), how many calls each side contributed, and the floors applied to both
only_in_fileYesthe first sample’s calls that no call of the same kind in the second sample overlaps, on a chromosome BOTH files index — each with the chromosome name and the call itself. This is the half a reader cannot get by reading two result sets one after the other
only_in_compareYesthe second sample’s calls that no call of the same kind in the first sample overlaps, on a chromosome both files index
unmatched_chromosomesYeschromosomes only one of the two files indexes, each with which side carries it. Their calls were NOT compared and are NOT in only_in_file or only_in_compare: a targeted array that does not carry Y says nothing about Y in the other sample

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds real behavioral value beyond that: a gain in one sample and a loss in the other yields two unshared calls, chromosomes indexed by only one file are listed separately and are not counted as differences, and no overlap threshold is applied. Error/auth behavior is not addressed, but the comparison semantics are unusually well disclosed.

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 purpose and scope lead the paragraph, followed by matching semantics, then the non-comparison caveat, then the no-threshold point. It is dense and long for a single description, but each clause carries information; there is little outright waste other than the slightly verbose phrasing.

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, return-value explanation is a bonus rather than a requirement, and annotations carry the safety profile. The description covers what an agent needs to interpret the comparison result correctly, but leaves the relation to sibling tools (copy_number_findings, copy_number_segment, etc.) unstated, which is the one remaining gap for an 8-parameter 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%, so the schema already explains file, compare, data_set, min_bases, min_markers and compare_data_set in detail. The description does not add per-parameter meaning; its 'NO OVERLAP THRESHOLD IS APPLIED' line reinforces the min_bases/min_markers defaults but nothing beyond the schema. Baseline 3 is appropriate.

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 (join/compare) and resource (two Affymetrix copy-number samples' own calls) and immediately scopes the output to shared vs unshared events. The matching semantics ('kind is part of the match') distinguish it from generic comparison siblings like copy_number_findings or copy_number_regions without needing to open their schemas.

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 clear context for when this tool is the right one: comparing two CNV call sets, with explicit rules for how calls pair and how single-file chromosomes are handled. It does not, however, name an alternative sibling or state when NOT to use it (e.g. when a caller-level tool is wanted), so it stops short of full when/when-not 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