Skip to main content
Glama

CovaSyn Chemistry Tools

covadoe_design_power

Planning-time statistical power from a design's REAL model matrix — no data needed.

Builds the design and takes `ncp = effect_size² / (X'X)⁻¹_jj`, so it is correct for centre
points, axial points and unbalanced designs — unlike `covadoe_power_analysis`, which assumes
orthogonality and overstates power on a CCD, Box-Behnken or DSD. Use this when planning an
experiment; use `covadoe_post_hoc_power` only once you have measured responses.

`design_type` + `n_factors` builds the design (same generator as `covadoe_create_design`, so the
answer describes the design you would actually get). Common aliases resolve ("full_factorial",
"ccd", "dsd"). Alternatively pass `design`, an explicit coded run matrix, to score a design you
already hold — D/I-optimal, mixture, split-plot or hand-built. `n_runs` / `model_terms` are
forwarded to the generator for the optimal designs.

`model`: "linear" | "interaction" | "quadratic" | "quadratic_no_interaction" (a DSD supports only
the last). `term` names the coefficient — "x1", "x1^2", "x1*x2"; omit it to get power for every
term and group, which differ sharply on the same design. `alpha` is the significance level;
the CCD axial distance is `axial_alpha`, and the two are easy to confuse.

CCD variant: `axial_alpha` defaults to ROTATABLE, (2**n_factors)**0.25 — the design JMP,
Design-Expert and Minitab hand you. Pass a number, or "orthogonal" for the α where Σx² = n_runs
(at 3 factors: main-effect power 0.9400 against the rotatable 0.8846 on the same 17 runs; the
orthogonal α is also the premise of `covadoe_power_analysis`, so on that design the two agree
for a main effect and disagree for every other term). `face` — "circumscribed" (default),
"faced" (star points on the faces, α = 1) or "inscribed"; a bool works, and an unknown value is
rejected rather than quietly treated as circumscribed.

Returns power, power_by_term, power_by_group, df_error, relative_variance ((X'X)⁻¹_jj), the
resolved design_summary (the α and factorial level actually built — read both, an inscribed CCD
always reports α = 1), and `orthogonal_shortcut_power` — what `covadoe_power_analysis` would
have claimed — with its signed error (signed: the shortcut does not always overstate). Returns
`estimable: false` plus a reason when the model cannot be fitted on the design.

Input Schema

NameRequiredDescriptionDefault
faceNo
termNo
alphaNo
modelNoquadratic
designNo
n_runsNo
api_keyNo
n_factorsNo
axial_alphaNo
design_typeNo
effect_sizeNo
model_termsNo
factor_namesNo
n_center_pointsNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden, and it delivers: it states when the result is estimable (returns estimable:false with a reason), that unknown `face` values are rejected rather than silently defaulted to circumscribed, the alpha-vs-axial_alpha confusion risk, and what the return payload contains. This is unusually rich behavioral disclosure for an unannotated 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?

Front-loaded with the core promise, and every paragraph earns its place given the tool's complexity (formulas, CCD variants, aliases). It is dense and long rather than padded, though the parenthetical statistics (e.g. 'main-effect power 0.9400 against the rotatable 0.8846') add more example depth than an agent strictly needs.

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 14-parameter, formula-driven tool with no annotations, the description covers the build-vs-pass-a-design paths, the model/term/alpha semantics, and the CCD special cases. Return values are documented even though an output schema exists, and the estimable:false edge case is noted, so nothing essential is missing.

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?

Schema description coverage is 0% across 14 params, so the description must compensate, and it does: it defines `model` values, `term` syntax ('x1', 'x1^2', 'x1*x2'), `alpha` vs `axial_alpha`, `face` variants, `design_type` aliases, the role of `n_runs`/`model_terms`, and the `effect_size²/(X'X)⁻¹_jj` formula. Only `api_key`, `factor_names`, and `n_center_points` go unaddressed.

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 first sentence states a specific computation ('planning-time statistical power from a design's REAL model matrix') and explicitly names the sibling it differs from ('unlike covadoe_power_analysis, which assumes orthogonality'). An agent can distinguish it from covadoe_power_analysis and covadoe_post_hoc_power without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use routing: 'Use this when planning an experiment; use covadoe_post_hoc_power only once you have measured responses.' It also names the alternative (covadoe_power_analysis) and the condition under which the two agree or diverge, leaving nothing to inference.

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.