This server bridges Claude Desktop to your local Windows development environment, giving Claude four developer tools to interact with your local machine.
Read Local Repositories (github_repo_reader): Recursively reads source files from any local repo, returning a directory tree and file contents — automatically skipping .git, node_modules, binaries, and files over 500KB (up to 500 files per call).
Execute Code Snippets (code_executor): Runs self-contained Python or Node.js code in a sandboxed process with a 15-second timeout and 64KB output cap — ideal for quick calculations, data transformations, and logic testing with no persistent state between calls.
Search Local Documentation (doc_search): Performs case-insensitive, multi-keyword full-text search across a local docs folder, supporting a wide range of file types (.md, .txt, .json, .yaml, .py, .ts, .js, .sh, etc.) with surrounding context returned for each match.
Run Terminal Commands (terminal_commander): Executes safe Windows CMD or PowerShell commands (e.g., git status, dir, npm install, ipconfig) via a strict allowlist, with dangerous patterns (e.g., rm -rf, format C:, shutdown) blocked automatically — supports custom working directories and optional PowerShell mode.
Allows running Docker commands on the local machine, such as managing containers and images, through the terminal commander tool.
Allows reading local Git repositories and executing Git commands (e.g., status, log, diff) via the terminal commander tool.
Enables executing Node.js code snippets in an isolated sandbox via the code executor tool.
Provides ability to run npm commands (e.g., install, build) via the terminal commander tool.
Enables executing Python code snippets in an isolated sandbox via the code executor tool.
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., "@AI Dev Assistant Read my repo at C:\Projects\my-api and explain the architecture."
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.
A production-ready Model Context Protocol (MCP) Server that bridges Claude Desktop directly to your local Windows 10 development environment. Give Claude the ability to read your code, run scripts, search docs, and execute safe terminal commands — all without leaving the chat.
This server extends Claude Desktop with four powerful developer tools:
Tool | What It Does |
| Recursively reads any local repo (ignores |
| Runs Python or Node.js snippets in isolated child processes |
| Full-text keyword search across your local |
| Executes safe CMD/PowerShell commands via a strict allowlist |
Related MCP server: copilot-studio-code
ai-dev-assistant-mcp/
├── main.py ← MCP server entry point & tool implementations
├── pyproject.toml ← Python project configuration
├── claude_desktop_config.json ← Example Claude Desktop config block
└── README.mdPython 3.8+ — verify with python --version
Node.js (optional, only needed for the code_executor Node.js runtime)
Claude Desktop installed
uv (optional, for faster installs) or pip
Place this project folder somewhere permanent, for example:
C:\ai-dev-assistant-mcp\⚠️ Do not move the folder later — Claude Desktop will reference the script path.
Open a terminal in the project root and run:
cd C:\ai-dev-assistant-mcp
pip install -e .Or with uv:
uv pip install -e .Open (or create) the Claude Desktop config file at:
%APPDATA%\Claude\claude_desktop_config.jsonPaste in the following block (adjust the path if you placed the project elsewhere):
{
"mcpServers": {
"ai-dev-assistant": {
"command": "python",
"args": [
"C:\\ai-dev-assistant-mcp\\main.py"
],
"env": {}
}
}
}💡 Already have other MCP servers? Just add the
"ai-dev-assistant"key inside your existing"mcpServers"object.
Fully quit and relaunch Claude Desktop. You should see the 🔧 tools icon in the chat input bar — click it to confirm all four tools appear.
The terminal_commander tool will refuse to run any command whose base name is not on the explicit allowlist in main.py:
SAFE_COMMANDS_ALLOWLIST = {
"dir", "ls", "git", "node", "npm", "npx", "python",
"tsc", "docker", "ipconfig", "ping", "whoami", ...
}Additionally, even allowlisted commands are blocked if they match any dangerous pattern:
rm -rf del /s format C: shutdown
taskkill net user netsh Invoke-Expression
curl | bash registry edits UAC elevation ...To add a new command, edit SAFE_COMMANDS_ALLOWLIST in main.py.
Scripts run in isolated temp files — no persistent state between calls
15-second hard timeout — runaway processes are killed automatically
64 KB output cap — prevents memory exhaustion from verbose output
Temp files are deleted immediately after execution
Ignores: .git, node_modules, .next, dist, __pycache__, .venv, etc.
Skips: binary files, images, archives, .lock files
500 KB per-file cap — large generated files are skipped automatically
500 file maximum per call
Once connected to Claude Desktop, you can ask Claude:
"Read my repo at C:\Projects\my-api and explain the architecture."
"Run this Python script and tell me the output:
import json; print(json.dumps({'status': 'ok', 'count': 42}))"
"Search my docs folder at C:\Projects\my-api\docs for 'authentication'"
"Run git status in C:\Projects\my-api"
"What files are in C:\Projects? Run dir."python main.pyAdd a new @Tool() decorated function in main.py
The server will automatically register it
Windows paths use backslashes. In JSON config files, always double-escape them:
"C:\\Users\\YourName\\Projects\\my-repo"In Claude prompts, you can use either style — the tools normalize paths internally using pathlib.Path.resolve().
Layer | Technology |
Language | Python 3.8+ |
MCP SDK |
|
Process execution |
|
Transport | stdio (standard MCP transport) |
┌─────────────────────────────────────────────────┐
│ Claude Desktop │
│ ┌─────────────────────────────────────────────┐ │
│ │ Claude AI (Claude Sonnet / Opus) │ │
│ │ → Decides which tool to call │ │
│ └─────────────┬───────────────────────────────┘ │
└────────────────┼────────────────────────────────┘
│ MCP Protocol (stdio JSON-RPC)
┌────────────────▼────────────────────────────────┐
│ AI Dev Assistant MCP Server │
│ ┌──────────────┐ ┌──────────────────────────┐ │
│ │ Repo Reader │ │ Code Executor │ │
│ │ (pathlib) │ │ (asyncio.subprocess) │ │
│ └──────────────┘ └──────────────────────────┘ │
│ ┌──────────────┐ ┌──────────────────────────┐ │
│ │ Doc Search │ │ Terminal Commander │ │
│ │ (os.walk) │ │ (cmd.exe / pwsh.exe) │ │
│ └──────────────┘ └──────────────────────────┘ │
└─────────────────────────────┬───────────────────┘
│
┌───────────────▼───────────────┐
│ Windows 10 File System │
│ Python / Node Runtimes │
│ Git / npm / Docker │
└───────────────────────────────┘Claude sends a tool-call request over stdio. The MCP server validates it, executes the appropriate handler, and returns formatted Markdown back to Claude — which presents it naturally in the conversation.
MIT — free to use, modify, and build upon.
Executes a small Python or Node.js code snippet in a sandboxed child process. Hard limits: 15 second timeout, 64 KB output cap. The snippet runs in an isolated temp file — no persistent state between calls. Ideal for quick calculations, data transformations, and API-free logic.
| Name | Required | Description | Default |
|---|---|---|---|
| language | Yes | The language runtime to use: 'python' or 'node'. | |
| code | Yes | The code snippet to execute. Keep it self-contained. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and effectively discloses key behavioral traits: it specifies hard limits (15-second timeout, 64 KB output cap), isolation (runs in isolated temp file), and statelessness (no persistent state between calls). It does not cover aspects like error handling or security implications, but provides substantial operational context.
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 front-loaded with core functionality and efficiently structured in three sentences: the first states purpose and constraints, the second details isolation, and the third provides usage context. Every sentence adds value without redundancy, making it appropriately sized and zero-waste.
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 moderate complexity (code execution with constraints), no annotations, and no output schema, the description is largely complete: it covers purpose, behavioral limits, and usage context. However, it lacks details on return values or error responses, which would be helpful for an agent invoking the tool.
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?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds minimal value beyond the schema, mentioning 'self-contained' for the code parameter but not elaborating on syntax or constraints. Baseline 3 is appropriate as the schema does the heavy lifting.
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 executes code snippets in specific languages (Python/Node.js) in a sandboxed environment, distinguishing it from sibling tools like doc_search or terminal_commander by focusing on code execution rather than document retrieval or system commands. It specifies the action ('executes'), resource ('code snippet'), and context ('sandboxed child process').
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 clear context for when to use this tool ('ideal for quick calculations, data transformations, and API-free logic'), but does not explicitly state when not to use it or name alternatives among siblings. It implies usage for small, stateless tasks but lacks explicit exclusions or comparisons to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches all documents in a local docs/ folder (or any directory) for one or more keywords. Supports case-insensitive multi-keyword search across markdown, text, JSON, YAML, code, and other text files. Returns matching lines with surrounding context. Searchable extensions: .md, .txt, .rst, .html, .json, .yaml, .ts, .js, .py, .sh, .bat, .ps1, and more.
| Name | Required | Description | Default |
|---|---|---|---|
| docs_path | Yes | Absolute path to the docs folder to search. Windows example: C:\Users\YourName\Projects\my-repo\docs | |
| keywords | Yes | List of keywords to search for. All keywords must appear on the same line (AND logic). | |
| case_sensitive | No | Whether the search is case-sensitive. Default: false. | |
| file_extension_filter | No | Optional: only search files with this extension (e.g., '.md', '.txt'). Leave blank to search all supported file types. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses some behavioral traits like case-insensitive search, multi-keyword AND logic, and supported file extensions, but misses critical details such as error handling (e.g., invalid paths), performance limits, output format specifics, or whether it's read-only/destructive. This leaves gaps for an agent to use it correctly.
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 appropriately sized and front-loaded, starting with the core purpose. It uses two sentences efficiently, though the second sentence is slightly dense with file extension details. Overall, it avoids unnecessary repetition and wastes little space.
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 no annotations and no output schema, the description is moderately complete for a search tool but has gaps. It covers what the tool does and some behavioral aspects, but lacks details on output format, error conditions, and performance constraints, which are important for an agent to invoke it effectively without structured output guidance.
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?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema, mentioning 'case-insensitive' (covered by case_sensitive default) and 'searchable extensions' (implied by file_extension_filter), but does not provide additional syntax or format details. Baseline 3 is appropriate as the schema does the heavy lifting.
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 specific verbs ('searches all documents') and resources ('local docs/ folder'), and distinguishes it from siblings by specifying it searches documents rather than executing code, reading repos, or running terminal commands. It provides concrete details about supported file types and search behavior.
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 implies usage for searching documents in a folder, but does not explicitly state when to use this tool versus alternatives like sibling tools (e.g., github_repo_reader for remote repos). It mentions the default directory ('docs/') but lacks explicit guidance on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recursively reads all source files in a local repository directory. Automatically ignores .git, node_modules, binary files, and large files (>500KB). Returns a directory tree and the full content of each readable file.
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | Yes | Absolute path to the local repository root. Windows example: C:\Users\YourName\Projects\my-repo | |
| max_files | No | Maximum number of files to return (default: 100, max: 500). |
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 effectively describes key behaviors: recursive traversal, automatic ignoring of specific directories and file types, handling of binary and large files, and the return format (directory tree and file contents). This gives the agent clear expectations without contradictions.
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 front-loaded with the core purpose in the first sentence, followed by essential behavioral details in a compact form. Every sentence adds value (e.g., filtering rules and return format), with no redundant or vague language, making it highly efficient and easy to parse.
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 moderate complexity (recursive file reading with filters), no annotations, and no output schema, the description does a good job covering behavior and output. It explains what is returned (directory tree and file contents) and key constraints, though it could benefit from mentioning error handling or performance implications for large repositories.
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?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description does not add any additional meaning or context beyond what the schema provides for 'repo_path' and 'max_files', such as usage examples or constraints not in the schema. Baseline 3 is appropriate as the schema handles parameter documentation.
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 specific verbs ('reads', 'returns') and resources ('all source files in a local repository directory'). It distinguishes itself from potential siblings by specifying recursive reading with automatic filtering of common directories and file types, which is not implied by the tool name alone.
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 implies usage context through details like 'local repository directory' and filtering of '.git', 'node_modules', etc., suggesting it's for analyzing codebases. However, it does not explicitly state when to use this tool versus alternatives like 'doc_search' or 'code_executor', nor does it provide exclusions or prerequisites for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Executes a safe Windows CMD or PowerShell command on the local machine. Protected by a strict allowlist — only pre-approved commands are permitted. Dangerous patterns (rm -rf, del /s, format, shutdown, registry edits, etc.) are blocked even if the base command is allowed. Allowed commands include: dir, git, node, npm, python, tsc, docker, ipconfig, and more. Use this to run git status, dir, npm install, tsc --noEmit, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | The full command to execute. Examples: 'git status', 'dir C:\Projects', 'npm run build', 'ipconfig /all' | |
| working_directory | No | Optional: Absolute path to set as the working directory before executing. Windows example: C:\Users\YourName\Projects\my-repo | |
| use_powershell | No | If true, runs the command via PowerShell instead of CMD. Default: false (uses CMD on Windows, /bin/sh on others). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does an excellent job disclosing key behavioral traits: safety mechanisms (strict allowlist, blocked dangerous patterns), platform specifics (Windows CMD/PowerShell), and examples of allowed commands. It doesn't cover error handling or output format, but provides substantial operational context.
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 appropriately sized and front-loaded with the core purpose and safety constraints, followed by specific examples. Every sentence adds value, though the list of allowed commands could be slightly more concise.
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 tool with no annotations and no output schema, the description provides excellent context about safety constraints, allowed commands, and usage examples. It doesn't describe the return format or error behavior, but covers most essential operational aspects given the complexity.
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?
Schema description coverage is 100%, so the schema already fully documents all three parameters. The description adds no additional parameter information beyond what's in the schema, meeting the baseline expectation when schema coverage is complete.
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 specific verbs ('executes') and resources ('Windows CMD or PowerShell command on the local machine'), and distinguishes it from siblings by focusing on safe command execution rather than code execution, document search, or GitHub 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?
It explicitly defines when to use this tool ('to run git status, dir, npm install, tsc --noEmit, etc.') and provides clear alternatives by naming sibling tools (code_executor, doc_search, github_repo_reader), though it doesn't explicitly state when not to use it beyond the allowlist constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose with no overlap: code_executor runs code snippets, doc_search searches documents, github_repo_reader reads repository files, and terminal_commander executes system commands. The descriptions make it easy to differentiate between them, as they target different resources and use cases.
The naming follows a consistent snake_case pattern with descriptive names (e.g., code_executor, doc_search), but there is a minor deviation with github_repo_reader using a compound term that could be more aligned (e.g., repo_reader). Overall, the naming is readable and mostly predictable.
With 4 tools, the count is well-scoped for an AI Dev Assistant, covering key development tasks like code execution, documentation search, repository reading, and terminal commands. Each tool earns its place without feeling excessive or insufficient for the server's purpose.
The tool set covers essential development workflows, including code execution, documentation, repository management, and system operations. A minor gap exists in not having tools for more advanced tasks like debugging or version control beyond basic commands, but agents can work around this with the provided tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Source-checked CLI guides and model-aware planning for Claude Code, Codex, and Grok Build.
Let ChatGPT, Claude & Cursor use your Mac: email, calendar, iMessage, Teams, files. Local, free.
Persistent memory for Claude Code and Cursor. Stop re-explaining your project every session.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/pathakkhhimanshu/MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
