Skip to main content
Glama

Jean — Molecular Biology & Genomics

check_rows

Read-only

A QC gate over a TABLE: assert something about every row at once (every band inside a size window, no guide above an off-target score, at least three assays under a penalty).

Input Schema

NameRequiredDescriptionDefault
maxNoupper bound, inclusive. Only applies when operator is between.
minNolower bound, inclusive. Only applies when operator is between.
setNothe values the field must be one of (or none of). Only applies when operator is in or not_in.
textNothe text the field must contain. Only applies when operator is contains.
countNoN, for the counted requirements. Only applies when require is at_least or at_most or exactly.
fieldNowhich field of each row to test (e.g. `size`, `score`). Leave empty when the rows are plain numbers.
itemsYesthe rows to check. Wire a json/list output (bands, guides, assays, amplicons).
labelNowhat this gate is checking, in your words. It becomes the message when it fails.
valueNothe value to compare against. Only applies when operator is == or != or > or >= or < or <=.
_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.
recordNooptional: the record this gate is guarding. It comes back out of `record` when the check passes, so the gate sits in the middle of a chain.
requireNowhat must hold across the table. Values: all (every row), any (at least one row), none (no row), at_least (at least N rows), at_most (at most N rows), exactly (exactly N rows).all
_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.
operatorNohow each row is compared. Values: == (equals), != (does not equal), > (greater than), >= (at least), < (less than), <= (at most), between (between (inclusive)), in (is one of), not_in (is none of), contains (contains text), is_true (is true), not_empty (is not empty).>=
report_onlyNoreport the verdict instead of stopping the run: wire `passed` (or `failed`) into another step's condition to choose a branch.

Output Schema

NameRequiredDescriptionDefault
failedYesthe opposite verdict, so the ELSE arm of a branch needs no extra step. Only meaningful with `report_only` on
passedYeswhether the requirement held. As a gate this is true whenever it is read downstream; with `report_only` on it is the real verdict, for driving a branch
recordYesthe guarded record, unchanged. Wire it into the next node's $subject to make that step conditional
matchedYeshow many rows met the per-row condition
messageYeswhat was checked, in words
offendersYesthe rows that did NOT meet it: what to look at when the gate fails

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/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. The description adds that this is a QC gate asserting over all rows, but it does not disclose the default stop-the-run behavior on failure, which appears only in the report_only parameter description, nor does it mention record chaining.

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?

One front-loaded sentence with no filler. The parenthetical examples earn their place by illustrating row-wise assertions, though the list is slightly run-on.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is complex (15 parameters, nested objects) and has an output schema, so return values need not be explained. However, the description omits workflow-relevant behavior such as default failure handling and record pass-through, leaving that to the schema and annotations.

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%, with clear descriptions for all 15 parameters including operator/require enums and nested _subject. The description adds no parameter-level detail beyond the schema, so the 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?

States a specific verb ('QC gate', 'assert') and resource ('a TABLE', 'every row at once'), with concrete examples such as bands in a size window and guides above an off-target score. It implicitly distinguishes table-wide checks from single-row checks, but does not name any sibling tool such as check_value or check_invariants.

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?

No explicit when-to-use/when-not-to-use guidance or named alternatives are given. The parenthetical examples imply typical QC scenarios, but routing between this and sibling checkers is left to inference.

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