Skip to main content
Glama
deenesjakoruzh
SepineTam

Stata-MCP

by SepineTam
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

en cn Publish to PyPI Build and Push Docker Images PyPI version PyPI Downloads License: AGPL 3.0 Issue Ask DeepWiki

Notes: While we strive to make open source accessible to everyone, we regret that we can no longer maintain the Apache-2.0 License. Due to individuals directly copying this project and claiming to be its maintainers, we have decided to change the license to AGPL-3.0 to prevent misuse of the project in ways that go against our original vision.

Notes: 尽管我们希望尽可能让所有人都能从开源中获益，但我们很遗憾地宣布无法继续保持 Apache-2.0 License。由于有人直接抄袭本项目并标榜其为项目维护者，我们不得不将 License 更改为 AGPL-3.0，以防止有人滥用本项目进行违背项目初心的事情。

Background: @jackdark425's repository directly copied this project and claimed to be the sole maintainer. We welcome open source collaboration based on forks, including but not limited to adding new features, fixing existing bugs, or providing valuable suggestions for the project, but we firmly oppose plagiarism and false attribution.

Update: The infringing project has been taken down via GitHub DMCA. Click here to learn about.

背景: @jackdark425 的仓库直接抄袭了本项目并标榜为项目唯一维护者。我们欢迎基于fork的开源协作，包括但不限于添加新的feature、修改已有bug或对项目提出您宝贵的意见，但坚决反对抄袭和虚假署名行为。

更新: 侵权项目已通过GitHub DMCA被takedown，点击这里查看详情。

News:

  • 🦞 OpenClaw Support: Standalone CLI tools for OpenClaw integration (stata-mcp tool), see OpenClaw guide

  • ✨ Claude Code Plugin Support: Official plugin package with MCP server and Stata LSP integration

  • Use Stata-MCP in Claude Code, look here

Finding our newest research? Click here or visit reports website.

MCP or AI about Stata

Datasets and Informations

  • STOP Dataset: StataMCP-Team Opendata Project 📊, we have open-sourced a comprehensive dataset collection for social science research, aiming to enable the future of AI-driven and data-powered research paradigms.

  • Trace DID: If you want to fetch the newest information about DID (Difference-in-Difference), click here. Now there is a Chinese translation by Sepine Tam and StataMCP-Team 🎉

  • Jupyter Lab Usage (Important: Stata 17+) here and nbstata

💡 Quickly Start

Use Stata-MCP in Claude Code

We can use Stata-MCP in Claude Code as its prefect agentic ability.

Before using it, please make sure you have ever install Claude Code, if you don't know how to install it, visit on GitHub

Generally, you can install Stata-MCP globally for one time, you can run:

claude mcp add stata-mcp --scope user -- uvx stata-mcp

Then, you do not need to watch it again.

If you want to install it locally only for the certain workspace, you can open your terminal and cd to your working directory, and run:

claude mcp add stata-mcp --env STATA_MCP_CWD=$(pwd) --scope local -- uvx --directory $(pwd) stata-mcp

It would nothing happen, you can type claude and type /mcp to find the status.

If you are collaborating with others, you can use project scope for that, with:

claude mcp add stata-mcp --scope project -- uvx stata-mcp

In your working directory, you can find a file named .mcp.json, your mcp config will be placed here.

Then, you can use Stata-MCP in Claude Code. Here are some scenarios for using it:

  • Paper Replication: Replicate empirical studies from economics papers

  • Quick Hypothesis Testing: Validate economic hypotheses through regression analysis

  • Stata Learning Assistant: Learn econometrics with step-by-step Stata explanations

  • Code Organization: Review and optimize existing Stata do-files

  • Result Interpretation: Understand complex statistical outputs and regression results

Install Claude Code Plugin

We provide official native plugin, integrating Stata-MCP maintained by @sepinetam and Stata LSP maintained by @euglevi. Installation commands:

# Install stata-mcp marketplace first
claude plugin marketplace add sepinetam/stata-mcp

