dev-kit-mcp-server

by DanielAvdar

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.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.
Average 3.9/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 12 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![dev-kit-mcp-server MCP server](https://glama.ai/mcp/servers/DanielAvdar/dev-kit-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/DanielAvdar/dev-kit-mcp-server)

Score Badge

Copy to your README.md:

[![dev-kit-mcp-server MCP server](https://glama.ai/mcp/servers/DanielAvdar/dev-kit-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/DanielAvdar/dev-kit-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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