Skip to main content
Glama

power_analysis

Determine required sample size to detect an effect, or compute statistical power and detectable effect from a given sample size for t-tests and proportion comparisons.

Instructions

power_analysis —— 统计推断组 · 功效分析/样本量计算(工具 27,v1.1.0 新增)。

回答两类问题:「要检出效应量,需要多少样本」与「给定样本量能检出多大效应 / 实际功效多少」。 纯封闭公式计算(statsmodels.stats.power 精确非中心 t / 正态近似),零 LLM、确定性输出。

docstring = agent 使用说明书,与 statlab_mcp/docs/design/10_power_analysis.md 同步维护。

参数: scenario (str): one_sample_t(单样本/配对 t,n=总样本)/ two_sample_t(独立两样本 t,n=每组样本量)/ two_proportions(两独立比例,n=每组样本量) effect_size (float|None): Cohen's d(仅 t 系场景);与 n 至少提供一个;必须 >0 的有限数 n (int|None): 样本量;与 effect_size 至少提供一个;必须是 >=2 的整数 p1 (float|None), p2 (float|None): 两个总体比例 ∈(0,1),仅 two_proportions 场景且须成对; 工具内部换算 Cohen's h = 2·arcsin√p₁ − 2·arcsin√p₂ 并随 result/summary 报告 alpha (float, 0.05): 显著性水平 ∈(0,1) power_target (float, 0.80): 目标功效(求 n 时使用)∈(0,1) alternative (str, "two_sided"): two_sided / less / greater

模式决策表(任务书钉死): 只给效应侧 → mode="solve_n"(求 n_required_exact 与 n_recommended=向上取整) 只给 n → mode="detect_effect"(可检出标准化效应) 都给 → mode="verify"(返回实际 power 验算结果) 都不给 → E1001 中文报错

返回: 成功 {"status":"ok","result":{...},"summary":"..."}; result 含 scenario/n_each/n_total 及各模式专属字段;两比例场景另报 cohens_h。 局限声明(固定附在 summary 末尾):功效计算依赖效应量假设,实际效应量未知时结论仅供参考。

示例: power_analysis("two_sample_t", effect_size=0.5) # 经典配置 → 64/组 power_analysis("one_sample_t", n=34) # 反查可检出的 d power_analysis("two_proportions", p1=0.50, p2=0.80, n=100) # verify 实际功效

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nNo
p1No
p2No
alphaNo
scenarioYes
alternativeNotwo_sided
effect_sizeNo
power_targetNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv1.2.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations present, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It states that computation is deterministic, uses exact noncentral t/normal approximations via statsmodels, defines all three modes, documents the E1001 error condition, and discloses the fixed limitation disclaimer appended to the summary.

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 long but well organized and front-loaded with purpose and usage context. Most sentences add value; only minor maintenance metadata like tool version and docstring sync status could be trimmed without hurting an agent's ability to select and invoke the tool.

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 tool has 8 parameters, no output schema, and no annotations, the description is exceptionally complete. It covers parameter constraints, mode selection, return structure, error behavior, and limitations, with examples that illustrate realistic calls.

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

Parameters5/5

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

Input schema coverage is 0%, so the description must fully explain the parameters, and it does. Every parameter is documented with types, defaults, constraints, per-scenario meaning, and the Cohen's h conversion for two-proportion scenarios, plus examples showing parameter combinations.

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 clearly states the tool is for power analysis and sample size calculation, and it specifies the two exact questions it answers. It adds scenario details (one_sample_t, two_sample_t, two_proportions) and a mode decision table, so it is easy to distinguish from related statistical tools.

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 description gives clear context for when to use the tool: whenever the user asks how many samples are needed or what effect/power is achievable with a given n. It also provides a precise mode decision table based on which parameters are supplied, though it does not explicitly name sibling tools that should be used instead.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/good-boy4069/statlab-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server