¡Deja que AI se encargue de tus entornos de desarrollo locales mientras tú te concentras en crear cosas increíbles!
Un gestor de entornos de desarrollo local que permite a los LLM configurar y gestionar entornos de desarrollo. Diseñado para que los asistentes de IA gestionen automáticamente la configuración del entorno, la gestión de dependencias y las pruebas.
Related MCP server: MCP Build Environment Service
Instale Claude Desktop desde la guía de inicio rápido de MCP
Agregue lo siguiente a su configuración de Claude Desktop:
{
"servers": {
"local_dev": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/txbm/mcp-local-dev@main",
"mcp-local-dev"
]
}
}
}¡Señala a Claude cualquier repositorio de GitHub y pídele que configure un entorno de desarrollo!
¡Haga que ejecute las pruebas y reporte la cobertura!
¡Ten una discusión, investiga un poco o límpialo si terminaste!
🧪 pytest con informes de cobertura
⚡️ Vitest con cobertura V8
🃏 Jest con métricas de cobertura detalladas
Prueba unitaria con soporte de cobertura
🐍 Python con gestión de paquetes UV
📦 Node.js con NPM
⚡️ Tiempo de ejecución de Bun y administrador de paquetes
🏗️ Detección automática del tiempo de ejecución
📦 Selección de gestor de paquetes inteligente
Entornos sandbox
🧹 Limpieza automática
Compatibilidad con repositorios de GitHub
📂 Apoyo a proyectos locales
🎯 No se necesita configuración
📊 Registro JSON estructurado
🔍 Métricas detalladas de cobertura de pruebas
🛡️ Entornos aislados por proyecto
Especificaciones del servidor MCP : Cumplimiento total con una cobertura de pruebas integral
Aislamiento de ruta : cada entorno está perfectamente contenido
Integración del sistema : utiliza los entornos de ejecución instalados (Python, Node.js, Bun)
Gestión de paquetes : selecciona automáticamente el administrador de paquetes más rápido disponible para cada entorno de ejecución
Acceso a la red : Conectividad completa para la gestión de paquetes
Manejo de procesos : Procesos nativos del sistema para máxima velocidad
El desarrollo implicó pruebas rigurosas en múltiples modelos:
🏆 Claude 3.5 Soneto: Lo aplastó
💪 DeepSeek V3: Un rendimiento potente
👎 O1: No muy bien, Bob
Este proyecto demuestra el increíble potencial del desarrollo asistido por IA:
🏃♂️ Prototipado ultrarrápido
🎯 Ese último 15% es todavía donde ocurre el verdadero trabajo.
📚 Gran ejemplo de patrones de desarrollo de IA en el mundo real
Como alguien con años de experiencia en desarrollo de software, lo emocionante de este proyecto no es solo la automatización, sino el cambio en nuestra interacción con los entornos de desarrollo. El valor no reside en reemplazar a los desarrolladores humanos, sino en reducir la sobrecarga cognitiva. Cuando la IA gestiona la configuración y el mantenimiento del entorno, los desarrolladores pueden centrarse más en las decisiones de arquitectura y diseño.
Este proyecto demuestra que la IA no se trata solo de generar código, sino de gestionar la complejidad. Al gestionar los aspectos mecánicos de la configuración del entorno de desarrollo, liberamos recursos mentales para los desafíos creativos y arquitectónicos que realmente requieren la comprensión humana.
UV - Instalador de paquetes Python de Speed Demon
Aider - Tu compañero de programación de IA en pareja
Antrópico - Por la ayuda de Claude en el desarrollo
Helix Editor : la edición modal en su máxima expresión
Instituto Tecnológico de Massachusetts (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
