How do I use academic-stats-advisor?

1. Click on "Install 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., "@academic-stats-advisor What statistical test should I use for two independent groups?" 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.

academic-stats-advisor

by ganlin770

Overview Schema Source Related Servers Score Discussions Admin

Python

Hybrid

academic-stats-advisor · MCP server

An MCP (Model Context Protocol) server that lets an AI assistant — ChatGPT, Claude, Claude Code, Cursor, or any MCP client — directly call a statistician's decision logic instead of guessing. Point it at a study design and it returns the correct test, its assumptions, the SPSS menu path and R code, an APA reporting template, and an a-priori power analysis.

Built by Gan Lin. Dependency-light (only mcp), so it runs with a single command and deploys anywhere. (Repo academic-stats-mcp; server/package name academic-stats-advisor.)

⚠️ Decision-support for people who already know some statistics. It does not run your data or replace a statistician — always verify assumptions against your own dataset.

Tools

Tool	What the AI can call it for
`recommend_test`	"What statistical test should I use?" → test + why + assumptions + SPSS path + R code + APA template
`check_assumptions`	Assumptions of a given test, how to check each, and what to do if violated
`interpret_result`	Turn a p-value / effect size into a correct, APA-style conclusion (guards the classic mistakes)
`plan_sample_size`	A-priori power analysis — required n for two means, paired means, two proportions, or a correlation
`normality_guide`	How to decide and report normality the right way (the #1 thing students get wrong)
`list_supported_tests`	Everything the advisor knows, with SPSS menu paths

Covers the full classic tree: one-sample / independent / paired t-tests, Welch, Mann–Whitney, Wilcoxon, one-way / Welch / repeated-measures ANOVA, Kruskal–Wallis, Friedman, Pearson/Spearman, chi-square / Fisher / McNemar / goodness-of-fit, and Poisson/NB for counts.

Related MCP server: Stats Engine MCP Server

Run it (zero setup)

The server file carries its own dependencies (PEP 723), so uv needs nothing installed:

uv run server.py            # stdio  (for Claude Desktop / Claude Code / Cursor)
MCP_HTTP=1 uv run server.py # HTTP    (remote endpoint at http://localhost:8000/mcp)

Use it in Claude Code / Claude Desktop (local, stdio)

Add to your MCP config (Claude Desktop: claude_desktop_config.json; Claude Code: claude mcp add):

{
  "mcpServers": {
    "academic-stats-advisor": {
      "command": "uv",
      "args": ["run", "/absolute/path/to/academic-stats-mcp/server.py"]
    }
  }
}

Claude Code one-liner:

claude mcp add academic-stats-advisor -- uv run /absolute/path/to/academic-stats-mcp/server.py

Then just ask: "My outcome is a continuous score, two independent groups, the data are skewed — what test, and how do I report it?" — the model calls recommend_test and answers with the real decision logic.

Use it in ChatGPT / Claude.ai (remote, HTTP)

Deploy the HTTP transport, then add the resulting https://…/mcp URL as a custom connector.

Render (free): this repo includes render.yaml + Dockerfile → New ▸ Blueprint → pick the repo. Endpoint: https://<service>.onrender.com/mcp.
Docker anywhere: docker build -t stats-mcp . && docker run -p 8000:8000 stats-mcp → http://<host>:8000/mcp.
Any Python host: python server.py --http, and set PUBLIC_HOST=<your-domain> so the Host check allows it (without it, DNS-rebinding protection is off so it still works behind any proxy).

License

MIT — see LICENSE.

Available Tools

6 tools

check_assumptionsA

List the assumptions of a specific test, how to check each, and what to do if violated.

Pass a test_id from recommend_test / list_supported_tests (e.g. 'independent_t', 'one_way_anova', 'pearson', 'chi_square_independence').

ParametersJSON Schema

Name	Required	Description	Default
`test_id`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It describes the read-only nature (listing assumptions) and corrective actions, but gives no detail on side effects or post-conditions. Adequate for low-risk tool.

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: first states purpose, second provides usage guidance. No redundant information, front-loaded.

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?

Given simple tool with one parameter and no output schema, description covers purpose, parameter source, and return content (list). Could mention output format but not necessary.

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 has 0% description coverage for the only parameter, test_id. Description compensates by specifying that the value must come from recommend_test/list_supported_tests and providing example strings, adding essential context beyond the schema.

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?

Description clearly states the action: 'List the assumptions of a specific test', identifies the resource (test_id), and differentiates from siblings like interpret_result and recommend_test by specifying what it returns.

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?

Explicitly instructs to pass a test_id from recommend_test/list_supported_tests, with examples. Does not state when not to use, but context is clear.

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

interpret_resultB

Interpret a p-value correctly and produce a defensible, APA-style conclusion.

Guards against the classic mistakes: a non-significant result does NOT prove the null, and statistical significance is not practical importance (report effect size + CI).

ParametersJSON Schema

Name	Required	Default
`alpha`	No
`p_value`	Yes
`test_name`	No	the test
`effect_size`	No
`effect_size_type`	No

TDQS

B3.3/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. It discloses the tool guards against common mistakes and produces a conclusion, but does not describe side effects, error handling, or output format sufficiently.

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?

The description is two sentences long, front-loads the purpose, and wastes no words. Every sentence adds value.

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?

Given 5 parameters and no output schema, the description is incomplete. It fails to explain parameter roles or the output format, leaving the agent with insufficient guidance.

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

Parameters1/5

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

Schema coverage is 0% and the description does not explain any parameter beyond what field names suggest. Parameters like alpha, test_name, effect_size_type are not described, leaving significant ambiguity.

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 verb ('Interpret') and resource ('p-value'), and specifies an APA-style conclusion as output. It distinguishes from sibling tools (e.g., check_assumptions, recommend_test) by focusing on result interpretation.

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 description implies the tool is used after obtaining a p-value to get a correct interpretation, but does not explicitly state when not to use it or provide alternatives among siblings.

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

list_supported_testsA

List every test this advisor knows, with its SPSS menu path.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It states the tool lists tests with menu paths but does not disclose any additional behavioral traits (e.g., whether the list is static or dynamic, or if there are rate limits). It is adequate for a simple read-only operation.

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 with no extraneous words, front-loaded with the key action ('list every test'). Every sentence earns its place.

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?

Given no parameters and no output schema, the description is nearly complete. It could optionally mention if the list is sorted or categorized, but for a simple enumeration tool, it suffices.

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 has zero parameters and schema coverage is 100%, so the baseline is 4. The description adds meaning by specifying the output includes SPSS menu paths, which is beyond the schema.

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 uses a specific verb ('List') and resource ('every test this advisor knows') and includes additional detail ('with its SPSS menu path'), clearly distinguishing it from sibling tools like 'recommend_test' or 'check_assumptions'.

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 description implies usage when you need to see available tests, but lacks explicit when-to-use, when-not-to-use, or references to alternatives. Sibling tools exist but are not mentioned in the description.

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

normality_guideC

How to decide and report normality correctly — the #1 thing students get wrong.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

C2.7/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the burden. It implies an educational output but does not disclose what the tool actually does (e.g., returns text, shows a form). No mention of side effects or safety.

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?

The description is very short, which is concise, but lacks essential details about the tool's behavior. It is front-loaded but not sufficiently informative.

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?

Given no output schema, the description should explain what the tool returns. It only hints at guidance content, leaving output format unclear. For a simple guidance tool, more detail is needed.

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 has zero parameters and schema coverage is 100%. Baseline score of 4 applies as the description does not need to explain parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'How to decide and report normality correctly — the #1 thing students get wrong' indicates the tool provides guidance on normality testing, but does not specify the action (e.g., returns a guide, displays steps). It differentiates from siblings like 'check_assumptions' and 'interpret_result' by focusing on procedural advice.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like 'recommend_test' or 'interpret_result'. No context about prerequisites or typical scenarios.

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

plan_sample_sizeA

A priori power analysis: the required sample size for a target power.

effect_size is Cohen's d for two_means/paired_means, Cohen's h for two_proportions, and the correlation r for correlation. Uses a normal approximation — treat the result as a close lower bound and confirm exact numbers in G*Power for t-based tests.

ParametersJSON Schema

Name	Required	Description	Default
`alpha`	No
`power`	No
`two_sided`	No
`comparison`	Yes
`effect_size`	Yes

TDQS

A4.2/5.0

Behavior4/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. It discloses that the calculation uses a normal approximation and that the result is a close lower bound. This transparency about the method and its limitations is valuable for an agent deciding whether to trust the output.

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?

The description is two sentences with no redundant words. It front-loads the core purpose and then adds necessary detail. Every sentence contributes value.

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?

Given the tool's complexity (5 parameters, no output schema), the description explains the purpose, effect size mapping, and a crucial caveat. It does not describe the return value explicitly, but for a power analysis tool, the output (sample size) is implied. It is reasonably complete for an agent to use correctly.

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?

With schema description coverage at 0%, the description must compensate. It explains that effect_size uses Cohen's d for two_means/paired_means, Cohen's h for two_proportions, and correlation r for correlation. This adds meaning beyond the schema. However, it does not clarify alpha, power, or two_sided beyond their defaults, though these are standard statistical parameters.

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's purpose: 'A priori power analysis: the required sample size for a target power.' It uses a specific verb ('compute') and resource ('sample size'), and it distinguishes from sibling tools like check_assumptions or interpret_result by focusing on planning.

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 provides usage guidance by noting the normal approximation and advising to confirm exact numbers in G*Power for t-based tests. This tells the agent when to be cautious. However, it does not explicitly state when to use this tool versus alternatives like recommend_test.

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

recommend_testA

Recommend the correct statistical test for a study design.

Use this to answer "what statistical test should I use?". Describe the design: outcome_type (continuous/ordinal/nominal/count), design (one_sample = compare one group to a value; independent = compare separate groups; paired = same subjects over time/conditions; correlation = relationship between two variables; association = two categorical variables), how many groups, whether the outcome is ~normal, and whether group variances are equal. Returns the test, why, assumptions, SPSS path, R code, an APA reporting template, and fallbacks if assumptions fail.

ParametersJSON Schema

Name	Required	Default
`design`	Yes
`n_groups`	No
`normality`	No	unknown
`outcome_type`	Yes
`equal_variance`	No	unknown

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It clearly states what the tool returns: the test, assumptions, SPSS path, R code, APA template, and fallbacks. This provides good transparency about the tool's output, though it does not mention non-side-effect traits like data handling or auth requirements, which are not critical for this tool.

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?

The description is concise at about 5 sentences, front-loading the core purpose, then listing required inputs and expected outputs. Every sentence adds value, with no redundant or unclear phrasing.

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?

Given the tool's complexity and lack of output schema, the description covers the essential aspects: input requirements and output contents. It provides enough detail for an agent to use it correctly. A minor improvement could be including an example of a full input, but it is still quite complete.

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 coverage is 0%, so the description must compensate. It explicitly explains all 5 parameters: outcome_type, design, n_groups, normality, and equal_variance, with examples and guidance. This adds significant meaning beyond the raw schema, which only lists enums without descriptions.

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's purpose: 'Recommend the correct statistical test for a study design.' It specifies the verb (recommend), resource (statistical test), and context (study design). This distinguishes it from siblings like check_assumptions or interpret_result, which focus on different aspects of statistical analysis.

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 explicitly says 'Use this to answer "what statistical test should I use?"' and guides the user on what information to provide (outcome type, design, etc.). However, it does not explicitly mention when not to use this tool or directly contrast with siblings, though the context makes the differentiation clear.

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. Dates show when Glama detected each change.

6 tool updatesv0.1.0Jul 9, 2026
- First observedcheck_assumptions
- First observedinterpret_result
- First observedlist_supported_tests
- First observednormality_guide
- First observedplan_sample_size
- First observedrecommend_test

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: recommending tests, checking assumptions, interpreting results, planning sample size, listing supported tests, and normality guidance. No two tools overlap significantly; even assumptions and normality are separated clearly.

Naming Consistency5/5

All tool names use lowercase snake_case and follow a verb_noun pattern (e.g., check_assumptions, interpret_result). The only slight outlier is 'normality_guide', but it still fits the pattern and is consistently readable.

Tool Count5/5

With 6 tools, the set is well-scoped for a statistical advisor. Each tool covers a core aspect of statistical analysis workflow without redundancy or excessive granularity.

Completeness4/5

The toolset covers the essential workflow: test recommendation, assumptions, normality, sample size, interpretation, and listing tests. Minor gaps exist, such as non-parametric alternatives or post-hoc tests, but the core is solid.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

pearl-api-mcp-server A
com.pearl.mcp
Hybrid human + AI expertise for faster, trusted answers and decisions via MCP Server.
Search Knowledge & Memory
42
anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
ZapierOAuth
com.zapier
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
App Automation Workplace & Productivity
2297
OneSchema MCP Server
co.oneschema
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Data Platforms App Automation
1

Related MCP Servers

StatTools
Code Execution AI & Machine Learning Research & Data
zhangxiany-tamu
F
license
Not graded
quality
D
maintenance
MCP server that lets AI agents discover and call R and Python statistical functions without writing code.
Updated 4 months ago (2026-05-08 20:08 UTC)
-
Stats Engine MCP Server
Research & Data Data Visualization
wzx11223344
A
license
Not graded
quality
B
maintenance
A statistical analysis MCP server offering 30 tools for descriptive statistics, hypothesis tests, regression, and time series, all returning Markdown reports with automatic interpretations to enable AI agents to perform comprehensive data analysis.
Updated 2 months ago (2026-07-18 11:10 UTC)
MIT
statistician-mcp
Research & Data Data Visualization
ypotheto
A
license
Not graded
quality
B
maintenance
A virtual statistician MCP server that provides real statistical methods—design of experiments, hypothesis testing, regression, SPC, MSA—via tested Python libraries, with plain-language interpretations and plotted outputs.
Updated 2 months ago (2026-07-12 11:18 UTC)
MIT
r-stats-mcp
Research & Data Data Visualization
Ian3738
A
license
A
quality
C
maintenance
An MCP server that provides an LLM with access to R's statistical toolkit including hypothesis tests, regression, psychometrics, survival analysis, time series, and plots through a persistent R session.
Updated a month ago (2026-07-30 04:32 UTC)
33
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/ganlin770/academic-stats-mcp'

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