Which integrations are available for this server?

Compiles, runs, and tests C++ code for competitive programming workflows: it builds sources with g++/clang++ (or an auto-installed managed toolchain), executes programs against provided input, compares actual output to expected output, manages test case files, and supports GDB-based debugging within a sandboxed temp workspace.

How do I use mcp_oi_assistant?

1. Click on "Deploy 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., "@mcp_oi_assistant compile and run solution.cpp with input "5 3"" 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.

mcp_oi_assistant

by Stellinora

Overview Schema Source Related Servers Discussions Admin

Python

Local

mcp_oi_assistant

一个为编程竞赛（OI）选手设计的 MCP 服务器，能够安全地编译、运行并测试 C++ 代码。

📋 功能列表

核心功能

✅ 编译 C++ 代码：优先使用系统 g++ / clang++ / MinGW
✅ 自动准备工具链：系统没有编译器时，首次运行自动下载到用户缓存目录
✅ 运行程序：提供输入数据，获取程序输出
✅ 输出比较：自动比对实际输出与预期输出
✅ GDB 调试：支持使用 GDB 进行代码调试
✅ 测试用例管理：读取预设的测试用例文件
✅ 环境自检：通过 get_environment_info 查看编译器与缓存状态

安全特性

✅ 目录隔离：所有文件操作限制在临时工作区内
✅ 命令过滤：阻止执行危险系统命令
✅ 资源限制：自动限制运行时间、内存和输出大小
✅ 文件名消毒：防止路径遍历攻击

Related MCP server: @meeseeks-sdk/mcp

🛠️ 工具链

探测顺序：

OI_CXX / OI_GDB / OI_MINGW_DIR 环境变量
配置文件中的显式路径
系统 PATH 中的 g++ / clang++ / gdb（Windows 也会检查常见 MinGW 目录）
缓存目录中的托管工具链
仓库旁的 mingw64/

系统没有可用编译器时，首次运行会在后台自动下载并安装到用户缓存目录；不会修改系统 PATH，也不会写入系统目录。

平台	托管工具链	下载体积
Windows x86_64	WinLibs MinGW-w64 GCC 15.3.0 + GDB	约 255MB
Linux x86_64 / aarch64	micromamba + conda-forge GCC 15.3.0 + GDB	约 300–500MB
macOS x86_64 / arm64	conda-forge clang 23.1.3 + GDB	约 300–500MB

缓存位置（可用 toolchain.cache_dir 覆盖）：

Linux：~/.cache/mcp-oi-assistant/toolchains
macOS：~/Library/Caches/mcp-oi-assistant/toolchains
Windows：%LOCALAPPDATA%\mcp-oi-assistant\toolchains

macOS 若没有 Xcode Command Line Tools，conda clang 可能缺少系统头文件，此时请执行 xcode-select --install。Windows ARM64 与 Linux musl（Alpine）暂不支持托管安装，请使用系统工具链。

常用命令：

# 查看当前使用的编译器、GDB、缓存和安装状态
uvx ... mcp-oi-assistant --check-toolchain

# 手动预装（CI、离线环境或不想等待首次编译时）
uvx ... mcp-oi-assistant --install-toolchain

# 删除托管工具链
uvx ... mcp-oi-assistant --clean-toolchain

可用环境变量：OI_TOOLCHAIN_AUTO_INSTALL=0 关闭自动安装，OI_TOOLCHAIN_OFFLINE=1 禁止联网，OI_TOOLCHAIN_MIRROR 指定镜像目录或 URL 前缀，OI_TOOLCHAIN_DIR 指向现成工具链目录。

🚀 快速开始

需要先安装 uv 和 git（一次性）。之后一条命令即可启动，首次运行会下载并缓存，后续直接复用缓存：

uvx --from "git+https://github.com/Stellinora/mcp_oi_assistant.git@v1.1.2" mcp-oi-assistant

首次：拉取源码、构建并安装依赖，缓存到 uv 缓存目录。
之后：复用已构建的缓存；使用 tag 时仍会向 GitHub 解析一次引用（约 1–2 秒）。
完全离线：把 @v1.1.2 换成对应提交 SHA（git rev-parse v1.1.2），已缓存后可用 UV_OFFLINE=1 启动。
升级：改用新 tag，或加 --refresh；清理缓存：uv cache prune。

本地开发也可直接运行：

uv run mcp-oi-assistant
# 或兼容旧入口
python main.py

配置到 AI 客户端

MCP 服务器需要配合支持 MCP 协议的 AI 客户端使用，如 Claude Desktop、Cursor、CherryStudio 等。

