Skip to main content
Glama

jean — Molecular Biology & Genomics

summarize_rows

Read-only

Reduce a whole TABLE column to one number — the largest band, the median guide score, the spread of a set of melting temperatures. This is what makes a CROSS-ROW check expressible: check_rows can only assert the same thing of every row, so "the largest fragment is at least twice the smallest" needed two summaries and a comparison and had nowhere to come from. Name a group_field and it summarizes each group instead of the whole table (the mean product size per template), emitting a table a gate can then check group by group; pick a pairwise operation and it relates two columns of the same rows.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
trimNothe fraction to drop from EACH end before averaging, 0-0.5. datamash's own bound: 0.5 keeps only the middle value. Only applies when operation is trimmean.
fieldNowhich field of each row to reduce (e.g. `size`, `score`). Leave empty when the rows are plain numbers; a tuple row is indexed by number, so `0` is the first column.
itemsYesthe rows to summarize. Wire a json/list output (bands, guides, assays, amplicons).
labelNowhat this summary IS, in your words. It becomes the message the run reports.
_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.
_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.
operationNowhich summary to take. The vocabulary is GNU datamash's, so a number here is the number `datamash <op>` gives for the same column. The last four relate TWO columns and need a `second_field`. Values: sum (sum), min (minimum), max (maximum), absmin (smallest by magnitude), absmax (largest by magnitude), range (range (max − min)), count (count of values), first (first value), last (last value), mode (most common value), antimode (least common value), unique (the distinct values, sorted), collapse (every value, in order), countunique (count of distinct values), mean (mean), geomean (geometric mean), harmmean (harmonic mean), trimmean (trimmed mean), median (median), q1 (lower quartile), q3 (upper quartile), iqr (interquartile range), perc (percentile), pstdev (standard deviation (population)), sstdev (standard deviation (sample)), pvar (variance (population)), svar (variance (sample)), ms (mean square), rms (root mean square), mad (median absolute deviation, scaled), madraw (median absolute deviation, unscaled), sskew (skewness (sample)), pskew (skewness (population)), skurt (excess kurtosis (sample)), pkurt (excess kurtosis (population)), jarque (Jarque–Bera normality p-value), dpo (D'Agostino–Pearson normality p-value), scov (covariance (sample)), pcov (covariance (population)), spearson (Pearson correlation (sample)), ppearson (Pearson correlation (population)).max
percentileNowhich percentile to take, 0–100. In %. Only applies when operation is perc.
group_fieldNosplit the rows by this field first and summarize each group: `template` on a multiplex screen, `strand` on a guide table. Leave empty to summarize the whole table.
second_fieldNothe second column for the pairwise operations, the one this field is related TO (e.g. `gc` against `size`). Only applies when operation is scov or pcov or spearson or ppearson.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
usedYeshow many of those rows actually carried a number. Lower than `count` means the column has gaps, and the summary says so rather than implying it read them all
countYeshow many rows went into it: a summary of three bands and a summary of thirty are different claims
valueYesthe summary itself. Wire it into a gate's `value` or its `against`; with a `group_field` this is the first group's value, and `groups` is the table you want
groupsYesone row per group (`{ group, value, count, used }`) when a `group_field` is set. Wire it into `check_rows` to gate every group at once
numberYesthe same answer as a number, so it can drive a numeric port directly. Absent for the text summaries (`first`, `unique`, …)
messageYeswhat was summarized, in words
groupCountYeshow many distinct groups the split found. Absent when nothing was grouped — an ungrouped summary has no group count, and a 0 would read as one

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description usefully adds that a grouped summary emits a table a downstream gate can check group-by-group, but omits error behavior, empty/tuple row handling, and any limits beyond what the schema notes.

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?

The core operation is front-loaded, but the middle sentence is discursive ('had nowhere to come from') and reads like motivation rather than instruction. The grouped/pairwise modes are tacked on as a long semicolon-chained clause, reducing scannability.

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 10-parameter tool with an output schema, the description covers whole-table, grouped, and pairwise modes, which are the key mode distinctions an agent needs. It leaves output shape and `label`/`trim`/`percentile` conditional coupling to the schema, which is acceptable given 100% coverage and a defined output schema.

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 enum fully documents every operation, so the schema does the heavy lifting. The description only adds conceptual framing around `group_field` and pairwise operations, which is already spelled out in the schema; baseline 3 is correct.

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+resource ('reduce a whole TABLE column to one number') with concrete examples (largest band, median guide score, melting temperature spread). It explicitly positions itself against the sibling `check_rows`, explaining what that tool cannot do, so an agent can distinguish them without opening 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?

Names the alternative (`check_rows`) and the condition that selects this tool, and gives a second usage mode via `group_field` with a concrete example (mean product size per template). It does not enumerate when NOT to use it or cover other aggregation-adjacent siblings like `filter_items` or `check_value`, so it falls short of full when/when-not coverage.

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