Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
作者提供的说明(英文原文)
Sandboxed Python execution for AI agents. PEP 723 inline deps, multi-version Python, zero pollution.
这三项永远不会合并成一个分数:意见、测量和人气是不同的东西。
我们还没有为它写通俗的介绍。下面是我们从注册中心读取到的事实。
选择你使用的 AI 应用,然后复制设置。
你需要
你用的是哪个应用?
在上方选择你的应用。我们会记住它,下次按钮会显示“安装到 …”。
打开 Claude Desktop → Settings → Developer → Edit Config,把下面的内容粘贴到 claude_desktop_config.json
{
"mcpServers": {
"python-exec-sandbox": {
"command": "uvx",
"args": [
"mcp-python-exec-sandbox"
]
}
}
}在终端中运行这条命令
claude mcp add python-exec-sandbox -- uvx mcp-python-exec-sandbox粘贴到项目中的 .cursor/mcp.json,或 ~/.cursor/mcp.json
{
"mcpServers": {
"python-exec-sandbox": {
"command": "uvx",
"args": [
"mcp-python-exec-sandbox"
]
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
粘贴到项目中的 .vscode/mcp.json
{
"servers": {
"python-exec-sandbox": {
"type": "stdio",
"command": "uvx",
"args": [
"mcp-python-exec-sandbox"
]
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
这个服务器在你的电脑上运行,而 ChatGPT 只能连接互联网上的服务器。请选择其他应用。
你的选择通过 Cookie 保存在这台设备上,无需账户。
这些设置是根据作者在注册中心的条目生成的。如果 README 的写法不同,请以 README 为准。
它在你的电脑上运行;安装后,工具列表会显示在你的 AI 应用中。
我们检查的是任何人都能看到的信息;我们没有阅读代码。不适用的检查项不计入总数。 · 检查于 2026年11月6日
注册名称已通过 GitHub 账户 lu-zhengda 验证,该账户拥有此仓库
我们还没有从 GitHub 读取这个仓库
我们还没有从 GitHub 读取这个仓库
它在你的电脑上运行,没有互联网端点
在你的电脑上运行,改用本地设置
它在你的电脑上运行;我们只能读取互联网端点的工具列表
与注册中心里这个分类中所有活跃的服务器比较。只有当发布者拥有该仓库时,星标数才计入。
它在 1 项适用的基础检查中通过了 1 项。我们没有阅读代码。在添加密钥或令牌之前,请先看看这个服务器要求哪些权限,并使用只具备所需权限的密钥。
注册中心没有列出必需的密钥,不过有些服务器会在首次使用时要求你登录。
它在你的电脑上运行。你的 AI 应用会在需要时启动它,数据不会经过作者的服务器(除非它自己调用在线服务)。
GitHub 仓库最后更新于–,最新版本(0.1.5)于9个月前进入注册中心。
支持 MCP 的应用,例如 Claude Desktop、Claude Code、Cursor 和 VS Code。你的电脑上还需要有 Python (uv)。
同一分类中有:Spec Driven Development, Remote Desktop Commander, yontu
同一分类中其他作者的服务器,按星标数排序。
如何看卡片:★ GitHub 星标i三大支柱:评价 · 检查 · 使用情况i更新 = 最新版本发布到注册中心的时间i
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
Türkçe yazı denetimi: TDK kuralları, yapay zekâ izleri, metin türüne göre üslup.
按原文从作者的仓库复制。PopNx MCP 没有审查或背书其内容。HTML、图片和脚本已被移除。链接会离开本站。
Sandboxed Python execution for AI agents. Scripts run in ephemeral, isolated environments with inline dependencies (PEP 723) -- zero host pollution, zero leftover venvs, zero package conflicts.
Every coding agent can already run Python on your host. The problem is what happens next: packages accumulate, venvs sprawl, and a rogue pip install breaks your system. mcp-python-exec-sandbox eliminates this:
uv# /// script blocksAll setups require:
uvx for running the server without installing it globally.Additional requirements depend on your chosen sandbox backend:
| Setup | Additional requirements | Install |
|---|---|---|
| Native sandbox (Linux) | bubblewrap | sudo apt install bubblewrap |
| Docker sandbox (macOS, any) | Docker Engine | See Docker docs |
| No sandbox | None | -- |
Host Python vs. execution Python: These are independent. Python 3.13+ is needed to run the server process itself. The
--python-versionflag controls which Python version your *scripts* execute on -- uv downloads the target version automatically. You do not need to install Python 3.14 or 3.15 on your host to run scripts on those versions.
claude mcp add python-sandbox -- uvx mcp-python-exec-sandbox
claude mcp add python-sandbox -- uvx mcp-python-exec-sandbox
The Docker sandbox image is pulled automatically from GHCR on first use. No manual build required.
claude mcp add python-sandbox -- uvx mcp-python-exec-sandbox --sandbox-backend none
Add to .cursor/mcp.json (project-level) or ~/.cursor/mcp.json (global):
{
"mcpServers": { "python-sandbox": { "command": "uvx", "args": ["mcp-python-exec-sandbox"] } } }
codex mcp add python-sandbox -- uvx mcp-python-exec-sandbox
Or add to .codex/config.toml:
[mcp_servers.python-sandbox]
command = "uvx" args = ["mcp-python-exec-sandbox"]
Any client that supports the MCP stdio transport can use this server:
{
"mcpServers": { "python-sandbox": { "command": "uvx", "args": ["mcp-python-exec-sandbox"] } } }
Use --python-version to target a specific Python version. uv downloads it automatically -- no manual install needed.
# Python 3.13 (default)
uvx mcp-python-exec-sandbox --python-version 3.13
uvx mcp-python-exec-sandbox --python-version 3.14
uvx mcp-python-exec-sandbox --python-version 3.15
This works across all sandbox backends. The Docker sandbox uses uv inside the container to manage Python versions, so the same --python-version flag applies.
execute_pythonExecute a Python script with automatic dependency management.
| Parameter | Type | Default | Description |
|---|---|---|---|
script | str | required | Python source code, may include PEP 723 inline metadata |
dependencies | list[str] | [] | Extra PEP 508 dependency specifiers to merge |
timeout_seconds | int | 30 | Maximum execution time (1--300) |
# Simple script
execute_python(script="print('hello world')")
execute_python( script="import requests; print(requests.get('https://httpbin.org/get').status_code)", dependencies=["requests"] )
execute_python(script="""
import pandas as pd print(pd.DataFrame({'a': [1,2,3]}).describe()) """)
check_environmentReturns information about the execution environment: Python version, uv version, platform, sandbox status, and configuration.
validate_scriptValidates a script's PEP 723 metadata and dependencies without executing it.
| Parameter | Type | Default | Description |
|---|---|---|---|
script | str | required | Python source code to validate |
dependencies | list[str] | [] | Extra dependency specifiers to validate |
| Backend | Platform | Tool | Notes |
|---|---|---|---|
native | Linux | bubblewrap | Namespace isolation, network allowed |
docker | Any | Docker | Container isolation, resource limits |
none | Any | -- | No sandboxing (not recommended) |
The default backend is native (bubblewrap) on Linux and docker on macOS/other platforms. Specifying --sandbox-backend native on macOS automatically redirects to Docker. If the sandbox tool is unavailable, the server falls back to none with a warning.
The Docker sandbox image is published to GHCR and pulled automatically when the server starts. No manual setup is needed.
To build locally for development:
docker build -t ghcr.io/lu-zhengda/mcp-python-exec-sandbox profiles/
mcp-python-exec-sandbox [OPTIONS]
Options: --python-version TEXT Python version for execution (default: 3.13) --sandbox-backend TEXT native | docker | none (default: native on Linux, docker on macOS) --max-timeout INT Maximum allowed timeout in seconds (default: 300) --default-timeout INT Default timeout in seconds (default: 30) --max-output-bytes INT Maximum output size in bytes (default: 102400) --no-warm-cache Skip cache warming on startup --uv-path TEXT Path to uv binary (default: uv)
git clone https://github.com/lu-zhengda/mcp-python-exec-sandbox.git
cd mcp-python-exec-sandbox uv sync --dev
src/mcp_python_exec_sandbox/ # Package source
server.py # FastMCP server + tool definitions executor.py # uv subprocess orchestration script.py # PEP 723 metadata parsing/merging sandbox.py # Sandbox ABC + factory sandbox_linux.py # bubblewrap sandbox (Linux) sandbox_docker.py # Docker sandbox (macOS/any) config.py, cache.py, output.py, errors.py tests/ # Unit + integration tests (mocked or local uv) e2e_tests/ # End-to-end tests (require uv + network) profiles/ # Dockerfile, warmup packages .devcontainer/ # Devcontainer for Linux sandbox testing from macOS
Unit and integration tests -- fast, run everywhere:
uv run pytest tests/ -v
E2E tests -- require uv and network access. These exercise real script execution, package installation, MCP protocol flow, and sandbox enforcement:
uv run pytest e2e_tests/ -v
The Docker E2E tests (e2e_tests/test_docker_sandbox.py) verify execution, dependency installation, read-only filesystem enforcement, host isolation, and timeout handling through the Docker backend.
Prerequisites:
docker build -t ghcr.io/lu-zhengda/mcp-python-exec-sandbox profiles/
Then run:
uv run pytest e2e_tests/test_docker_sandbox.py -v
These tests are automatically skipped if Docker is unavailable or the image hasn't been built.
The Linux sandbox tests (e2e_tests/test_sandbox_enforcement.py::test_linux_sandbox_blocks_etc_shadow) use bubblewrap (bwrap) for namespace isolation. They are skipped on macOS because bwrap is Linux-only.
To run them from macOS, use the included devcontainer which provides Ubuntu 24.04 with bwrap pre-installed:
VS Code:
uv run pytest e2e_tests/test_sandbox_enforcement.py -v
CLI:
# Install the devcontainer CLI (once)
npm install -g @devcontainers/cli
devcontainer up --workspace-folder .
devcontainer exec --workspace-folder . uv run pytest e2e_tests/test_sandbox_enforcement.py -v
| Test suite | Command | Requirements |
|---|---|---|
| Unit tests | uv run pytest tests/ -v | uv |
| Integration tests | uv run pytest tests/test_integration.py -v | uv |
| E2E (general) | uv run pytest e2e_tests/ -v | uv, network |
| E2E (Docker sandbox) | uv run pytest e2e_tests/test_docker_sandbox.py -v | uv, Docker, sandbox image |
| E2E (Linux/bwrap sandbox) | uv run pytest e2e_tests/test_sandbox_enforcement.py -v | uv, Linux with bwrap (or devcontainer) |
uv run pytest tests/ -v before committing -- all tests must pass.tests/, E2E in e2e_tests/ if it needs real execution.server.py are user-facing MCP tool descriptions. Write them for an LLM audience.NoopSandbox with a warning.MIT