openreadout

Official

Overview Schema Source Related Servers Discussions Admin

openreadout_check

Idempotent

Verify lab-instrument file integrity, flagging truncation, missing planes or bad blocks, or compare two files for metadata, geometry and pixel differences.

Instructions

Integrity check: ok plus findings (severity, code, message) for truncation, missing planes or parts, bad blocks; a plate folder reports missing files per well; a file still being written reports acquisition_in_progress. against compares two files instead (e.g. a source and its export): metadata differences, geometry, channels, per-plane hashes or max |difference| within tolerance. report=true builds a privacy-reviewed diagnostic bundle for the maintainers (no data values; free text only with include_text) with the issue_url to file it at.

Input Schema

TableJSON Schema

Name	Required	Description
`file`	Yes	Absolute or working-directory-relative path to the file or data-set directory.
`image`	No	against: only this image index (in both files).
`ignore`	No	against: JSON pointers (into openreadout_info output) to leave out of the metadata diff; `*` matches one segment.
`output`	No	report: also write the bundle to this new local file. Default: only return it.
`report`	No	Build a privacy-reviewed diagnostic bundle for the maintainers instead (for a file that is refused, fails, or is not validated).
`select`	No	against: plane selection strings such as `c=0`, `z=2-5`, `t=0,3`. A second file holding only the selected planes (an export with the same selection) is matched to them in order.
`strict`	No	true: refuse (an error with exit_code 6 and a hint) values this file's assurance does not validate. Default: the server's setting (OPENREADOUT_STRICT; off).
`against`	No	Compare with this second file instead (e.g. an OME-TIFF export of `file`): metadata differences, geometry, channels, physical sizes and per-plane hashes.
`no_pixels`	No	against: metadata and geometry only, no pixels.
`tolerance`	No	against: largest absolute sample difference that still counts as equal. Default: bit-identical planes (same xxh3-128).
`include_text`	No	report: keep free text from the file (sample, image and channel names, comments); the path and personal data are still replaced. Default false: only with the user's consent.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 3, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations give readOnlyHint=false/destructiveHint=false/idempotent, and the description usefully explains the write behavior behind that (report writes a bundle to `output`, default only returns it) plus refusal semantics (strict → error with exit_code 6 and a hint). It also discloses the privacy model (no data values; free text only with include_text). Missing: any note on cost/runtime for large plates.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose, which is good, but the rest is a single run-on paragraph of semicolon-joined clauses mixing three modes. Every clause carries information, yet the mode boundaries are hard to parse on a first read.

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?

An output schema exists so return values need not be described, and the description still covers all three operating modes, privacy handling, and the refusal path. Adequate for an 11-parameter tool; only the sibling-tool boundary is left implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it groups parameters by mode (plain check vs `against` vs `report`), explains what `against` compares (metadata, geometry, channels, per-plane hashes or max |difference| within tolerance), and clarifies `strict` and `include_text` behavior beyond the schema text.

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 ('Integrity check: ok plus findings ... for truncation, missing planes or parts, bad blocks') and explicitly names the two alternate modes (against-comparison, report bundle). An agent can distinguish it from openreadout_info/export/analyze without opening the schema.

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?

The 'instead' framing tells the agent when to switch modes: pass `against` to compare two files, pass `report=true` for a refused/failed file. It also notes acquisition_in_progress for in-progress writes. It does not, however, explicitly contrast with sibling tools like openreadout_info or openreadout_export, which the comparison mode overlaps with.

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

This server cannot be deployed