Skip to main content
Glama

Jean — Molecular Biology & Genomics

estimate_effect_size

Read-only

The effect a power calculation needs, measured from a pilot instead of guessed: two groups of one measurement in a table, standardized as Hedges' g (default), Cohen's d or Glass's Δ with its noncentral-t confidence interval (effectsize 1.0.3, reproduced), and the two-sample t design sized at the estimate and at the interval limit nearest zero.

Input Schema

NameRequiredDescriptionDefault
ciNothe confidence level of the interval.
groupNothe group compared. Left unset, the second group to appear.
powerNosize the design for this power; leave empty to estimate the effect only.
tableYesthe pilot: a header row, then one row per observation. Tab- or comma-separated.
valueYesthe column holding the measurement.
_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.
groupsNoone group label per data row, in row order, separated by commas, spaces or new lines, when the table has no group column.
pairedNothe two groups are the same subjects measured twice, paired by row order within each group. Only applies when estimator is hedges_g or cohens_d.
_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.
subtractNoa column subtracted from the measurement row by row before anything else: a reference gene's Ct (giving delta-Ct), a baseline.
estimatorNoHedges' g corrects Cohen's d's small-sample bias by the exact J(df); Cohen's d is the uncorrected standardized difference; Glass's Δ standardizes by the reference group's SD alone, for when the treatment changes the spread. Values: hedges_g (Hedges' g), cohens_d (Cohen's d), glass_delta (Glass's Δ).hedges_g
pooled_sdNostandardize by the pooled SD (Student). Off averages the two variances, with Welch's df. Only applies when estimator is hedges_g or cohens_d.
referenceNothe group it is compared against (the control). Left unset, the first group to appear.
sig_levelNoα for the sizing. Advanced.
alternativeNoa two-sided interval, or one bounded on one side. Values: two.sided (Two-sided), less (Less (upper bound only)), greater (Greater (lower bound only)). Advanced.two.sided
group_columnNothe column naming each row's group. Or give `groups`.

Output Schema

NameRequiredDescriptionDefault
designYeswhat calculate_power takes: the t test's d (`effect`), and the raw `difference` and `sd` for t_raw
groupsYesevery group in the table: n, mean and SD of the measurement
sizingYespwr.t.test's sample size at the estimate and at the limit nearest zero, when power was given
estimateYesthe standardized effect
intervalYesthe confidence interval: level, low, high

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / estimator / description
      Previous value: -"Hedges' g corrects Cohen's d's small-sample bias by the exact J(df); Cohen's d is the uncorrected standardised difference; Glass's Δ standardises by the reference group's SD alone, for when the treatment changes the spread. Values: hedges_g (Hedges' g), cohens_d (Cohen's d), glass_delta (Glass's Δ)."New value: +"Hedges' g corrects Cohen's d's small-sample bias by the exact J(df); Cohen's d is the uncorrected standardized difference; Glass's Δ standardizes by the reference group's SD alone, for when the treatment changes the spread. Values: hedges_g (Hedges' g), cohens_d (Cohen's d), glass_delta (Glass's Δ)."
    • changedInput schema / properties / pooled_sd / description
      Previous value: -"standardise by the pooled SD (Student). Off averages the two variances, with Welch's df. Only applies when estimator is hedges_g or cohens_d."New value: +"standardize by the pooled SD (Student). Off averages the two variances, with Welch's df. Only applies when estimator is hedges_g or cohens_d."
    • changedOutput schema / properties / estimate / description
      Previous value: -"the standardised effect"New value: +"the standardized effect"
  2. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already establish this is a safe, closed-world read, so the description's job is to add computational behavior — and it does, disclosing the estimator implementations (exact J(df) bias correction for Hedges' g, reference-group SD for Glass's Δ), noncentral-t confidence intervals reproduced from effectsize 1.0.3, and the detail that the design is sized at the interval limit nearest zero. Those are non-obvious behaviors an agent cannot get from the schema. It does not discuss failure modes for malformed tables or missing group columns, which is the remaining gap.

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?

Length is reasonable, but the entire definition is one long run-on sentence dense with parentheticals, which makes it hard to scan. The core idea is front-loaded, yet the estimator list and confidence-interval mechanics crowd the same sentence as the purpose statement. Splitting purpose, estimators, and sizing behavior into separate clauses would cost nothing and gain clarity.

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?

With 16 parameters, a nested _subject object, and an output schema (so return values need not be described), the description covers the essential workflow: pilot table, measurement column, grouping, estimator choice, and optional design sizing. Given the output schema exists, the omission of output shape is fine. It could say more about how the table/group_column versus groups parameters interact, but the schema handles that.

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 parameter descriptions are already rich (the estimator enum spells out all three formulas, group/reference defaults are documented), so the schema carries most of the semantic load. The description reinforces the estimator family and explains why the interval matters for sizing, but adds little per-parameter meaning beyond what the schema states. 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?

The opening clause names a specific operation on a specific resource: estimate an effect size from a pilot table, standardized as Hedges' g / Cohen's d / Glass's Δ, with a confidence interval and an optional design sizing. It implicitly separates itself from power-calculation siblings by positioning itself as the source of the effect size that a power calculation consumes. It stops short of naming calculate_power or calculate_rnaseq_power explicitly, so the sibling boundary is inferred rather than stated.

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?

"Measured from a pilot instead of guessed" gives a clear trigger condition: you have pilot measurements and need an empirical effect size before sizing a study. The phrase about sizing "the two-sample t design at the estimate and at the interval limit nearest zero" tells the agent it can also produce a design sizing. There is no explicit when-not guidance or named alternative tool for the pure power-calculation step.

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