{
  "mcpServers": {
    "oi-assistant": {
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/Stellinora/mcp_oi_assistant.git@v1.1.2",
        "mcp-oi-assistant"
      ],
      "env": {
        "OI_CXX": "/usr/bin/g++",
        "OI_GDB": "/usr/bin/gdb"
      }
    }
  }
}

Windows 示例：

{
  "mcpServers": {
    "oi-assistant": {
      "command": "C:\\Users\\你的用户名\\.local\\bin\\uvx.exe",
      "args": [
        "--from",
        "git+https://github.com/Stellinora/mcp_oi_assistant.git@v1.1.2",
        "mcp-oi-assistant"
      ],
      "env": {
        "OI_CXX": "C:\\mingw64\\bin\\g++.exe",
        "OI_GDB": "C:\\mingw64\\bin\\gdb.exe"
      }
    }
  }
}

GUI 客户端可能找不到 shell PATH 中的 uvx，请填写 which uvx（Windows 用 where uvx）得到的绝对路径。env 中的工具路径可省略，省略时自动探测。

目录结构

mcp_oi_assistant/
├── pyproject.toml       # 打包与依赖定义
├── main.py              # 兼容旧入口
├── config.yaml          # 开发用配置样例
├── src/mcp_oi_assistant/
│   ├── __main__.py      # 启动入口
│   ├── server.py        # MCP 服务器核心
│   ├── runner.py        # 代码运行器
│   ├── toolchain.py     # 工具链探测、下载与缓存
│   ├── toolchain_manifest.json  # 各平台下载地址与校验值
│   ├── security.py      # 安全模块
│   └── config.py        # 配置加载与路径解析
├── tests/               # 单元测试
├── tmp/                 # 开发时的临时工作区（自动创建）
└── mingw64/             # MinGW 工具链（可选，需自行放置）

⚙️ 配置文件

配置文件是可选的，未找到时使用内置默认值。查找顺序：

--config 路径
环境变量 OI_CONFIG
当前目录的 config.yaml
用户配置目录下的 config.yaml（Linux 通常为 ~/.config/mcp-oi-assistant/）
仓库根目录的 config.yaml（仅开发场景）

主要配置项：

# 编译设置
compilation:
  compiler_path: "auto"     # auto 或 g++ 的显式路径
  cpp_standard: "c++17"     # C++标准
  optimization_level: "-O2" # 优化级别

# 运行限制
execution:
  max_time: 5000            # 最大运行时间（毫秒）
  max_memory: 256           # 最大内存（MB）
  max_output_size: 1048576  # 最大输出（1MB）

# 路径设置
paths:
  temp_dir: "./tmp"         # 临时文件目录（相对配置文件所在目录）
  mingw_dir: "./mingw64"    # MinGW目录（可选）
  gdb_path: "auto"          # auto 或 gdb 的显式路径

# 托管工具链
toolchain:
  auto_install: true        # 系统没有编译器时自动下载
  prefer: "system"          # system 或 managed
  cache_dir: null           # null 表示使用用户缓存目录
  install_timeout: 900      # 首次等待安装的秒数
  mirror: null              # 镜像目录或 URL 前缀

未配置 paths.temp_dir 时，默认使用用户缓存目录：

Linux：~/.cache/mcp-oi-assistant/tmp
macOS：~/Library/Caches/mcp-oi-assistant/tmp
Windows：%LOCALAPPDATA%\mcp-oi-assistant\tmp

📁 文件存储

程序运行时会自动在临时工作区下创建以下子目录：

tmp/
├── sources/     # 源代码文件（*.cpp）
├── execute/     # 可执行文件
├── inputs/      # 输入数据文件（*.in）
├── outputs/     # 程序输出文件（*.out）
└── tests/       # 测试用例文件（*.txt）

托管工具链与其下载缓存位于同级缓存目录的 toolchains/ 下，可用 --clean-toolchain 删除。

🏷️ 版本策略

破坏性变更（改命令名、配置格式、工具参数等）升主版本号
新增功能升次版本号
修复问题升补丁版本号

📄 许可证

MIT License

Available Tools

5 tools

compare_outputsC

比较两个输出

Name	Required	Description
`actual`	Yes	实际输出
`expected`	Yes	预期输出
`ignore_case`	No	是否忽略大小写
`ignore_whitespace`	No	是否忽略空白字符

TDQS

C2.5/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full disclosure burden, yet it says nothing about behavior: not whether the comparison is exact, not what the result looks like (boolean? diff text?), and not how failures are surfaced. The only behavioral hints come from the schema defaults (ignore_whitespace=true), not the description.

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 a single short phrase with no wasted words, but it is under-specified rather than effectively concise. There is no front-loaded detail beyond a restatement of the tool name.

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?

