让 AI 处理您的本地开发环境，而您则专注于构建令人惊叹的事物！
本地开发环境管理器，可让 LLM 为您配置和管理开发环境。专为 AI 助手构建，可自动处理环境设置、依赖项管理和测试。
Related MCP server: MCP Build Environment Service
从MCP 快速入门指南安装 Claude Desktop
将以下内容添加到您的 Claude Desktop 配置中：
{
"servers": {
"local_dev": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/txbm/mcp-local-dev@main",
"mcp-local-dev"
]
}
}
}将 Claude 指向任何 GitHub 存储库并要求其设置开发环境！
让它运行测试并报告覆盖范围！
如果完成了，就进行讨论、探究或清理！
🧪 pytest 覆盖率报告
⚡️ Vitest 覆盖 V8
🃏 Jest 具有详细的覆盖率指标
🔬 具有覆盖率支持的单元测试
🐍 带有 UV 包管理的 Python
📦 使用 NPM 的 Node.js
⚡️ Bun 运行时和包管理器
🏗️ 自动运行时检测
📦智能包管理器选择
🔒 沙盒环境
🧹 自动清理
🔄 GitHub 存储库支持
📂 本地项目支持
🎯 无需配置
📊 结构化 JSON 日志记录
🔍 详细的测试覆盖率指标
🛡️ 每个项目都有独立的环境
MCP 服务器规范：完全符合全面测试覆盖
路径隔离：每个环境都整齐地包含
系统集成：使用您安装的运行时（Python、Node.js、Bun）
包管理：为每个运行时自动选择最快的可用包管理器
网络访问：包管理的完全连接
进程处理：本机系统进程以实现最大速度
开发涉及多个模型的严格测试：
🏆 Claude 3.5 十四行诗：粉碎它
💪 DeepSeek V3：表现强劲
👎 O1：不太好，鲍勃
该项目展示了人工智能辅助开发的巨大潜力：
🏃♂️ 闪电般快速的原型设计
🎯 最后的 15% 才是真正的工作
📚 现实世界人工智能开发模式的绝佳范例
作为一名在软件开发领域深耕多年的资深人士，我认为这个项目的亮点不仅仅在于自动化，更在于我们与开发环境交互方式的转变。其价值不在于取代人类开发者，而在于减少认知开销。当人工智能负责环境的设置和维护时，开发者可以更加专注于架构和设计决策。
这个项目表明，人工智能不仅仅是生成代码，更是管理复杂性。通过处理开发环境设置的机械环节，我们可以释放更多精力，用于真正需要人类洞察力的创意和架构挑战。
UV——速度恶魔 Python 包安装程序
Aider - 你的AI结对编程伙伴
Anthropic - 感谢 Claude 为开发提供的帮助
Helix Editor - 最佳的模态编辑
麻省理工学院
Clean up a local development environment
| Name | Required | Description | Default |
|---|---|---|---|
| env_id | Yes | Environment identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool performs cleanup but does not specify what actions are taken (e.g., destructive deletion, archiving, or resetting), potential side effects, permission requirements, or error handling. This leaves significant gaps in understanding the tool's behavior and risks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence: 'Clean up a local development environment.' It is front-loaded with the core action and resource, with no unnecessary words or redundancy. Every part of the sentence contributes directly to the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a cleanup operation likely involving destructive actions), lack of annotations, and no output schema, the description is insufficient. It does not explain what 'clean up' entails, what is returned (e.g., success status, logs), or any constraints. For a tool that could have significant side effects, more detail is needed to ensure safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with one parameter ('env_id'), documented as 'Environment identifier.' The description does not add any parameter-specific details beyond the schema, but since there is only one parameter and schema coverage is high, the baseline is elevated. The description implies the parameter identifies the environment to clean up, which aligns with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as 'Clean up a local development environment,' which is clear but vague. It specifies the verb ('clean up') and resource ('local development environment'), but lacks detail on what 'clean up' entails (e.g., deleting files, stopping processes, resetting configurations). It does not differentiate from sibling tools like 'local_dev_from_filesystem' or 'local_dev_run_tests,' which are unrelated operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as when cleanup is needed (e.g., after testing or before deployment), or exclusions, like avoiding use during active development. Without context, the agent must infer usage based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new local development environment from a filesystem path
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Local filesystem path |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool creates something but doesn't specify what 'local development environment' entails, whether it requires specific permissions, if it's destructive to existing environments, or what happens on failure. This leaves significant gaps for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized for a tool with one parameter and gets straight to the point without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations, no output schema, and siblings that suggest complex operations (cleanup, tests), the description is insufficient. It doesn't explain what constitutes a 'local development environment', what gets created, or what the expected outcome is. The agent lacks crucial context to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'path' documented as 'Local filesystem path'. The description adds no additional parameter information beyond what's in the schema. According to guidelines, when schema coverage is high (>80%), the baseline is 3 even with no param info in description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new local development environment') and the resource ('from a filesystem path'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'local_dev_from_github' which serves a similar purpose but from a different source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'local_dev_from_github' or 'local_dev_cleanup'. It lacks any context about prerequisites, when this approach is preferred, or what happens if the path is invalid. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new local development environment from a GitHub repository
| Name | Required | Description | Default |
|---|---|---|---|
| github_url | Yes | GitHub repository URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool creates a local dev environment but lacks details on permissions needed, whether it overwrites existing environments, error handling, or output format. This is a significant gap for a creation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words, making it highly efficient and front-loaded. It directly communicates the core functionality without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a creation operation with no annotations and no output schema, the description is insufficient. It doesn't explain what the created environment entails, how to interact with it, or potential side effects, leaving critical gaps for an AI agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'github_url' documented as 'GitHub repository URL'. The description adds no additional semantic context beyond this, such as URL format examples or validation rules, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('local development environment from a GitHub repository'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'local_dev_from_filesystem' or 'local_dev_cleanup', which would require mentioning the specific GitHub source distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'local_dev_from_filesystem' or 'local_dev_cleanup', nor does it mention prerequisites or exclusions. It merely states what the tool does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Auto-detect and run tests in a local development environment
| Name | Required | Description | Default |
|---|---|---|---|
| env_id | Yes | Environment identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'auto-detect and run tests' but lacks details on permissions, side effects, error handling, or output format. This is inadequate for a tool that likely involves execution in a development environment.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that is front-loaded and contains no wasted words. It directly conveys the core functionality without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, and the tool's potential complexity (running tests in a local environment), the description is insufficient. It does not cover behavioral aspects, return values, or error cases, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'env_id' parameter documented as 'Environment identifier'. The description does not add any further meaning or context about this parameter, so it meets the baseline for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('run tests') and resource ('in a local development environment'), and includes the 'auto-detect' capability. However, it does not explicitly differentiate from sibling tools like local_dev_cleanup or local_dev_from_github, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as the sibling tools listed. There is no mention of prerequisites, context, or exclusions, leaving the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
local_dev_cleanuplocal_dev_from_filesystemlocal_dev_from_githublocal_dev_run_testsEach tool has a clearly distinct purpose: cleanup, creation from filesystem, creation from GitHub, and running tests. There is no overlap in functionality, making it easy for an agent to select the correct tool for each specific task without confusion.
All tool names follow a consistent 'local_dev_' prefix with descriptive suffixes (cleanup, from_filesystem, from_github, run_tests). This snake_case pattern is uniform throughout, making the tools predictable and easy to understand at a glance.
With 4 tools, the count is reasonable for managing local development environments, covering key operations like setup, cleanup, and testing. It might be slightly lean for broader development tasks, but it's well-scoped for the apparent purpose without being overwhelming.
The toolset covers core lifecycle operations: creation (from two sources), cleanup, and testing. Minor gaps might include updating or monitoring environments, but the existing tools provide a solid foundation for basic local development workflows without significant dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Build Apps and run code in 30 languages — sandboxed, with persistent sessions for agent loops.
Run Python code in a secure sandbox without local setup. Declare inline dependencies and execute s…
Execute code in 8 languages (Python, JS, TS, Go, Java, C++, C, Bash) in gVisor sandboxes.
AI-native git hosting — repos, PRs, issues, CI gates, and AI code review over MCP (60 tools).
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/txbm/mcp-local-dev'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
