What can you do with this server?

This server exposes six G*Power-compatible tools for statistical power analysis (t tests family) over MCP stdio. * Discover tests — list_tests lists all implemented statistical tests with effect-size metric, design, and supported analysis types; describe_test gives one test's G*Power menu title, effect size, extra parameters, and analysis types. * Run power analyses — power_analysis solves for sample size (a priori), achieved power (post hoc), alpha (criterion), detectable effect size (sensitivity), or compromise, returning numeric results (n1, n2, total, power, critical t, df, noncentrality, effect size, warnings) plus a G*Power-style report and an APA sentence. * Handle designs — two-group (via n1/n2 or n with allocation ratio/rule), paired, one-sample, point-biserial, regression-coefficient (with predictors), and generic t (with df); one- or two-tailed. * Convert effect sizes — compute_effect_size turns raw descriptives into standardized effect sizes with seven calculators (independent/paired/one-sample d, dz, f² from R² or partial R², r from d). * Tabulate power curves — power_curve shows power vs. sample size across a range (up to 500 rows). * Report provenance — engine_provenance states engine version, implemented spec, and encoded behavioural findings for trust questions. * Consistent, safe I/O — every tool routes through the same engine as the CLI (outputs match byte-for-byte); all return {"ok": true, ...} or {"ok": false, "error": {...}} on invalid input.

How do I use gpower-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@gpower-mcp How many participants per group for a two-sided t-test with d=0.5, alpha=0.05, power=0.95?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

gpower-mcp

by abdulkadirelaldi

Overview Schema Source Related Servers Discussions Admin

Python

Remote

gpower-rea

t2-indep (two independent means) sample size and power, as G*Power computes them — from a CLI, from an MCP server, or in plain Turkish.

