Skip to main content
Glama

Jean — Molecular Biology & Genomics

rank_next_tests

Read-only

Rank candidate experiments by what running them would TEACH — Lindley's expected information gain, the drop in uncertainty about a hypothesis expected before anything is run.

Input Schema

NameRequiredDescriptionDefault
nNohow many measurements the run would take. Only applies when mode is measurements.
betaNothe Beta prior's β — failures already believed in. Only applies when mode is trials.
modeNowhich grain of the question: rank candidate tests, size a run of measurements, or size a run of trials. Values: tests (Candidate tests), measurements (Measurements of a mean), trials (Trials of a rate).tests
alphaNothe Beta prior's α — successes already believed in. Only applies when mode is trials.
testsNothe candidates, each `{id, hypothesis, power, alpha}` and optionally `cost`, `reads` (what it would read) and `label`. Only applies when mode is tests.
_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.
ledgerNoa jane.discovery-ledger file, as `run_discovery_programme` returns: its elicited beliefs and the sources its evidence already read. Only applies when mode is tests.
trialsNohow many trials the run would take. Only applies when mode is trials.
beliefsNobelief that each hypothesis is true, as `{hypothesisId: probability}` — given directly, or to override the ledger's. Only applies when mode is tests.
_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.
noise_sdNothe measurement noise, in the same units. Only applies when mode is measurements.
prior_sdNohow uncertain the mean is now, as a standard deviation. Only applies when mode is measurements.
target_bitsNoa gain to reach: the answer says how many measurements it would take. Only applies when mode is measurements.

Output Schema

NameRequiredDescriptionDefault
bestYesthe most informative candidate's id, or the mode's own answer in words
bitsYesthe expected information gain of the top answer, in bits
gainYesthe gain itself: nats, bits, and the entropies before and after. Absent when candidate tests were ranked, where each one carries its own
noteYeswhy a ranking is short or empty, when it is
byCostYesthe same candidates ordered by gain per unit cost, when every one was priced
rankedYesevery ranked candidate: gain, gain per unit cost, the prior it stands on and the posterior each outcome would leave
resultYesthe full answer, with the settings that produced it
beliefsYesthe belief each hypothesis was ranked against, and where it came from
samplesForTargetYeshow many measurements reach `target_bits`; null when no target was set

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already establish readOnly, non-destructive, closed-world behavior, so the description need only add semantics — and it does explain the scoring metric. However it presents the tool purely as ranking candidates, while the schema shows three distinct modes (tests, measurements, trials) where measurements takes prior_sd/noise_sd/target_bits and trials takes alpha/beta — a materially different behavior the description never discloses.

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 compact sentence, front-loaded with the verb and objective, with no padding. The trailing em-dash gloss is slightly awkward and the clause 'the drop in uncertainty about a hypothesis expected before anything is run' takes a moment to parse, but nothing is wasted.

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

Completeness2/5

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

With 13 parameters, nested _subject/_files objects and a three-mode enum, one sentence covering only the default 'tests' mode leaves the measurements and trials branches completely undescribed. The output schema removes the need to explain return values, but the mode-selection story an agent needs is absent.

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 n, beta, alpha, ledger, beliefs, prior_sd and the per-mode scoping. The description adds meaning only for the ranking objective itself, not for any parameter, so the baseline 3 applies.

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?

Names a specific verb (rank) and resource (candidate experiments) and gives the ordering criterion — Lindley's expected information gain, i.e. the expected drop in uncertainty about a hypothesis. That is far more specific than a tautology, though it never distinguishes it from relatives such as rank_strategies, rank_tradeoffs, calculate_power or plan_next_tools.

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?

Implies a pre-experiment context ('expected before anything is run'), which is useful framing, but there is no explicit when-to-use/when-not guidance and no pointer to the sibling ranking or power tools that an agent must choose between.

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