Supports Bun runtime and package manager for JavaScript/TypeScript development environments
Allows setting up development environments from GitHub repositories
Integrates with Helix Editor for modal editing capabilities
Provides Jest test runner with detailed coverage metrics for JavaScript/TypeScript projects
Supports Node.js runtime for JavaScript/TypeScript development environments
Supports NPM package management for JavaScript/TypeScript projects
Provides pytest test runner with coverage reporting for Python projects
Supports Python runtime with UV package management for development environments
Provides Vitest test runner with V8 coverage for JavaScript/TypeScript projects
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-local-dev set up a dev environment for https://github.com/example/my-python-app and run tests with coverage"
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.
Let AI handle your local development environments while you focus on building amazing things!
A local development environment manager that lets LLMs configure and manage dev environments for you. Built for AI assistants to handle environment setup, dependency management, and testing automatically.
Related MCP server: MCP Build Environment Service
Install Claude Desktop from the MCP quickstart guide
Add the following to your Claude Desktop config:
{
"servers": {
"local_dev": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/txbm/mcp-local-dev@main",
"mcp-local-dev"
]
}
}
}Point Claude at any GitHub repository and ask it to set up a dev environment!
Have it run the tests and report coverage!
Have a discussion, poke around or clean it up if you're done!
🧪 pytest with coverage reporting
⚡️ Vitest with V8 coverage
🃏 Jest with detailed coverage metrics
🔬 unittest with coverage support
🐍 Python with UV package management
📦 Node.js with NPM
⚡️ Bun runtime and package manager
🏗️ Automatic runtime detection
📦 Smart package manager selection
🔒 Sandboxed environments
🧹 Automatic cleanup
🔄 GitHub repository support
📂 Local project support
🎯 Zero configuration needed
📊 Structured JSON logging
🔍 Detailed test coverage metrics
🛡️ Isolated environments per project
MCP Server Spec: Full compliance with comprehensive test coverage
Path Isolation: Each environment is neatly contained
System Integration: Uses your installed runtimes (Python, Node.js, Bun)
Package Management: Automatically selects fastest available package manager for each runtime
Network Access: Full connectivity for package management
Process Handling: Native system processes for maximum speed
Development involved rigorous testing across multiple models:
🏆 Claude 3.5 Sonnet: Crushed it
💪 DeepSeek V3: Strong performer
👎 O1: Not great, Bob
This project demonstrates the incredible potential of AI-assisted development:
🏃♂️ Lightning fast prototyping
🎯 That last 15% is still where the real work happens
📚 Great example of real-world AI development patterns
As someone who's spent years in software development, what's exciting about this project isn't just automation - it's the shift in how we interact with development environments. The value isn't in replacing human developers, but in reducing cognitive overhead. When AI handles environment setup and maintenance, developers can focus more on architecture and design decisions.
This project demonstrates that AI isn't just about generating code - it's about managing complexity. By handling the mechanical aspects of development environment setup, we free up mental bandwidth for the creative and architectural challenges that truly need human insight.
UV - Speed demon Python package installer
Aider - Your AI pair programming buddy
Anthropic - For Claude's assistance in development
Helix Editor - Modal editing at its finest
MIT
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