With no annotations and no output schema, the description is the only place an agent can learn what the comparison returns and how results should be interpreted, and it supplies none of that. For a 4-parameter tool whose entire value is its comparison result, this is a significant gap.

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 100%, with each of the four parameters documented in Chinese (actual, expected, ignore_case, ignore_whitespace). The description adds no meaning beyond the schema, so the baseline of 3 applies.

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 phrase "比较两个输出" gives a verb (compare) and a resource (two outputs), so the general purpose is understandable. However, it does not distinguish the tool from siblings such as compile_and_run or read_test_case, and it never specifies what 'compare' means (exact equality, boolean result, diff report).

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?

There is no guidance on when to use this tool versus alternatives, no mention of prerequisites (e.g., needing output captured from compile_and_run first), and no exclusions. The agent must infer its place in the workflow entirely from the name.

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

compile_and_runC

编译并运行C++代码

Name	Required	Description
`code`	Yes	C++源代码
`input`	Yes	输入数据
`filename`	No	文件名（可选）
`time_limit`	No	时间限制（毫秒）
`memory_limit`	No	内存限制（MB）
`expected_output`	No	预期输出（可选）

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are present, so the description carries the full behavioral burden. It discloses nothing about sandboxing, execution limits, error handling for compilation failures, or what is returned (stdout, stderr, exit code), beyond the bare implication that code executes.

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 a single front-loaded sentence with zero waste. It is very terse for a six-parameter execution tool, but that is a completeness gap rather than verbosity.

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?

With no annotations, no output schema, and six parameters including limits and expected_output, the description is far too thin. An agent cannot tell what the tool returns, how failures are reported, or how expected_output interacts with the run.

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 100%, so all six parameters are already documented in the schema. The description adds no meaning beyond those field labels, which is the baseline 3 for high schema coverage.

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

Purpose4/5

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

The description names a specific verb pair plus resource (compile and run C++ code), so the core purpose is unambiguous. It does not differentiate itself from siblings such as debug_with_gdb or explain the role of expected_output versus compare_outputs, leaving routing to inference.

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 is given about when to use this tool rather than debug_with_gdb, compare_outputs, or read_test_case. There is no mention of preconditions, whether expected_output triggers comparison, or when to prefer the debugging sibling.

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

debug_with_gdbC

使用GDB调试C++程序

Name	Required	Description	Default
`code`	Yes	C++源代码
`gdb_script`	No	GDB调试脚本（可选）

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It says debugging happens via GDB but does not explain interactivity, execution environment, permissions, side effects, or what the tool returns, leaving significant gaps.

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 a single front-loaded sentence with no wasted words. Its brevity is appropriate structurally, though it leaves important details to other dimensions.

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?

With no annotations, no output schema, and no explanation of execution behavior, the description is under-informative for a debugging tool. An agent would not know whether debugging is interactive, what environment is used, or what to expect from the two parameters.

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 100%, so both parameters are already documented by the schema. The description does not add meaning beyond the schema, which is acceptable given the complete schema coverage, but it also does not clarify the optional gdb_script usage.

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

Purpose4/5

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

The description states a clear action and resource: use GDB to debug C++ programs. It is specific enough for an agent to understand the tool's basic function, though it does not differentiate this from sibling tools such as compile_and_run.

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?

There is no guidance on when to use this tool versus compile_and_run or other siblings. The agent must infer the tool's role from its name and description alone.

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

get_environment_infoA

查看编译器、GDB、托管工具链与缓存状态

Name	Required	Description	Default
No parameters

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 carries the full behavioral burden. It makes clear this is a status/inspection operation with no parameters, which implies read-only and side-effect-free, but it never states that explicitly, nor does it describe the shape of the returned status data. With no output schema, that omission is the main gap.

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 short clause that front-loads the verb and lists the four inspected areas with no filler. Nothing could be removed without losing information.

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?

For a zero-argument read tool this is close to adequate, but with no annotations and no output schema the description should say what the returned status looks like (per-component fields, versions, cache hit state). As written, an agent knows what categories are checked but not what it will receive.

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 takes zero parameters, so there is nothing for the description to disambiguate. The baseline for a no-parameter tool applies, and the description correctly signals that the call needs no input.

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

Purpose4/5

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

The description states a specific verb (查看/view) and enumerates the resources inspected: compiler, GDB, managed toolchain, and cache status. That is more specific than a generic 'get info' tool. It does not explicitly contrast itself with siblings like compile_and_run or debug_with_gdb, though their action-oriented names make the division fairly evident.

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?

