-
dev-kit-mcp-server
by DanielAvdar
Servidor MCP de Dev-Kit
Un servidor de Protocolo de Contexto de Modelo (MCP) diseñado para herramientas de desarrollo de agentes, que proporciona operaciones autorizadas con alcance en el directorio raíz del proyecto. Este paquete permite la ejecución segura de operaciones como la ejecución de comandos de makefile, el traslado y la eliminación de archivos, y está previsto que incluya más herramientas de edición de código. Es un excelente servidor MCP para VS-Code Copilot y otras herramientas de desarrollo asistidas por IA.
Características
🔒 Operaciones seguras : ejecute operaciones dentro de un directorio raíz autorizado y con alcance
🛠️ Ejecución de comandos Makefile : ejecute comandos Makefile de forma segura dentro del proyecto
📁 Operaciones con archivos : mover, crear, renombrar y eliminar archivos dentro del directorio autorizado
🔄 Operaciones de Git : Realice operaciones de Git como estado, agregar, confirmar, enviar, extraer y verificar
🔌 Integración MCP : Convierte cualquier base de código en un sistema compatible con MCP
🤖 Desarrollo asistido por IA : Excelente integración con VS-Code Copilot y otras herramientas de IA
🔄 Marco extensible : agregue fácilmente nuevas herramientas para la edición de código y otras operaciones
🚀 Rendimiento rápido : Creado con FastMCP para un alto rendimiento
Related MCP server: DiviDen MCP Server
Instalación
pip install dev-kit-mcp-serverUso
Ejecución del servidor
# Recommended method (with root directory specified)
dev-kit-mcp-server --root-dir=workdir
# Alternative methods
uv run python -m dev_kit_mcp_server.mcp_server --root-dir=workdir
python -m dev_kit_mcp_server.mcp_server --root-dir=workdirEl parámetro --root-dir especifica el directorio donde se realizarán las operaciones con archivos. Esto es importante por razones de seguridad, ya que restringe las operaciones con archivos únicamente a este directorio.
Herramientas disponibles
El servidor proporciona las siguientes herramientas:
Operaciones con archivos
create_dir : Crea directorios dentro del directorio raíz autorizado
edit_file : edita archivos reemplazando las líneas entre las líneas de inicio y final especificadas con texto nuevo
move_dir : Mover archivos y directorios dentro del directorio raíz autorizado
remove_file : Elimina archivos dentro del directorio raíz autorizado
rename_file : cambia el nombre de los archivos y directorios dentro del directorio raíz autorizado
Operaciones de Git
git_status : obtiene el estado del repositorio Git (archivos modificados, archivos no rastreados, etc.)
git_add : Agregar archivos al índice de Git (área de preparación)
git_commit : Confirmar cambios en el repositorio Git
git_push : envía cambios a un repositorio Git remoto
git_pull : Extraer cambios desde un repositorio Git remoto
git_checkout : Extrae o crea una rama en el repositorio Git
git_diff : muestra diferencias entre confirmaciones, confirmaciones y árbol de trabajo, etc.
Operaciones de Makefile
exec_make_target : Ejecuta comandos makefile de forma segura dentro del proyecto
Ejemplo de uso con el cliente MCP
from fastmcp import Client
async def example():
async with Client() as client:
# List available tools
tools = await client.list_tools()
# File Operations
# Create a directory
result = await client.call_tool("create_dir", {"path": "new_directory"})
# Move a file
result = await client.call_tool("move_dir", {"path1": "source.txt", "path2": "destination.txt"})
# Remove a file
result = await client.call_tool("remove_file", {"path": "file_to_remove.txt"})
# Rename a file
result = await client.call_tool("rename_file", {"path": "old_name.txt", "new_name": "new_name.txt"})
# Edit a file
result = await client.call_tool("edit_file", {
"path": "file_to_edit.txt",
"start_line": 2,
"end_line": 4,
"text": "This text will replace lines 2-4"
})
# Git Operations
# Get repository status
result = await client.call_tool("git_status")
# Add files to the index
result = await client.call_tool("git_add", {"paths": ["file1.txt", "file2.txt"]})
# Commit changes
result = await client.call_tool("git_commit", {"message": "Add new files"})
# Pull changes from remote
result = await client.call_tool("git_pull", {"remote": "origin", "branch": "main"})
# Push changes to remote
result = await client.call_tool("git_push")
# Checkout a branch
result = await client.call_tool("git_checkout", {"branch": "feature-branch", "create": True})
# Makefile Operations
# Run a makefile command
result = await client.call_tool("exec_make_target", {"commands": ["test"]})Desarrollo
Configuración
# Clone the repository
git clone https://github.com/DanielAvdar/dev-kit-mcp-server.git
cd dev-kit-mcp-server
# Install development dependencies
pip install -e ".[dev]"
# Run tests
pytestContribuyendo
¡Agradecemos sus contribuciones! No dude en enviar una solicitud de incorporación de cambios.
Licencia
Este proyecto está licenciado bajo la licencia MIT: consulte el archivo de LICENCIA para obtener más detalles.
Available Tools
6 toolscreate_dirADestructive
Use instead of terminal: Create a file or folder in the workspace.
Args:
path: Path to the folder to create
Returns:
A dictionary containing the status and path of the created file or folderParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true, indicating this is a mutation operation. The description adds useful context by specifying it creates files/folders in the workspace and mentions the return format. However, it doesn't disclose additional behavioral traits like permission requirements, what happens if the path already exists, or workspace-specific constraints beyond what annotations provide.
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 appropriately sized and front-loaded with the core purpose. The Args and Returns sections are structured but slightly verbose. Every sentence adds value, though the formatting could be more streamlined without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (destructive operation with 1 parameter), the description is reasonably complete. It explains the purpose, parameter, and return format. With an output schema present, it doesn't need to detail return values. However, it could better address behavioral aspects like error conditions or workspace boundaries.
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?
With 0% schema description coverage, the description compensates well by explaining the single parameter: 'path: Path to the folder to create.' This adds meaningful semantics beyond the bare schema. However, it doesn't clarify whether 'folder' includes files, path format requirements, or relative/absolute path handling, leaving some gaps.
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 clearly states the tool's purpose: 'Create a file or folder in the workspace.' This specifies the verb ('create') and resource ('file or folder'), though it doesn't explicitly distinguish it from sibling tools like 'move_dir' or 'rename_file'. The 'Use instead of terminal' context is helpful but doesn't fully differentiate from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context with 'Use instead of terminal' and implies this is for workspace file/folder creation. However, it doesn't explicitly state when to use this tool versus alternatives like 'exec_make_target' or 'predefined_commands', nor does it mention any exclusions or prerequisites for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
exec_make_targetADestructive
Use instead of terminal: Execute Makefile targets.
Args:
commands: List of Makefile targets to execute
Returns:
A dictionary containing the execution results for each target
Raises:
ValueError: If commands is not a listParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| commands | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations include 'destructiveHint: true,' indicating potential destructive behavior. The description adds context by mentioning it returns execution results and raises a ValueError for invalid input, which goes beyond the annotations. However, it doesn't detail what 'destructive' entails (e.g., file modifications, side effects) or other traits like rate limits or auth needs, limiting transparency.
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 appropriately sized and front-loaded with the core purpose. It uses a structured format with Args, Returns, and Raises sections, making it easy to scan. However, the initial phrase 'Use instead of terminal' is somewhat redundant and could be integrated more smoothly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive hint, one parameter), the description is fairly complete. It explains the parameter, return values, and error handling, and with an output schema present, it doesn't need to detail return structure. However, it could better address the destructive nature and sibling tool differentiation.
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?
With 0% schema description coverage, the description compensates by explaining the 'commands' parameter as 'List of Makefile targets to execute' and noting it raises a ValueError if not a list. This adds meaningful semantics beyond the bare schema, though it could elaborate on target format or examples.
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 clearly states the tool's purpose: 'Execute Makefile targets.' It specifies the verb ('Execute') and resource ('Makefile targets'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'predefined_commands' or terminal usage beyond the initial phrase 'Use instead of terminal,' which is somewhat vague.
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?
The description provides implied usage guidance with 'Use instead of terminal,' suggesting this tool is preferred over direct terminal commands for executing Makefile targets. However, it lacks explicit when-to-use rules, alternatives (e.g., when to use 'predefined_commands' instead), or exclusions, leaving some ambiguity in context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
move_dirADestructive
Use instead of terminal: Move a file or folder from path1 to path2.
Args:
path1: Source path of the file or folder to move
path2: Destination path where the file or folder will be moved to
Returns:
A dictionary containing the status and paths of the moved file or folderParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path1 | No | ||
| path2 | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint=true, indicating this is a mutation operation. The description adds that it moves files/folders, which implies destructive behavior, but doesn't elaborate on permissions needed, error handling, or rate limits. It doesn't contradict annotations, and adds minimal context beyond them, such as the return format, but could be more informative.
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 structured with a brief introductory sentence followed by Args and Returns sections, making it easy to parse. It's front-loaded with the main purpose. However, the formatting includes extra whitespace, and some sentences could be more tightly written, but overall it's efficient and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters with 0% schema coverage, annotations for destructive behavior, and an output schema, the description does a good job. It explains the parameters, mentions the return type, and aligns with annotations. For a move operation, it's reasonably complete, though it could add more on error cases or usage constraints.
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?
Schema description coverage is 0%, so the description carries the full burden. It clearly defines path1 as the source path and path2 as the destination path, adding semantic meaning beyond the schema's generic titles. This compensates well for the lack of schema descriptions, though it doesn't detail path formats or constraints.
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 clearly states the verb 'move' and the resource 'a file or folder', specifying it moves from one path to another. It distinguishes from siblings like 'rename_file' by focusing on moving rather than renaming, though it doesn't explicitly contrast with 'create_dir' or 'remove_file'. The purpose is specific but could be more differentiated.
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?
The description includes 'Use instead of terminal', which provides some context for when to use this tool over manual terminal commands. However, it lacks explicit guidance on when to choose this tool versus sibling tools like 'rename_file' or 'remove_file', and doesn't mention prerequisites or exclusions. Usage is implied but not fully detailed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
predefined_commandsADestructive
Use instead of terminal: Execute a predefined command. The command string may include parameters after the command name.
Available commands list: ['check', 'doctest', 'make', 'pytest'].
Args:
command: The command to execute, with optional parameters (e.g., 'test', 'test myparam')
Returns:
A dictionary containing the execution results for the command
Raises:
ValueError: If no command is providedParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the destructiveHint annotation. It specifies the tool executes commands (implying system interaction), lists available commands, mentions parameters can be included, and describes error handling with ValueError. This provides important operational details that the annotation alone doesn't cover, though it could mention more about the destructive nature hinted by the annotation.
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 appropriately sized but not optimally structured. It mixes usage guidance, parameter documentation, and return/error information without clear separation. The formatting with indentation and blank lines is somewhat inconsistent. However, all content is relevant and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (command execution with destructive hint), the description is reasonably complete. It explains the purpose, usage, parameters, returns, and errors. With an output schema present, it doesn't need to detail return values. The main gap is not explicitly addressing the destructive nature hinted by the annotation, but overall it provides good context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining the 'command' parameter in detail: it's the command to execute, may include parameters, provides examples ('test', 'test myparam'), and lists available command values. This adds substantial meaning beyond the bare schema type information.
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 clearly states the tool's purpose: 'Execute a predefined command' with a specific verb ('Execute') and resource ('predefined command'). It distinguishes from sibling tools like 'exec_make_target' by specifying it handles multiple predefined commands rather than just make targets. However, it doesn't explicitly contrast with all siblings like file operations tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: 'Use instead of terminal' and lists available commands, giving guidance on when to use this tool. It doesn't explicitly state when NOT to use it or name alternatives among siblings, but the command list implicitly suggests this tool is for those specific commands rather than general terminal operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
remove_fileADestructive
Use instead of terminal: Remove a file or folder.
Args:
path: Path to the file or folder to remove
Returns:
A dictionary containing the status and path of the removed file or folderParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.8/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations include 'destructiveHint: true,' which already indicates this is a destructive operation. The description adds value by specifying that it removes 'a file or folder' and mentions the return format ('A dictionary containing the status and path'), providing useful context beyond the annotations. No contradiction with annotations is present.
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 well-structured with clear sections for Args and Returns, making it easy to parse. It's appropriately sized with no wasted sentences, though the 'Use instead of terminal' phrase could be more integrated or omitted if redundant, keeping it efficient but not perfect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive operation with one parameter) and the presence of annotations and an output schema, the description is reasonably complete. It covers the purpose, parameter, and return value, though it could benefit from more detailed behavioral warnings or examples to fully compensate for the low schema coverage.
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 schema description coverage is 0%, so the description carries the full burden. It clearly explains the 'path' parameter as 'Path to the file or folder to remove,' adding essential meaning beyond the schema's basic type definition. However, it doesn't detail format constraints or examples, which slightly limits its effectiveness.
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 clearly states the tool's purpose: 'Remove a file or folder.' It specifies the verb ('Remove') and resource ('file or folder'), making it understandable. However, it doesn't explicitly differentiate from sibling tools like 'move_dir' or 'rename_file' beyond the basic action, 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by stating 'Use instead of terminal,' implying this is a higher-level or safer alternative to raw terminal commands. However, it lacks explicit guidance on when to use this tool versus alternatives like 'move_dir' or 'rename_file,' and doesn't mention prerequisites or exclusions, leaving usage somewhat implied rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rename_fileADestructive
Use instead of terminal: Rename a file or folder.
Args:
path: Path to the file or folder to rename
new_name: New name for the file or folder (not a full path, just the name)
Returns:
A dictionary containing the status and paths of the renamed file or folderParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| new_name | No | ||
| path | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations provide destructiveHint=true, indicating this is a mutation operation. The description adds valuable context beyond this by specifying that new_name is 'not a full path, just the name' and mentioning the return format. However, it doesn't cover potential error conditions, permissions needed, or system-specific constraints.
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 well-structured with clear sections (Args, Returns) and uses minimal sentences. The 'Use instead of terminal' phrase could be slightly more integrated, but overall it's efficient and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the destructiveHint annotation, 2 parameters with full semantic coverage in the description, and an output schema (which handles return values), the description is quite complete. It could be improved by mentioning error cases or prerequisites, but it covers the essential context well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by clearly explaining both parameters: 'path' as 'Path to the file or folder to rename' and 'new_name' as 'New name for the file or folder (not a full path, just the name)'. This adds crucial semantic information not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Rename a file or folder') and distinguishes it from sibling tools like 'move_dir' (which likely changes location) and 'remove_file' (which deletes). The opening phrase 'Use instead of terminal' provides additional context about its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Use instead of terminal' and distinguishes this tool from command-line alternatives. It also implicitly differentiates from siblings by focusing on renaming (vs. creating, moving, or removing files/folders), though it doesn't name specific alternatives.
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. Dates show when Glama detected each change.
6 tool updates
v1.0.0- First observed
create_dir - First observed
exec_make_target - First observed
move_dir - First observed
predefined_commands - First observed
remove_file - First observed
rename_file
TDQS
A3.9/5.0
Disambiguation3/5
The tools have some overlap that could cause confusion, particularly between move_dir and rename_file which both handle file/folder modifications, and exec_make_target and predefined_commands which both execute commands. However, the descriptions clarify their specific purposes, such as move_dir for relocation and rename_file for name changes, helping agents differentiate them.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (e.g., create_dir, remove_file, rename_file), which is clear and predictable. The only deviation is predefined_commands, which uses a noun_verb structure, but this minor inconsistency does not significantly hinder readability or pattern recognition.
Tool Count5/5
With 6 tools, the server is well-scoped for a development kit, covering essential file operations and command execution. Each tool serves a distinct purpose, such as directory management and running Makefile or predefined commands, making the count appropriate and efficient for the domain.
Completeness4/5
The toolset provides good coverage for basic development tasks, including create, move, rename, remove, and command execution. A minor gap exists in lacking a tool for reading or listing files/directories, which could be useful for agents to inspect workspace contents, but core workflows are still supported.
Maintenance
ActivityMaintained
ResponsivenessUnresponsive
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Developmental agents for the agent economy: create an agent from a digital genome, then evolve it wi
141The cloud for agents. Tools for AI agents to register, build, and deploy other agents. Zero human required.
Agent Negotiation MCP Server by MEOK AI Labs
Workflow planning, recovery checkpoints, coordination, fixtures, and compatibility tools for agents.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceOpen coordination network for AI agents and their humans. 13 tools for structured coordination, job marketplace, reputation system. Dual-protocol: MCP + A2A. MIT licensed.1MIT
- MIT
- AlicenseNot gradedqualityBmaintenanceA local OKF-compatible knowledge engine for AI agents. Enables capturing agent conversations, hybrid semantic+keyword search, MCP serving to agents, interactive graph visualization, and OKF bundle export.Apache 2.0
Appeared in Searches
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/DanielAvdar/dev-kit-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server