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. Three grains: tests ranks candidate falsification tests against the beliefs a discovery ledger holds, each with the posterior its two outcomes would leave, by gain and separately by gain per unit cost; measurements says what n readings of a normal quantity would teach, and how many it takes to reach a target; trials says the same for a rate held as a Beta. A gain is what a result would settle whichever way it lands — never evidence that a hypothesis is true, which stays with the ledger's e-values.

Input Schema

TableJSON 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

TableJSON 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

A4.6/5.0
Behavior5/5

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

Beyond the safety annotations, the description provides deep, sophisticated behavioral context by explaining the underlying mechanism—Lindley's expected information gain—and clarifying the philosophical difference between 'gain' and 'evidence that a hypothesis is true.' This is crucial for a Bayesian modeling tool.

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?

The description is highly dense and technical, which is appropriate given the complexity of the topic (Bayesian design). It is structured well by introducing the core concept first, followed by the three specific application 'grains'.

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

Completeness5/5

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

Given the extreme complexity of the domain and the 100% schema coverage, the description successfully provides the necessary high-level context (why, when, and how the three modes differ) that allows an agent to utilize the tool correctly in a decision-making flow.

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?

Although the schema coverage is 100%, the description adds significant conceptual meaning by linking the parameters to the three grains. For instance, it explains that the 'tests' grain ranks against a discovery ledger's beliefs, providing essential context for how the inputs relate to the overall function.

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?

The description provides an exceptionally specific purpose: to rank candidate experiments based on Lindley's expected information gain (what running them would TEACH). It immediately details the three distinct modes—'tests', 'measurements', and 'trials'—which precisely scopes the tool.

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?

It clearly guides the user on the conceptual use of the three modes: 'tests' for falsification against beliefs, 'measurements' for sizing a run of readings, and 'trials' for sizing a rate run. This distinguishes between the tool's capabilities effectively.

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