Yapılan katmanlar: ✅ Temel — CLI (gpower-clone, ders sözleşmesi) · ✅ +15 MCP sunucusu (gpower-mcp) · ✅ +10 AI ajanı (MCP üzerinden, Türkçe). Test ailesi: 1) t2-indep (the engine also covers the rest of G*Power's t tests family). Jev (Sistem 1) was not used: the family-selection step is the same LLM restricted to the tools, see agent/eval/REPORT.md.


gate: hidden-vector style N, exact	`gpower-clone` vs every GPower t2-indep reading: 125 / 125* a-priori `N` exact (tests/UYUM-RAPORU.md); all tests and analyses: 225 / 225
differential test	443 G*Power GUI runs; 429 / 429 identical outside F-14 (VALIDATION §0)
evidence ledger	LEDGER.md — `[DOK]`, `[GÖZLEM]`, `[AJAN]`; no `[REA]` (binary) lines: no static analysis was done in this work
hallucination log	HALLUCINATIONS.md — 10 entries, each with the test that caught it
spec	SPEC.md v1.3, acceptance criteria in Gherkin (§6, executable: `tests/test_gherkin_spec.py`)
agent cost	AGENT_COST.md
prompts of both sessions	prompts/
oracle	oracle/ — 141 G*Power t2-indep vectors (CSV) + 900 `statsmodels` vectors
agent evaluation	agent/eval/REPORT.md — 10 / 10 family, parameters and N

Versions and identity


reference program, readings	GPower 3.1.9.6 for macOS* (`GPowerMac_3.1.9.6.zip`, SHA-256 `841390e00110ccdd5201f334af985b54837b9f9b4ffb3151d49e28efb9bb3964`)
reference program named by the course	GPower 3.1.9.7 for Windows*, `GPowerNT.exe` SHA-256 `c63e6a133eb6372932f810c08cc33dc35a06d1ddb658f897bd6c34a754efc812` (from `GPowerWin_3.1.9.7.zip`, SHA-256 `3bb7f1f2478d74ee5ba701ae7f849373cf2b8a11f6b6216c7c6b236db7861199`) — not in this repository (`.gitignore`)
engine / spec	`gpower-rea` 1.3.0, `SPEC.md` v1.3
runtime	Python ≥ 3.10, no third-party dependency for engine and CLI
REA / Ghidra check (brief, "Kurulum")	not performed — see LEDGER.md
demo video (60 s, CLI)	to be added

Install and run

$ pip install -e .                       # engine + gpower-clone + gpower, no dependencies
$ pip install -e ".[mcp,agent,dev]"      # + MCP server, agent, test suite

$ gpower-clone --test t2-indep --mode a-priori --tails 2 --d 0.5 --alpha 0.05 --power 0.95 --ratio 1
{"n1":105,"n2":105,"n_total":210,"actual_power":0.9501,"critical":1.9714,"df":208,"ncp":3.6228}

$ gpower-clone --test t2-indep --mode post-hoc --tails 2 --d 0.5 --alpha 0.05 --n1 40 --n2 40
{"n1":40,"n2":40,"n_total":80,"actual_power":0.5981,"critical":1.9908,"df":78,"ncp":2.2361}

$ gpower-clone --test t2-indep --mode a-priori --tails 2 --d 0.5 --alpha 0.05 --power 0.8 --ratio 1000
{"error":"allocation ratio N2/N1 must be in [0.01, 100], the range G*Power accepts, got 1000.0 (SPEC F-15)"}
$ echo $?
2

$ python -m pytest -q                    # 1500+ tests, incl. every G*Power reading

--test accepts t2-indep and t-paired; the other course labels (anova-oneway, chi2-contingency, multireg-r2) are refused by name. --mode is a-priori or post-hoc; --d (alias --dz), --alpha, --power, --ratio (N2/N1, default 1), --tails (default 2), and for post hoc --n1 --n2. Output is always one JSON line; on invalid input {"error": "..."} and exit code 2.

MCP tool schema

gpower-mcp serves six tools over stdio ({"mcpServers": {"gpower": {"command": "gpower-mcp"}}}). Every tool calls the same engine.solve() as the CLI; tests/test_clone_cli.py::test_cli_and_mcp_give_the_same_output and tests/test_mcp_server.py assert that both give the same numbers for the same input. Inputs (generated from the server's own schema):

`list_tests`

List every statistical test this engine implements, with its effect-size

No inputs.

`describe_test`

Describe one test: its exact G*Power menu title, effect-size metric,

input	type	required	default
`test`	string	yes

`power_analysis`

Run one power analysis and return the full numeric result plus

input	type	required	default
`test`	string	yes
`solve_for`	string ∈ n, power, alpha, effect_size, effect-size, compromise		"n"
`alpha`	number/null		null
`power`	number/null		null
`effect_size`	number/null		null
`tails`	integer		2
`n`	integer/null		null
`n1`	integer/null		null
`n2`	integer/null		null
`allocation_ratio`	number/null		null
`allocation_rule`	string/null		null
`beta_alpha_ratio`	number/null		null
`predictors`	integer/null		null
`df`	number/null		null

`compute_effect_size`

Convert raw descriptive statistics into the standardised effect size a

input	type	required	default
`calculator`	string	yes
`parameters`	object	yes

`power_curve`

Tabulate power against sample size -- useful for showing a user the

input	type	required	default
`test`	string	yes
`alpha`	number	yes
`effect_size`	number	yes
`n_from`	integer	yes
`n_to`	integer	yes
`n_step`	integer		1
`tails`	integer		2
`allocation_ratio`	number/null		null
`predictors`	integer/null		null

`engine_provenance`

Report engine version, the specification it implements, and the

No inputs. Every tool returns {"ok": true, ...}; power_analysis returns {"ok": true, "result": {...}, "report_text": ..., "apa_sentence": ...}, where result has sample_size.{n1,n2,total}, power, critical_t, df, noncentrality, effect_size, warnings[]. On invalid input: {"ok": false, "error": {"type": ..., "message": ...}}.

Attribution

G*Power is the work of Faul, Erdfelder, Lang & Buchner (2007, Behavior Research Methods 39, 175–191; 2009, 41, 1149–1160), distributed free of charge by Heinrich-Heine-Universität Düsseldorf. This repository is not G*Power, is not affiliated with or endorsed by its authors, and does not use its name for the reimplementation (gpower-clone is the course's mandated command name). Cite G*Power for the method.

G*Power is the tool clinical researchers use to answer "how many participants do I need?". It is free and excellent, and it has only a graphical interface: no CLI, no API, nothing scriptable. An AI agent can drive it only by taking screenshots and clicking, which is slow, expensive and silently unreliable.

This repository reverse engineers one of its test families by running the real program — G*Power 3.1.9.6, driven black-box through its own GUI — documents every finding with [GÖZLEM] evidence, reimplements it clean-room, and gives it three interfaces.

Against the real G*Power: 443 recorded runs, 429/429 identical in every printed field outside the one documented region where G*Power itself is inexact, and 225/225 exact a-priori sample sizes. (VALIDATION §0)

$ gpower solve --test indep --alpha 0.05 --power 0.95 --effect-size 0.5
t tests - Means: Difference between two independent means (two groups)

Analysis:          A priori: Compute required sample size
Input Parameters
  Tail(s)                        = 2
  Effect size d                  = 0.5
  alpha err prob                 = 0.05
  Power (1-beta err prob)        = 0.95
  Allocation ratio N2/N1         = 1
Output Parameters
  Noncentrality parameter delta  = 3.6228442
  Critical t                     = 1.9714347
  Df                             = 208
  Sample size group 1            = 105
  Sample size group 2            = 105
  Total sample size              = 210
  Actual power                   = 0.9501287

An a priori power analysis for a two-tailed means: difference between two
independent means (two groups) (d = 0.5, alpha = 0.05, target power = 0.95)
indicated that n1 = 105 and n2 = 105 (total N = 210) is required; the achieved
power at that sample size is 0.9501.

Those are the numbers G*Power prints for that design, to all seven decimals (probe P-01-a).

Install

$ pip install -e .                      # engine + CLI, zero dependencies
$ pip install -e ".[mcp]"               # + MCP server
$ pip install -e ".[mcp,agent]"         # + natural-language agent
$ pip install -e ".[mcp,agent,dev]"     # + test suite (scipy, pytest)

Python 3.10+. The engine and CLI have no third-party runtime dependencies — enforced by a test that blocks numpy/scipy/pandas at import time and then runs the CLI.

The three interfaces, one engine

natural language ──► agent ──► MCP server ──┐
shell / CI ──────────────────► CLI ─────────┼──► engine.solve()
Python ─────────────────────────────────────┘

No arithmetic exists outside the engine, and that is checked rather than promised (ARCHITECTURE.md). The practical payoff: a number the agent reports in prose is byte-reproducible by a grader typing the equivalent gpower command.

1 · CLI — 85-point baseline

$ gpower list                                    # the six tests
$ gpower info point-biserial                     # parameters + spec findings
$ gpower solve -t paired -s power -a .05 -e .6 -n 24 --json
$ gpower solve -t indep -s compromise -e .5 --n1 40 --n2 40 --q 1
$ gpower effect-size -c d-two-independent-means \
      --param mean1=10.4 --param mean2=8.9 --param sd1=3.1 --param sd2=2.8
$ gpower curve -t indep -a .05 -e .5 --n-from 20 --n-to 200 --n-step 20
$ gpower batch -i vectors.csv --expect expected_N --min-match 0.90
$ gpower selftest

Full contract — flags, JSON schema, batch column aliasing, exit codes — in docs/CLI-CONTRACT.md.

2 · MCP server — +15

$ gpower-mcp          # stdio

{ "mcpServers": { "gpower": { "command": "gpower-mcp", "args": [] } } }

Six tools: list_tests, describe_test, power_analysis, compute_effect_size, power_curve, engine_provenance. Each one forwards to the engine and returns its JSON verbatim — asserted with == in tests/test_mcp_server.py, and again over a real stdio subprocess in tests/test_mcp_stdio_e2e.py. Works with both mcp 1.x (FastMCP) and mcp 2.x (MCPServer).

3 · AI agent — +10

$ export ANTHROPIC_API_KEY=...        # or: ant auth login
$ python agent/agent.py "40 kişilik iki grubum var, d=0.6 ile gücüm ne?"

Claude Opus 5.5 over the MCP server. Its system prompt forbids it from stating any number that did not come back from a tool call, and tools/compliance_check.py fails the build if the agent file contains arithmetic at all. The loop is covered by 22 offline tests.

A live run is recorded in agent/transcripts/2026-10-26-unbalanced-a-priori.md: a Turkish question, a model whose only tools were the six MCP tools, five tool calls, and an answer whose every number is reproducible with a gpower command. The run also found a defect in our output (a post-hoc report printed the default allocation ratio instead of the design's) — fixed and locked by a test. (agent.py itself needs an API key the build machine did not have; that run used Claude Code as the harness over the same MCP server — agent/README.md says which is which.)

What was reverse engineered

Sixteen findings. Every G*Power claim is labelled [GÖZLEM], has an evidence file, and is settled by recorded G*Power output — and every one is behaviour the manual does not state:

#	finding	`[GÖZLEM]` status
F-01	the whole family reduces to one `(ν, δ)` pair	derived + observed
F-02	two-sided power keeps the wrong-side tail — at `δ = 0` G*Power prints `α`, not `α/2`	observed
F-03	matched pairs counts pairs, not observations	derived + observed
F-04	point biserial: `δ` uses `√N`, the statistic uses `√(N−2)`	derived + observed
F-05	a balanced total is never odd, even when an odd split suffices (50 % of settings)	observed
F-06	"Actual power" is recomputed — and can be below the requested power	observed, one clause refuted
F-07	the predictor count enters `ν` only, never `δ`	derived + observed
F-08	a negative effect is a direction: power from `\|δ\|`, sign on `δ` and `t` — except in the criterion analysis	refuted → corrected
F-09	unbalanced designs: even totals only, stopping test on the unrounded split — neither pre-registered candidate was right	refuted → corrected
F-10	compromise analysis solves for the critical value	derived + observed
F-11	the equal-n pooling option is an RMS, not a pooled SD	open — the drawer is not reachable by the GUI driver
F-12	no epsilon slack at the boundary (`0.8000014` accepted)	observed
F-13	twelve points SPEC v1.0 did not determine, found by implementing it twice	spec closure
F-14	G*Power itself is inexact below `α ≈ 1e-9` (Internal Math Error) and above `N ≈ 1e7` (picks a design below target)	observed, arbitrated at 50 digits
F-15	the input domain: `r ≤ 0.999999`, `\|ES\| ≥ 1e-5` a priori, `power ≥ α`, `q ∈ [0.01, 100]`, `N ≥ 3` — and a priori may return `N = 2`, which post hoc then refuses	observed
F-16	nineteen points SPEC v1.2 did not determine, found by a second clean-room session — twelve then settled by asking G*Power (e.g. the split is computed in binary double: `66/8.8 → 7 / 59`)	spec closure, 12 rows observed

Read SPEC.md for the specification, docs/EVIDENCE/ for the sixteen evidence files, probes/REA-OBSERVED.md for every recorded reading against the engine, and docs/REA-METHOD.md for the method.

How do you prove the engine is right?

The assignment's question. The short answer this project arrived at:

Agreement between implementations proves a specification is implemented. Only the reference program proves the specification is right.

#	check	result
1	the real G*Power 3.1.9.6, driven through its GUI on 443 inputs	429/429 outside F-14; 225/225 exact a-priori `N`
2	pre-registered predictions, committed before G*Power was run once	26 supported, 2 refuted (F-08, F-09) — kept in the record
3	401 reference vectors, exact integer `N`	401/401
4	independent re-derivation: SciPy + brute-force search, from `SPEC.md`	401/401
5	an implementation by other people (`statsmodels`)	agrees, including the far-tail term of F-02
6	a second implementation of `SPEC.md`, written clean-room in a separate agent session	judged against the same contract and against the G*Power readings (CLEANROOM-PROTOCOL)
7	property tests: monotonicity, minimality, round trips, cross-entry identities	all pass
8	arbitration by 50-digit `mpmath` wherever two answers differ	decides who is right — including against G*Power (F-14)

Check 1 is the one that changed the engine. Before it, checks 3–8 all passed — and the engine still disagreed with G*Power on 32 % of a-priori designs (62 % of unbalanced ones), because SciPy, statsmodels and the first clean room had all implemented the same guessed allocation rule. Observation found that rule wrong, a fine power sweep exposed the real one, and the same campaign found the negative-effect rule, the input domain, a large-ν numerical defect in the engine, and two regions where G*Power is itself inexact.

$ python -m pytest -q                     # 1541 passed, incl. every recorded G*Power reading
$ python tools/rea_report.py              # cases=443 match=404 both_refuse=25 mismatch=14
$ python tools/fit_allocation.py          # F-09: 7 candidate rules vs the readings
$ gpower selftest                         # 401/401 exact N matches (rate 1.0000)
$ python tools/compliance_check.py        # COMPLIANCE: PASS (C-1..C-5)
$ python tools/judge_cleanroom.py         # the second implementation, same contract

Scope

Test family t tests, all six entries, all five analysis types:

test	effect size	a priori	post hoc	criterion	sensitivity	compromise
Means: two independent means	`d`	✅	✅	✅	✅	✅
Means: two dependent means (matched pairs)	`dz`	✅	✅	✅	✅	✅
Means: difference from constant (one sample)	`d`	✅	✅	✅	✅	✅
Correlation: point biserial model	`r`	✅	✅	✅	✅	✅
Linear multiple regression: single coefficient	`f²`	✅	✅	✅	✅	✅
Generic t test	`δ`	—	✅	✅	✅	✅

Plus the "Determine ⇒" effect-size calculators, including both pooling options of F-11.

Other families (F tests, χ² tests, z tests, exact tests) are out of scope by design — one family, done properly, with evidence. Adding a family is a Procedure object and a SPEC.md finding; the CLI, MCP server and agent pick it up with no edit (ARCHITECTURE.md).

Repository map

SPEC.md                      the specification; the clean-room handover artefact
ETHICS.md                    what was analysed, what is not here, and why
PUBLISH.md                   how to verify and publish a release
docs/
  REA-METHOD.md              how the behaviour was established, and its limits
  EVIDENCE/E-001 … E-012     one file per finding: claim, probe, [GÖZLEM] observation
  EVIDENCE/E-013             what the clean-room pass found (5 spec defects)
  EVIDENCE/E-014 … E-016     G*Power's inexact regions; its input domain; round-2 gaps
  CLI-CONTRACT.md            flags, JSON schema, exit codes
  ARCHITECTURE.md            the one-engine rule and how it is enforced
  VALIDATION.md              measured evidence, with the gaps named
  CLEANROOM-PROTOCOL.md      the two-session rule and how to sign it
  SESSION-LOG.md             what is done, what is unsigned
src/gpower_rea/
  numerics.py                Φ, incomplete beta/gamma, central and noncentral t
  procedures.py              six (ν, δ) maps + validation
  engine.py                  THE ENGINE: one power formula, five analysis types
  effectsize.py              the "Determine ⇒" calculators
  report.py                  GUI-style protocol block + APA sentence
  cli.py                     the `gpower` command
  mcp_server.py              six MCP tools
  data/public_vectors.csv    401 generated reference vectors
agent/agent.py               Claude Opus 5.5 over MCP
agent/transcripts/           a recorded live run, natural language -> MCP -> engine
tools/
  gpower_ax.py               drive the G*Power GUI, black box (macOS Accessibility)
  rea_campaign.py            run case sets through G*Power AND the engine; record
  rea_report.py              re-score the engine against every recorded reading
  fit_allocation.py          score candidate F-09 rules against the readings
  stamp_worksheet.py         fill the pre-registered worksheet from the readings
  probe_plan.py              generate the GUI probe worksheet
  harvest.py                 stamp observations into a verdict per finding
  make_vectors.py            regenerate / verify the vector file
  judge_cleanroom.py         hold the independent 2nd implementation to the contract
  probe_spec_gaps.py         probe the 12 regions SPEC.md v1.0 left undetermined
  compliance_check.py        the submission rules, as a machine check
  publish.ps1                verify, commit and push (refuses if the gate fails)
probes/
  observations/*.jsonl       443 raw G*Power 3.1.9.6 readings (never edited)
  REA-OBSERVED.md            the engine against every reading, field by field
  probe_worksheet.{csv,md}   36 pre-registered rows with competing predictions
  REA-RESULTS.md             per-finding verdict of the pre-registration
tests/
  test_numerics.py           accuracy, self-consistency, mpmath arbitration
  test_engine_invariants.py  monotonicity, minimality, round trips, identities
  test_reference_scipy.py    all 401 vectors re-derived independently
  test_reference_statsmodels.py      agreement with a third-party implementation
  test_reference_statsmodels_f05.py  F-05 counter-examples, without our search
  test_allocation_rule_rates.py      the measured rates quoted in F-09
  test_cli.py                the CLI contract
  test_mcp_server.py         MCP tools == engine output
  test_mcp_stdio_e2e.py      the server as a real subprocess over stdio
  test_effectsize.py         both pooling options (F-11)
  test_cleanroom_conformance.py  the 2nd implementation, same contract
  test_spec_f13.py           each of F-13's twelve resolutions
  test_agent_offline.py      the agent loop, driven with a stub client
  test_gpower_observed.py    [GÖZLEM] the engine prints what G*Power printed
  test_compliance.py         the submission rules
cleanroom/
  src/gpower_cleanroom/      the independent 2nd implementation (Session B)
  SPEC-GAPS.md               the 12 gaps it reported against SPEC.md v1.0
  selfcheck.py               its own 56 self-checks
  SPEC.md, INTERFACE.md      exactly what it was allowed to read

Licence and attribution

MIT (LICENSE). This is not G*Power and is not affiliated with or endorsed by its authors. If this contributes to published research, cite G*Power for the method — Faul, Erdfelder, Lang & Buchner (2007) and Faul, Erdfelder, Buchner & Lang (2009). See ETHICS.md.

Available Tools

6 tools

compute_effect_sizeA

Convert raw descriptive statistics into the standardised effect size a test needs.

Calculators: d-two-independent-means mean1, mean2, sd1, sd2 [, equal_n, n1, n2] dz-matched-pairs mean1, mean2, sd1, sd2, correlation dz-from-difference mean_difference, sd_difference d-one-sample mean, reference, sd f2-from-r-squared r_squared f2-from-partial-r-squared partial_r_squared r-from-d-balanced d

Name	Required	Description	Default
`calculator`	Yes
`parameters`	Yes

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses the dispatch model (one calculator selected by name) and the parameter set each calculator consumes, but says nothing about error behaviour for invalid calculator/parameter combinations, unit expectations, or what is returned beyond a standardised effect size.

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 front-loaded purpose sentence followed by a compact per-calculator signature table; each line carries information an agent needs. Minor penalty for a stray line break inside the opening sentence and for the table being the only body content, with no grouping of related calculators.

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

Completeness3/5

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

Given zero annotation coverage, no output schema, and an untyped nested parameter object, the description gives enough to pick a calculator but not enough to call it reliably: types, optionality, mutual exclusivity of equal_n with n1/n2, and failure modes are all absent.

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 0% and `parameters` is a free-form object, so the description must supply everything, and it does supply the full calculator dispatch table with the required keys for each. It still omits value types, whether equal_n is a boolean, and optionality/defaults for n1/n2 and correlation, so it falls short of complete.

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?

States a specific verb and resource: converting raw descriptive statistics into a standardised effect size for a test. The calculator table makes the scope concrete. It does not, however, say how it relates to power_analysis or whether that sibling also derives effect sizes, leaving some overlap ambiguous.

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: 'the effect size a test needs' suggests you call this when you have descriptives but need an effect size before a power calculation. There is no explicit statement of when to use this versus power_analysis, or what to do if an effect size is already known.

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

describe_testB

Describe one test: its exact G*Power menu title, effect-size metric, extra parameters, and which analysis types it supports.

Name	Required	Description	Default
`test`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

No annotations exist, so the description carries the full behavioral burden. It does disclose the returned fields, which is useful, but says nothing about whether this is a pure read, how it behaves for an unknown or misspelled test name (error vs. empty), or whether identifiers are case-sensitive — real risks for a name-keyed lookup with no enum.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that front-loads the verb and resource and then lists the returns. Every clause earns its place with no filler.

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

Completeness3/5

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

With no output schema, the description must convey the return shape — and it does at a high level via four enumerated fields. However, it leaves out how to acquire a valid test identifier and what happens on lookup failure, which are the two things an agent most needs for a single-key lookup tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%: the single required parameter "test" is a bare untyped-in-practice string with no description, no enum, and no example. The description implies it is a test identifier but never gives the accepted form (menu title? slug? key?) or how to obtain valid values, so it does not compensate for the schema gap.

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?

States a specific verb ("Describe") and resource ("one test"), then enumerates exactly what will be returned: menu title, effect-size metric, extra parameters, supported analysis types. This makes it clearly distinguishable from list_tests (one vs. many), though it never names that sibling explicitly.

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 "Describe one test" implies a per-test lookup that follows a listing step, but the description never states when to call this versus list_tests, power_analysis, or compute_effect_size, nor any prerequisite (e.g., that a valid test identifier must come from list_tests first).

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

engine_provenanceA

Report engine version, the specification it implements, and the documented behavioural findings it encodes. Use this when a user asks how trustworthy the numbers are or where they come from.

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description must carry the behavioral load. 'Report' implies a read-only, side-effect-free lookup and the content of the output is sketched, but it never explicitly states there are no side effects, no required auth, or how the findings are formatted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero waste, with the payload description front-loaded and the usage cue following immediately. Nothing could be removed without losing information.

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?

For a simple zero-parameter introspection tool with no output schema, the description adequately covers both what it returns and when to call it. A brief note on the shape of the findings (e.g. structured list vs prose) would make it complete.

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?

The tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate at the argument level and it correctly implies a no-argument call.

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?

States a specific verb ('Report') and enumerates exactly what is returned: engine version, the specification implemented, and documented behavioural findings. It is clearly distinct from siblings like list_tests or compute_effect_size, though it never names them explicitly.

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?

Gives a concrete triggering condition: 'when a user asks how trustworthy the numbers are or where they come from.' That routes the agent well, but there are no exclusions or named alternatives (e.g. describe_test) to fully disambiguate.

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

list_testsA

List every statistical test this engine implements, with its effect-size metric, design (one- or two-group) and supported analysis types.

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior3/5

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

No annotations exist, so the description carries the full burden. "List" signals a read-only, non-mutating operation and the description usefully discloses the per-item payload (effect-size metric, design, analysis types), but says nothing about ordering, pagination, or completeness guarantees.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence that names the action first and the returned fields after. Every clause earns its place; no filler or redundancy.

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 no output schema, the description steps in to describe the item shape (test name, effect-size metric, design, supported analysis types), which is the key information an agent needs. Only the envelope details (ordering, count, format) are left unstated, which is a minor gap for a zero-parameter list tool.

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?

The tool takes zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. No misleading parameter hints are present.

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?

States a specific verb and resource ("List every statistical test this engine implements") and even enumerates the fields returned per item. It implicitly contrasts with describe_test by emphasizing "every," but never names the sibling explicitly.

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: an agent can infer this is a catalog/discovery call to run before describe_test or power_curve. There is no explicit when-to-use statement, no exclusions, and no mention of alternatives.

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

power_analysisA

Run one power analysis and return the full numeric result plus ready-to-paste prose.

solve_for: "n" -> smallest sample size reaching power (a priori) "power" -> achieved power of an explicit design (post hoc) "alpha" -> alpha needed to reach power (criterion) "effect_size" -> smallest detectable effect (sensitivity) "compromise" -> alpha and power implied by beta_alpha_ratio

Supply n1+n2 or n(+allocation_ratio) for the two-group test and n otherwise. predictors applies to ttest-regression-coef; df to ttest-generic.

Name	Required	Default
`n`	No
`df`	No
`n1`	No
`n2`	No
`test`	Yes
`alpha`	No
`power`	No
`tails`	No
`solve_for`	No	n
`predictors`	No
`effect_size`	No
`allocation_rule`	No
`allocation_ratio`	No
`beta_alpha_ratio`	No

TDQS

A3.6/5.0

Behavior3/5

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

No annotations, so the description carries the full disclosure burden. It usefully says the return includes both numbers and ready-to-paste prose, but says nothing about validation behavior (which parameter combinations are invalid for a given test) or what happens when required inputs are missing.

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 one-line purpose, then a dense, well-mapped enumeration of solve_for modes and the minimum input requirements. Every line carries information; the slightly ragged line-wrapping is cosmetic, not bloat.

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?

For a 14-parameter computational tool with no annotations and no output schema, the description covers the core decision surface (solve_for semantics, sample-size input rules) and even previews the return shape. It falls short only on the 'test' value domain and allocation_rule/allocation_ratio disambiguation.

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 0%, so the description must compensate, and it does so well for solve_for, n/n1/n2, predictors and df. However alpha, power, tails, effect_size, allocation_rule vs allocation_ratio (an ambiguity an agent will hit), beta_alpha_ratio and especially the 'test' string domain are left undocumented.

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?

States a specific verb and resource ('Run one power analysis') and says what comes back ('full numeric result plus ready-to-paste prose'). It implicitly separates itself from power_curve and compute_effect_size by framing itself as the single-shot analysis, but never names those siblings.

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?

The solve_for block is effectively a when-to-use table for each mode (a priori, post hoc, criterion, sensitivity, compromise), and it tells the caller when to pass n1+n2 versus n(+allocation_ratio). What's missing is explicit routing against siblings, e.g. 'use power_curve for a range of values'.

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

power_curveB

Tabulate power against sample size -- useful for showing a user the trade-off instead of a single number. Capped at 500 rows.

Name	Required	Description	Default
`n_to`	Yes
`test`	Yes
`alpha`	Yes
`tails`	No
`n_from`	Yes
`n_step`	No
`predictors`	No
`effect_size`	Yes
`allocation_ratio`	No

TDQS

B3.3/5.0

Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose one important trait: results are 'capped at 500 rows', telling the agent output can be truncated. It says nothing about error behavior when the requested n range exceeds the cap, valid values for test, or whether the tabulation errors or silently truncates — gaps that matter for a computation 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?

Two short sentences with no filler, and the core purpose plus the key comparison are front-loaded. The structure is slightly fragmented (mid-sentence line break) but efficient.

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?

A 9-parameter statistical computation with no annotations, no output schema, and zero parameter documentation needs far more from the description than purpose and a row cap. An agent cannot tell what 'test' strings are valid, what effect_size means per test, or how n_step interacts with the 500-row limit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% across 9 parameters, including non-obvious ones like allocation_ratio, predictors, tails, and n_step. The description never mentions any of them; the 500-row cap only indirectly hints that the n_from/n_to/n_step range controls output volume. It does not compensate for the coverage gap.

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?

States a specific verb and resource ('Tabulate power against sample size') and clarifies the output shape ('instead of a single number'), which implicitly separates it from the sibling power_analysis. It could name power_analysis explicitly, but the function is unambiguous.

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?

'Useful for showing a user the trade-off instead of a single number' gives a clear selection criterion relative to a single-value power calculation. There is no explicit naming of alternatives or when-not-to-use conditions, keeping it short of a 5.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesv1.1.0Oct 26, 2026
- First observedcompute_effect_size
- First observeddescribe_test
- First observedengine_provenance
- First observedlist_tests
- First observedpower_analysis
- First observedpower_curve

Deploy Server

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

TDQS

A3.7/5.0

Scored 2026-10-26 14:40 across 6 tools

Disambiguation5/5

Each tool has a clearly distinct role: discovery, single-test description, single power analysis, power curve tabulation, effect-size conversion, and provenance reporting. The only near-overlap is between power_analysis and power_curve, but their descriptions make the single-result versus tabulated trade-off explicit.

Naming Consistency4/5

All names use snake_case consistently, and most are readable verb-led or domain-specific names. However, the set mixes verb_noun names like list_tests and compute_effect_size with noun phrases like power_curve and engine_provenance, so it is not a strict uniform pattern.

Tool Count5/5

Six tools is well within the ideal range for a focused statistical power engine. Each tool covers a distinct part of the workflow, and none feels redundant or padded.

Completeness5/5

The surface covers test discovery, detailed test metadata, power analysis across all solve-for modes, power curves, effect-size conversion, and provenance. For a G*Power-style engine, this is a complete lifecycle with no obvious dead ends.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

Related MCP Connectors

SmartMoney77A
com.smartmoney77
SmartMoney77 MCP v0.6.0 — 14 public tools that turn financial questions into exact numbers and citable links. New: historical_investment_return and compare_investments, which compute "what if I had invested" results from real yearly price data. Also compound interest, FIRE number, credit-card payoff, emergency fund, inflation, latte factor, investment fees, cost of waiting, plus discovery/deep-link/share-pack tools for a catalog of calculators in 6 languages (he/en/ar/es/pt/in). Public, no login. Endpoint: https://smartmoney77.com/mcp
Finance
141
https://smartmoney77.com/mcp
ML RefereeB
com.mlreferee.api
Independent statistical feature evaluation for machine learning and forecasting. ML Referee tests up to 1,000 candidate features in one run against a declared baseline, helping researchers and AI agents decide which inputs to pursue, which bounded feature repairs merit further testing, and where more evidence is needed—without a separate ablation run for every feature. Use the MCP tools to discover input schemas, check access and credits, preflight a dataset, obtain a quote, submit an authorized evaluation, and retrieve structured results and reports. Results are scoped to the submitted evidence and evaluation design; they do not guarantee future model performance. Invite-only beta with manual approval. Public tool discovery requires no authentication; account and evaluation tools require OAuth through approved client connections and available evaluation credits. Connect directly to https://api.mlreferee.com/mcp. Website: https://mlreferee.com Request beta access: https://mlreferee.com/beta Agent setup and documentation: https://mlreferee.com/agents
AI & Machine Learning
261
https://api.mlreferee.com/mcp
climbpast
io.github.archievi
Read and edit GA4, Search Console and Google Tag Manager from any MCP client. 29 tools.
Marketing Search Data Platforms
1
https://climbpast.com/api/mcp
Algenta MCP ServerA
io.github.thyn-ai
Governed data discovery, exact queries, decisions, simulations, and runtime utilities over MCP.
Data Platforms Search RAG Systems
14021
https://api.algenta.ai/mcp

Related MCP Servers

rigor-mcp
Research & Data Developer Tools
mrnh
A
license
A
quality
A
maintenance
Provides verified statistical inference and hypothesis testing tools, including t-tests, effect sizes, power analysis, and multiple comparisons correction, with assumption checks and citations.
Updated 2 months ago (2026-09-17 07:59 UTC)
37
35 PyPI
1
MIT
genpark-hypothesis-welch-tofficial
AI & Machine Learning Research & Data
Alpha-Park
A
license
Not graded
quality
B
maintenance
Enables statistical A/B testing by computing Welch's two-sample t-test, Satterthwaite degrees of freedom, and two-tailed p-values, alongside time-series forecasting, anomaly detection, regression, and PCA through MCP tools.
Updated a month ago (2026-09-28 03:18 UTC)
7
MIT
PairedLab MCP Server
Research & Data Education & Learning Tools
kurtulusyuksel
A
license
Not graded
quality
B
maintenance
Enables a-priori and post-hoc power analyses for paired-samples t-tests through a stdio MCP tool, returning required sample size, actual power, critical value, degrees of freedom, and noncentrality parameter.
Updated 19 days ago (2026-10-18 20:56 UTC)
MIT
eval-sample-size
Testing & QA Tools AI & Machine Learning
fayehall-ai
A
license
A
quality
C
maintenance
Enables agents to calculate how many evaluation test cases are needed to trust model comparisons, find the smallest detectable accuracy gap, and assess paired or unpaired results using McNemar and two-proportion statistical tests.
Updated 14 days ago (2026-10-23 18:55 UTC)
4
MIT

gpower-rea

Versions and identity

Install and run

MCP tool schema

list_tests

describe_test

power_analysis

compute_effect_size

power_curve

engine_provenance

Attribution

Install

The three interfaces, one engine

1 · CLI — 85-point baseline

2 · MCP server — +15

3 · AI agent — +10

What was reverse engineered

How do you prove the engine is right?

Scope

Repository map

Licence and attribution

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

genpark-hypothesis-welch-tofficial

`list_tests`

`describe_test`

`power_analysis`

`compute_effect_size`

`power_curve`

`engine_provenance`