There is no explicit statement of when to call this tool (e.g. before compiling or debugging to verify toolchain readiness) and no mention of alternatives. Usage is only implied by the fact that it inspects the environment the sibling tools operate in.

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

read_test_caseC

读取测试用例文件

Name	Required	Description	Default
`test_case_id`	Yes	测试用例ID

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about error behavior when the ID is not found, what the returned content looks like, or whether the read is side-effect free. 'Read' implies a safe operation, but that is left implicit.

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 single short sentence is front-loaded and wastes no words, but its brevity reflects under-specification rather than disciplined conciseness. There is no structure beyond the bare purpose statement.

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?

With no annotations, no output schema, and a one-line description, the definition leaves key information unstated for even a simple read tool — notably what is returned and how failures are signaled. Adequate only for trivial invocation.

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 100% and there is only one required parameter (test_case_id), so the schema already documents the input fully. The description adds no format hints (e.g., ID syntax) beyond what the schema provides, making the baseline 3 appropriate.

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

Purpose4/5

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

The description states a specific verb and resource ('读取测试用例文件' — read a test case file), which is clearly distinct from siblings like compile_and_run, debug_with_gdb, and compare_outputs. It does not explicitly name or contrast with any sibling, so it falls short of a 5.

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?

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The agent must infer usage purely from the tool name.

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.

5 tool updatesv1.1.2Nov 1, 2026
- First observedcompare_outputs
- First observedcompile_and_run
- First observeddebug_with_gdb
- First observedget_environment_info
- First observedread_test_case

Deploy Server

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

TDQS

B3.2/5.0

Scored 2026-11-01 08:50 across 5 tools

Disambiguation5/5

Each tool targets a distinct operation: compiling/running code, debugging with GDB, comparing outputs, reading a test case, and inspecting environment state. There is no meaningful overlap between these purposes, so an agent can select the right tool without confusion.

Naming Consistency4/5

All names use snake_case and are action-oriented, mostly following a verb_noun pattern such as compare_outputs, read_test_case, and get_environment_info. Minor deviations like compile_and_run and debug_with_gdb introduce conjunction/preposition forms, but the overall convention remains predictable.

Tool Count5/5

Five tools is well-scoped for a C++ olympiad-style assistant: compile/run, debug, compare outputs, read test cases, and check the toolchain environment. Each tool has a clear role, with no obvious filler or missing core capability at this scope.

Completeness4/5

The surface covers the core compile-run-debug-test workflow, including test case reading, output comparison, and environment inspection. Minor gaps remain, such as writing/editing source files, listing available test cases, or running a batch of test cases, but these can likely be handled outside this server.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Related MCP Connectors

ArcAgent MCP
io.github.araujota
ArcAgent MCP server for bounty discovery, workspace execution, and verified coding submissions.
Autonomous Agents Code Execution Coding Agents
22
https://mcp.arcagent.dev/mcp
Parallel Task MCP A
ai.parallel
An MCP server for deep research or task groups
Autonomous Agents Agent Orchestration Research & Data
4416
https://task-mcp.parallel.ai/mcp
Arcjet
com.arcjet
An MCP server for Arcjet - the runtime security platform that ships with your AI code.
Security AI & Machine Learning Code Execution
21
https://api.arcjet.com/mcp
Superserve
io.github.superserve-ai
MCP server for Superserve sandboxes: create, exec, and manage Firecracker microVMs
Virtualization Code Execution
2417
https://mcp.superserve.ai

Related MCP Servers

Code Sandbox MCP
Code Execution Virtualization
Automata-Labs-team
A
license
Not graded
quality
C
maintenance
An MCP server to create secure code sandbox environment for executing code within Docker containers.
Updated 2 years ago (2025-03-23 12:15 UTC)
327
MIT
@meeseeks-sdk/mcp
Code Execution Testing & QA Tools
abrahamcasanova
A
license
Not graded
quality
D
maintenance
An MCP server that runs a quality gate on generated code, executing it in a sandbox and scoring it before returning the code to the user.
Updated 6 months ago (2026-04-25 02:53 UTC)
5 npm
MIT
code-copy-mcp
File Systems Developer Tools
mhattingpete
A
license
A
quality
D
maintenance
MCP server for copying and pasting code between files with security controls and validation.
Updated 8 months ago (2026-03-06 10:18 UTC)
5
MIT
hardened-terminal-mcp
Shell Access Command Line
Asaad-Suliman
A
license
A
quality
C
maintenance
Security-hardened MCP server that runs only allowlisted commands with no shell, jailed to a single directory, and bounded execution.
Updated 20 days ago (2026-10-16 19:03 UTC)
2
MIT