Skip to main content
Glama

Jean — Molecular Biology & Genomics

check_value

Read-only

A QC gate. Compares a wired value against a threshold and PASSES or FAILS the pipeline there — every node downstream of a failed gate is skipped, so a run stops at the first check that does not hold.

Input Schema

NameRequiredDescriptionDefault
maxNoupper bound, inclusive. Only applies when operator is between.
minNolower bound, inclusive. Only applies when operator is between.
setNothe values the checked value must be one of (or none of), compared as text, so `1` matches 1. Only applies when operator is in or not_in.
textNothe text the value must contain. Only applies when operator is contains.
labelNowhat this gate is checking, in your words — it becomes the message when the gate fails (e.g. 'single EcoRI site').
valueYesthe value to check — wire a number (cut count, product size, tip count, Tm) or any output; a list is compared by its length.
_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 straight back out of the `record` output when the check passes, so the gate sits in the middle of a chain.
againstNooptional: compare against another step's value instead of the fixed threshold. When wired, this wins over `threshold`. Only applies when operator is == or != or > or >= or < or <=.
_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 to compare. 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).>=
thresholdNothe value to compare against. Leave it unset and wire `against` instead to compare two steps. Only applies when operator is == or != or > or >= or < or <=.
report_onlyNoreport the verdict instead of stopping the run: wire `passed` (or `failed`) into another step's condition to choose a branch.
against_factorNomultiply the compared-against value by this first, so `at least twice the smallest band` is one gate rather than an arithmetic step. Only applies when operator is == or != or > or >= or < or <=.
against_offsetNothen add this, so `within 50 bp of the predicted size` is expressible against a computed value. Only applies when operator is == or != or > or >= or < or <=.

Output Schema

NameRequiredDescriptionDefault
valueYesthe value that was checked, passed straight through so the gate can sit mid-chain
failedYesthe opposite verdict, so the ELSE arm of a branch needs no extra step. Only meaningful with `report_only` on
passedYeswhether the check held. As a gate this is true whenever it is read downstream, since a failure stops the run; 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 on this check
messageYeswhat was compared, in words

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/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, but they cannot convey the key consequence the description supplies: a failed gate skips every downstream node, so the run stops at the first failing check. That is exactly the kind of control-flow behavior an agent needs and cannot get from annotations. It stops short of mentioning the report-only variant (which the schema covers) or the passed/failed outputs.

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

Conciseness5/5

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

Two sentences, zero filler, and the core identity ('A QC gate') is front-loaded before the mechanics. The em-dash clause carries the consequence without padding.

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?

For a 15-parameter tool with nested objects and an output schema, the description covers the essential semantics (gate, threshold comparison, downstream skip) and can lean on the rich schema and output schema for the rest. The main omission is that the report-only/non-stopping mode is not surfaced in prose, which matters for an agent deciding how to wire the result.

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 every parameter including operator enums, threshold/against precedence, and against_factor/against_offset is already documented. The description only echoes 'wired value' and 'threshold' without adding syntax, format, or precedence meaning beyond the schema, which is the baseline 3 case.

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 names a specific verb (compares) and resource (a wired value against a threshold) and frames the tool as a 'QC gate' that PASSES or FAILS. That is far more specific than the name alone, though it does not explicitly distinguish itself from related siblings such as filter_items, check_rows, 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?

Usage is implied rather than stated: an agent can infer 'use this to gate a pipeline on a value' from the QC-gate framing and the downstream-skip behavior. There is no explicit when-to-use, when-not-to-use, or named alternative (e.g., when to use report_only branching instead of hard-stopping), so guidance stays at the implied level.

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