jean — Molecular Biology & Genomics

discover_target_validation

Read-only

Test a hypothesis that a gene drives a phenotype ("gene G regulates IL-2 production") the way POPPER does: each evidence table is one falsification test, an implication of the hypothesis that a gene-level score could contradict (expression in the relevant tissue, association with related disease, interaction with genes annotated to the process). Under the null that G is exchangeable with any gene the tables score, G's p in each table is the share of genes scoring at or beyond it; each p is calibrated to the e-value κ·p^(κ−1), the e-values are multiplied in the order given, and the hypothesis passes when the product exceeds 1/α. The product is a valid e-value only when the tests are independent under the null, so the run also reports the joint p: the product's own share among every gene's product, valid whatever the tables' dependence. Returns every test's score, rank, p, e and running product, the test after which the product first crossed 1/α, and the joint p. Each table is gene<TAB>score with one header line; the gene must be in every table.

Input Schema

TableJSON Schema

Name	Required	Description
`gene`	Yes	the gene under test, as the tables spell it (HGNC symbol for the bundled corpus).
`alpha`	No	the hypothesis passes when the product of e-values exceeds 1/α.
`kappa`	No	κ of the p-to-e calibrator κ·p^(κ−1); POPPER's default is 0.5. Advanced.
`_files`	No	The 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.
`tables`	Yes	the falsification tests in the order to apply them: each `{ name, text, direction }`, where `text` is `gene<TAB>score` with a header line and `direction` is the end of the score the hypothesis predicts, `greater` (default) or `less`.
`_subject`	No	The 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.

Output Schema

TableJSON Schema

Name	Required	Description
`tests`	Yes	each test: score, genes at or beyond, p, e and running product
`jointP`	Yes	the product's share among every gene's product
`result`	Yes	the full result
`combined`	Yes	the product of the calibrated e-values
`rejected`	Yes	whether the product of e-values exceeded 1/α
`nullModel`	Yes	the null, stated with every run

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 20, 2026

TDQS

A3.9/5.0

Behavior5/5

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

Annotations are suppressed (title plus readOnly/openWorld/destructive), but the description adds substantial behavior beyond them: order matters because e-values are multiplied 'in the order given,' the product is valid only under test independence, and a joint p is reported as the dependence-robust fallback. It also states the exact table format and the requirement that the gene appear in every table, giving the agent real operating constraints.

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 purpose is front-loaded in the first clause, but the rest is a dense run-on chain of method details (calibration formula, multiplication, validity caveat, return list) in very long sentences. All content is arguably relevant to such a method-heavy tool, but it is heavy going rather than crisp.

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?

An output schema exists, so return values need not be re-explained, yet the description still enumerates them (score, rank, p, e, running product, first crossing, joint p) for orientation. Given the statistical complexity and 6-parameter nested schema, it covers what an agent needs to invoke correctly, though the independence/calibration caveats could be tightened.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning not in the schema: the gene must be present in every table, table order is semantically significant, and 'direction' is the end of the score the hypothesis predicts. These are genuine usage constraints layered on top of the documented parameters.

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?

It opens with a concrete verb+resource: 'Test a hypothesis that a gene drives a phenotype,' and the POPPER falsification framing gives it a distinct identity from neighbors like validate_gene_trait. It does not name a sibling to differentiate from, so it stops short of 5.

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 only implied by the method description ('the way POPPER does'), with no explicit when-to-use, when-not-to-use, or named alternative such as validate_gene_trait. An agent can infer this is for gene-to-phenotype hypothesis testing with per-table test data, but must supply the selection logic itself.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All jean — Molecular Biology & Genomics tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?