# Install plugin to local, project or user scope
claude plugin install stata-toolbox -s local

Agent Mode

The details of agent mode find here.

git clone https://github.com/sepinetam/stata-mcp.git
cd stata-mcp

uv sync
uv pip install -e .

stata-mcp --version  # for test whether stata-mcp is installed successfully.
stata-mcp agent run  # now you can enjoy your stata-mcp agent mode.

or you can directly use it with uvx:

uvx stata-mcp --version  # for test whether it could be used on your computer.
uvx stata-mcp agent run

You can edit the task in agent_examples/openai/main.py for variable [model_instructions](source/agent_examples/openai/main.py#L37) and [task_message](source/agent_examples/openai/main.py#L68)

Agent as Tool

If you want to use a Stata-Agent in another agent, here is a simple example:

import asyncio

from agents import Agent, Runner
from stata_mcp.agent_as.agent_as_tool import StataAgent

# init stata agent and set as tool
stata_agent = StataAgent()
sa_tool = stata_agent.as_tool()

# Create main Agent
agent = Agent(
    name="Assistant",
    instructions="You are a helpful assistant",
    tools=[sa_tool],
)


# Then run the agent as usual.
async def main(task: str, max_turns: int = 30):
    result = await Runner.run(agent, input=task, max_turns=max_turns)
    return result


if __name__ == "__main__":
    econ_task = "Use Stata default data to find out the relationship between mpg and price."
    asyncio.run(main(econ_task))

AI Chat-Bot Client Mode

Standard config requires: please make sure the stata is installed at the default path, and the stata cli (for macOS and Linux) exists.

The standard config json as follows, you can DIY your config via add envs.

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

For more detailed usage information, visit the Usage guide.

And some advanced usage, visit the Advanced guide

Prerequisites

  • uv - Package installer and virtual environment manager

  • Claude, Cline, ChatWise, or other LLM service

  • Stata License

  • Your API-KEY from LLM

Notes:

  1. If you are located in China, a short uv usage document you can find here.

  2. Claude is the best choice for Stata-MCP, for Chinese, I recommend to use DeepSeek as your model provider as it is cheap and powerful, also the score is highest in China provider, if you are increased in it, visit the report How to use StataMCP improve your social science research.

Installation

For the new version, you don't need to install the stata-mcp package again, you can just use the following command to check whether your computer can use stata-mcp.

uvx stata-mcp doctor
uvx stata-mcp --version

If you want to use it locally, you can install it via pip or download the source code.

Download via pip

pip install stata-mcp

Download source code and compile

git clone https://github.com/sepinetam/stata-mcp.git
cd stata-mcp

uv build

Then you can find the compiled stata-mcp binary in the dist directory. You can use it directly or add it to your PATH.

For example:

uvx /path/to/your/whl/stata_mcp-1.13.0-py3-non-any.whl  # here is the wheel file name, you can change it to your version

Related MCP server: Stata MCP Server

📝 Documentation

Core Documentation

Usage Guides

Key Features

  • Security Guard: Blocks dangerous commands (!, shell, erase, etc.)

  • RAM Monitoring: Prevents memory exhaustion with configurable limits

  • Unified Configuration: TOML config + environment variables

  • Cross-platform support (macOS, Windows, Linux)

  • Automatic log capture and error reporting

💡 Questions

🚀 Roadmap

  • macOS support

  • Windows support

  • Additional LLM integrations (With a new webUI)

  • Performance optimizations (Via prompt and context engineering)

For more information, refer to the Statement.

🐛 Report Issues

If you encounter any bugs or have feature requests, please open an issue.

📄 License

GNU Affero General Public License v3.0

📚 Citation

If you use Stata-MCP in your research, please cite this repository using one of the following formats:

BibTeX

@software{sepinetam2025stata,
  author = {Song Tan},
  title = {Stata-MCP: Let LLM help you achieve your regression analysis with Stata},
  year = {2025},
  url = {https://github.com/sepinetam/stata-mcp},
  version = {1.13.0}
}

APA

Song Tan. (2025). Stata-MCP: Let LLM help you achieve your regression analysis with Stata (Version 1.13.0) [Computer software]. https://github.com/sepinetam/stata-mcp

Chicago

Song Tan. 2025. "Stata-MCP: Let LLM help you achieve your regression analysis with Stata." Version 1.13.0. https://github.com/sepinetam/stata-mcp.

📬 Contact

Email: sepinetam@gmail.com

Or contribute directly by submitting a Pull Request! We welcome contributions of all kinds, from bug fixes to new features.

❤️ Acknowledgements

The author sincerely thanks the Stata official team for their support and the Stata License for authorizing the test development.

📃 Statement

The Stata referred to in this project is the commercial software Stata developed by StataCorp LLC. This project is not affiliated with, endorsed by, or sponsored by StataCorp LLC. This project does not include the Stata software or any installation packages; users must obtain and install a validly licensed copy of Stata from StataCorp. This project is licensed under AGPL-3.0. The project maintainers accept no liability for any loss or damage arising from the use of this project or from actions related to Stata.

More information: refer to the Chinese version at [source/docs/README/cn/README.md]; in case of any conflict, the Chinese version shall prevail.

✨ Star History

Star History Chart

Available Tools

4 tools
get_data_infoA

Get descriptive statistics and a data preview for a supported data file (.dta, .csv, .tsv, .psv, .xlsx, .xls, .sav, .zsav). Returns overview, variable details, and optional head rows filtered by requested variables. Use when you need to understand a dataset or have no prior knowledge of the data.

ParametersJSON Schema
NameRequiredDescriptionDefault
headNo
encodingNoutf-8
data_pathYes
vars_listNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

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 must convey behavioral transparency. It implies a non-destructive read operation via 'Get' and 'preview', but does not explicitly state that no file modifications occur or address error/permission behavior. It adds some context with supported formats and output shape, but safety traits are left to inference.

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 that are front-loaded and efficient. The first sentence states the core function and return outputs; the second gives the usage trigger. No filler or redundant content.

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 data-info tool with an output schema, the description covers the essential purpose, supported formats, return summary, and usage context. It misses the encoding parameter and does not specify whether the tool is read-only, but overall it is sufficiently complete for an agent to invoke it correctly in most scenarios.

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. It explains 'optional head rows' (head) and 'filtered by requested variables' (vars_list), and data_path is implied by 'data file'. However, the encoding parameter is not mentioned, leaving 1 of 4 parameters undocumented. The description partially mitigates the schema gap but not completely.

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 function: 'Get descriptive statistics and a data preview for a supported data file' with explicit file format list. It specifies the return content (overview, variable details, optional head rows) and distinguishes itself from unrelated siblings like read_log and stata_do.

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 a clear use case: 'Use when you need to understand a dataset or have no prior knowledge of the data.' It does not explicitly mention when not to use or alternatives, but the context implies it's the primary tool for data exploration.

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

helpA

Retrieve documentation and usage information for a Stata command. Use when you need to understand a command's syntax, options, or troubleshoot errors before running it.

ParametersJSON Schema
NameRequiredDescriptionDefault
cmdYes
replaceNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/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 cover behavioral aspects. It states the tool 'retrieves documentation,' which implies a read-only operation, but it does not disclose the format of the output (e.g., text, pager) or any potential side effects. The description is adequate but minimal.

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 contains no redundant information. Every word earns its place.

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?

The tool is simple with an output schema, but the description lacks parameter documentation, which is essential for correct usage. It does not mention whether the command requires internet or works offline. It is minimally complete for a help tool but leaves gaps.

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%, meaning the description adds no explanation for the two parameters ('cmd' and 'replace'). The agent receives no guidance on what 'cmd' expects (e.g., a string of the command name) or the effect of 'replace' (e.g., overwriting existing help file). This is a critical gap.

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 action ('Retrieve') and the resource ('documentation and usage information for a Stata command'). This distinguishes it well from siblings like 'stata_do' (execute code) and 'get_data_info' (data information).

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 explicit context for when to use the tool: 'Use when you need to understand a command's syntax, options, or troubleshoot errors before running it.' It does not specify when not to use it or mention alternatives, but the positive guidance is strong and clear.

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

read_logA

Read a Stata log file (.log or .smcl) and return its content. Supports full, core, and dict output formats. Use lines to return only the first/last N lines.

ParametersJSON Schema
NameRequiredDescriptionDefault
linesNo
encodingNoutf-8
file_pathYes
output_formatNocore

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/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 does not explicitly state that the operation is read-only or describe any side effects, authentication needs, or constraints. However, the read nature is implied.

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?

Three sentences, all informative, no wasted words. Front-loads purpose and adds details about formats and the lines parameter efficiently.

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 4 parameters, no annotations, and presence of output schema, the description covers the basics but leaves gaps in parameter meaning (encoding, file_path) and does not fully compensate for missing schema descriptions.

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%, so description must explain parameters. It describes output_format enum values and lines parameter but does not clarify encoding or file_path. The lines behavior (positive/negative for first/last) is ambiguous.

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 it reads Stata log files (.log or .smcl) and returns content, with verb 'Read' and resource 'log file'. It distinguishes from siblings (get_data_info, help, stata_do) by specifying the file type and output formats.

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?

Provides basic guidance on output formats and lines parameter, but does not explicitly state when to use the tool vs. alternatives, nor when not to use it. Usage context is implied but not formalized.

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

stata_doB

Execute a Stata do-file and return the execution log. Accepts a do-file path, runs it via the configured Stata executable, and can optionally read log content only when return-code errors are detected. Use when you need to run Stata commands, perform regression or statistical analysis, or execute a do-file.

ParametersJSON Schema
NameRequiredDescriptionDefault
timeoutNo
dofile_pathYes
enable_smclNo
log_file_nameNo
is_replace_logNo
read_log_when_errorNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.2/5.0
Behavior2/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 mentions the tool executes a do-file and optionally reads log on error, but fails to disclose side effects (e.g., file system changes), required permissions, or behavior on failure. This leaves significant gaps for a mutation-like 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?

The description is three sentences and concise, front-loading the main action. However, it could be more structured by linking parameters to their roles, but it is not overly verbose.

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 6 parameters and an output schema, the description is incomplete. It does not explain most parameters (e.g., timeout, log options) beyond a brief mention of error-triggered log reading. This forces the agent to guess parameter semantics, reducing usability.

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 description coverage is 0%, yet the description adds no detail for parameters beyond mentioning 'dofile_path'. Parameters like 'timeout', 'enable_smcl', 'log_file_name', 'is_replace_log', and 'read_log_when_error' are completely unexplained, making it hard for an agent to use them correctly.

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 it executes a Stata do-file and returns the execution log, with a specific verb ('Execute') and resource ('Stata do-file'). It distinguishes itself from siblings like 'read_log' and 'get_data_info' by focusing on running do-files for 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 tells when to use the tool: 'Use when you need to run Stata commands, perform regression or statistical analysis, or execute a do-file.' It does not mention when not to use or alternatives, but the context is clear and helpful for an agent.

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.

  1. 1 tool updatev1.21.3
    • Changedget_data_info3 fields changed
      • addedInput schema / properties / head / anyOf
        Added value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]
      • changedInput schema / properties / head / default
        Previous value: -0New value: +null
      • removedInput schema / properties / head / type
        Removed value: -"integer"
  2. 2 tool updatesv1.21.0
    • Changedread_log2 fields changed
      • removedInput schema / properties / is_beta
        Removed value: -{
-  "default": false,
-  "title": "Is Beta",
-  "type": "boolean"
-}
      • changedInput schema / properties / output_format / default
        Previous value: -"dict"New value: +"core"
    • Changedstata_do2 fields changed
      • changedInput schema / title
        Previous value: -"stata_doArguments"New value: +"_sync_stata_doArguments"
      • changedOutput schema / title
        Previous value: -"stata_doOutput"New value: +"_sync_stata_doOutput"
  3. 2 tool updatesv1.19.0
    • Removedado_package_install
    • Changedstata_do1 field changed
      • addedInput schema / properties / timeout
        Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Timeout"
+}
  4. 7 tool updatesv1.16.2
    • Addedado_package_install
    • Removedappend_dofile
    • Changedget_data_info2 fields changed
      • addedInput schema / properties / head
        Added value: +{
+  "default": 0,
+  "title": "Head",
+  "type": "integer"
+}
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "title": "Result",
+      "type": "string"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "get_data_infoOutput",
+  "type": "object"
+}
    • Addedhelp
    • Changedread_log8 fields changed
      • addedInput schema / properties / encoding
        Added value: +{
+  "default": "utf-8",
+  "title": "Encoding",
+  "type": "string"
+}
      • addedInput schema / properties / file_path
        Added value: +{
+  "title": "File Path",
+  "type": "string"
+}
      • addedInput schema / properties / is_beta
        Added value: +{
+  "default": false,
+  "title": "Is Beta",
+  "type": "boolean"
+}
      • addedInput schema / properties / lines
        Added value: +{
+  "default": 0,
+  "title": "Lines",
+  "type": "integer"
+}
      • removedInput schema / properties / log_path
        Removed value: -{
-  "title": "Log Path",
-  "type": "string"
-}
      • addedInput schema / properties / output_format
        Added value: +{
+  "default": "dict",
+  "enum": [
+    "full",
+    "core",
+    "dict"
+  ],
+  "title": "Output Format",
+  "type": "string"
+}
      • changedInput schema / required
        Previous value: -[
-  "log_path"
-]New value: +[
+  "file_path"
+]
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "title": "Result",
+      "type": "string"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "read_logOutput",
+  "type": "object"
+}
    • Changedstata_do5 fields changed
      • addedInput schema / properties / enable_smcl
        Added value: +{
+  "default": true,
+  "title": "Enable Smcl",
+  "type": "boolean"
+}
      • addedInput schema / properties / is_replace_log
        Added value: +{
+  "default": true,
+  "title": "Is Replace Log",
+  "type": "boolean"
+}
      • addedInput schema / properties / log_file_name
        Added value: +{
+  "default": null,
+  "title": "Log File Name",
+  "type": "string"
+}
      • addedInput schema / properties / read_log_when_error
        Added value: +{
+  "default": false,
+  "title": "Read Log When Error",
+  "type": "boolean"
+}
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "additionalProperties": true,
+      "title": "Result",
+      "type": "object"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "stata_doOutput",
+  "type": "object"
+}
    • Removedwrite_dofile
  5. 5 tool updatesv1.0.0
    • First observedappend_dofile
    • First observedget_data_info
    • First observedread_log
    • First observedstata_do
    • First observedwrite_dofile
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0
Disambiguation5/5

Each tool has a clearly distinct role: executing do-files, reading log output, inspecting data, and retrieving command documentation. There is no overlap in purpose, so an agent can easily select the right tool.

Naming Consistency4/5

Three tools follow a clear verb_noun pattern (read_log, get_data_info, stata_do), though 'stata_do' is slightly awkward as a noun_verb inversion. 'help' is a single verb, deviating from the pattern, but the overall naming remains predictable and readable.

Tool Count4/5

With 4 tools covering the core workflow of running Stata analysis and inspecting outputs, the count feels appropriately scoped. It is on the lower end but not thin, as each tool addresses a substantial step.

Completeness4/5

The tool set covers the main lifecycle: execute a do-file, inspect its log, examine data, and get help for commands. Missing operations like dataset writing or interactive command execution are minor and can be worked around by using do-files.

Maintenance

ActivityActive
ResponsivenessResponsive

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

Appeared in Searches

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/SepineTam/mcp-for-stata'

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