Jean by Melad Labs

simulate_rnaseq_power

Read-only

Power and FDR for a two-group RNA-seq experiment by SIMULATION (PROPER 1.44.0): whole experiments drawn from a real pilot (Cheung, Gilad, Bottomly, MAQC, or a sequencing depth), each run through edgeR's exact test at every sample size. Reports power stratified by expression, the FDR actually achieved, true and false calls, and power at other depths; reproducible from its seed, value for value against R.

Input Schema

Name	Required	Description	Default
`seed`	No	the seed; round i uses seed + i, as PROPER does. Advanced.
`genes`	No	genes in the simulated experiment.
`pilot`	No	where each gene's baseline expression comes from: one of PROPER's pilots, a sequencing depth applied to aggregated human expression, or one constant. Values: cheung (Cheung (unrelated people, large dispersion)), gilad (Gilad (human liver, moderate)), bottomly (Bottomly (inbred mice, small)), maqc (MAQC (technical replicates)), depth (Sequencing depth), constant (One constant).	cheung
`_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.
`cutoff`	No	the cut-off a gene is called at.
`rounds`	No	simulated experiments. PROPER's own default is 100; each is a full edgeR run at every sample size, so time grows with it.
`strata`	No	stratum break points; unset, PROPER's: 0, 10, 20, 40 … 1280, ∞ for expression. Advanced.
`target`	No	which DE genes count as worth finding: by \|log fold change\|, or by \|log fold change\| / √dispersion. Values: lfc (Log fold change), effectsize (Effect size).	lfc
`call_by`	No	call a gene by its FDR or its raw p-value. Values: fdr (FDR), pval (raw p-value).	fdr
`_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.
`log_mean`	No	the natural-log mean count every gene shares. Only applies when pilot is constant.
`filter_by`	No	drop the lowest expression strata before counting, and recompute BH over what is left. Values: none (Keep every gene), expr (Drop low expression). Advanced.	none
`threshold`	No	the threshold a DE gene's size must exceed to count.
`dispersion`	No	one dispersion (BCV²) for every gene, instead of the pilot's; left unset, the pilot's own. Advanced.
`replicates`	No	replicates per group at each sample size to evaluate.
`stratify_by`	No	stratify the power by expression (mean normalized count) or by dispersion. Values: expr (Expression), dispersion (Dispersion). Advanced.	expr
`second_group`	No	replicates in the second group at each size, when the groups differ. Advanced.
`depth_factors`	No	sequencing depth multipliers to re-weight power to. Advanced.
`dropped_strata`	No	which strata (1-based) to drop. Only applies when filter_by is expr. Advanced.
`log_fold_change`	No	one log fold change for every DE gene; left unset, PROPER's normal(0, 1.5) draws. Advanced.
`changed_fraction`	No	the proportion of genes that are differentially expressed.
`dispersion_pilot`	No	take dispersions from this pilot instead (with a depth or a constant baseline, Cheung's unless set). Advanced.
`reads_per_sample`	No	total reads per sample. Only applies when pilot is depth.

Output Schema

Name	Required	Description
`power`	Yes	marginal power at each sample size
`strata`	Yes	the stratum intervals the stratified readouts are over
`powerSE`	Yes	the Monte-Carlo standard error of each marginal power
`rScript`	Yes	the R that reproduces the run
`summary`	Yes	per sample size: nominal and achieved FDR (or type I error), marginal power, mean true and false discoveries, false discovery cost
`seqDepth`	Yes	marginal power re-weighted to each sequencing depth factor, per sample size
`stratifiedFDR`	Yes	achieved FDR by stratum and sample size
`stratifiedPower`	Yes	power by expression (or dispersion) stratum, one line per sample size

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 21, 2026

TDQS

A4/5.0

Behavior4/5

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

With readOnlyHint/openWorldHint/destructiveHint already covering the safety profile, the description adds real value beyond annotations: seed-based reproducibility ('round i uses seed + i'), value-for-value agreement with R, and a runtime warning that cost grows with rounds. It does not discuss memory or failure modes, hence not a 5.

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?

Front-loaded with the capability and method, then the reported outputs. It is dense but every clause carries information; the only mild bloat is the long parenthetical pilot list that duplicates the schema enum.

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?

For a 23-parameter simulation tool with an output schema and full annotation coverage, the description supplies the missing decision-relevant context: what is simulated, which engine, what is reported, and that results are seed-reproducible. Nothing an agent needs to call it correctly 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% across 23 parameters, so the schema already documents every field including defaults, enums, and 'Advanced.' markers. The description restates the pilot/method context but adds no parameter nuance the schema lacks, so the baseline 3 applies.

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 (power and FDR for a two-group RNA-seq experiment) and pins the method (PROPER 1.44.0 simulation, edgeR exact test at every sample size). This clearly separates it from the analytic siblings compute_rnaseq_power / calculate_power and the design-oriented plan_rnaseq_experiment.

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?

The phrase 'by SIMULATION' implies the context — use this when you want empirical power/FDR rather than an analytic estimate — but the description never names calculate_rnaseq_power or calculate_power, nor states when to prefer one over the other. Usage is inferable, not spelled out.

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

All Jean by Melad Labs 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?