Skip to main content
Glama
Sign In
rigor-mcp

rigor-mcp

by mrnh
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

two_sample_t_test

Read-onlyIdempotent

Test whether two independent samples have different means. Uses Welch's t-test by default, with an option for the pooled-variance test when equal variances are assumed.

Instructions

Test whether two independent samples have different means. Defaults to Welch's t-test (does not assume equal variances); pass equal_var=true for the classic pooled-variance test.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "a": "<a>",
      "b": "<b>"
    },
    "name": "two_sample_t_test"
  }
}

Input Schema

NameRequiredDescriptionDefault
aYesfirst independent sample
bYessecond independent sample
alphaNosignificance level for the test (and any confidence interval); default 0.05
equal_varNoassume equal population variances (classic pooled-variance test) instead of Welch's test

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.3.0
    • addedInput schema / properties / a / description
      Added value: +"first independent sample"
    • addedInput schema / properties / alpha / description
      Added value: +"significance level for the test (and any confidence interval); default 0.05"
    • addedInput schema / properties / b / description
      Added value: +"second independent sample"
    • addedInput schema / properties / equal_var / description
      Added value: +"assume equal population variances (classic pooled-variance test) instead of Welch's test"
  2. First observedv0.1.0

TDQS

A4.7/5.0
Behavior4/5

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

The annotation layer already declares readOnlyHint=true and idempotentHint=true, so the description doesn't need to restate safety. The description adds behavioral value by disclosing that with default settings it runs Welch's test (which does not assume equal variances) and how to switch to the classic test. A slight deduction is appropriate as it doesn't mention return values (test statistic, p-value, confidence intervals), but for a read-only statistical test, the current disclosure is quite complete.

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 perfectly-formed sentences with zero filler. The phrasing is front-loaded with the verb+resource, the default behavior is stated, and the alternative path is given as a conditional, making it easy for an agent to parse quickly.

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 statistical hypothesis test with 100% schema coverage and no output schema required, the description covers the statistical assumptions, defaults, and usage context comprehensively. It doesn't mention return values, but for a non-destructive, deterministic test, the key information (null hypothesis, inputs, and key parameter) is present.

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?

With 100% schema coverage, the parameters are already well-documented (a and b as independent samples; alpha and equal_var with defaults and clear descriptions). The description adds semantic depth by explaining the statistical implication of equal_var=false (Welch's test) versus equal_var=true (pooled-variance test), complementing the schema's mechanical definitions.

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 opens with a clear, specific verb+resource statement: 'Test whether two independent samples have different means.' It precisely scopes the operation (two independent samples, means comparison) and differentiates the default Welch's t-test from the classic pooled-variance version, distinguishing it from siblings like paired_t_test or one_sample_t_test.

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?

Explicitly states when to use this tool (for two independent samples testing mean differences) and the default behavior (Welch's test that assumes unequal variances). It also explicitly tells the agent when to pass equal_var=true for the alternative pooled-variance test, giving clear context on parameter-driven usage decisions.

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

Deploy Server

Other Tools