coding-tools-mcp: a permission-gated MCP server that gives chat clients repo access
Give any AI agent the ability to code
At a glance
- What is it?
- xyTom/coding-tools-mcp is an Apache-2.0 Python MCP server that exposes file, patch, exec and git tools to any MCP client, confined to one workspace root and gated by permission modes. Its main trade-off is that the safety boundary is also an operational boundary: one workspace per process, and the most sensitive tool only exists in the mode most people should not run.
- Who is it for?
- Adopt coding-tools-mcp if you want an existing MCP chat client to read, patch, run commands and inspect git inside one repository, and you are willing to accept one workspace root per server process. Do not adopt it if your workflow needs several repositories under one agent session, or if you expect the permission modes to be a substitute for container isolation.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap coding-tools-mcp fills between a chat client and a repository
Most MCP chat clients can call tools. What they lack is a coherent set of tools for editing a codebase: read a file, search across files, apply a multi-file patch, run a command, inspect git history. The README frames the target user directly, describing the project as giving any AI chat or agent a safe pair of hands on your codebase, and the first listed use case is turning Claude Desktop into a coding agent using the subscription the user already has. That is the audience: people who already pay for a chat product and want repository access without adopting a second coding product. The secondary audience is agent builders. The README's seventh use case tells developers writing an agent loop with the Anthropic SDK or anything else not to hand-roll file and exec tools, and to speak MCP to this server instead. The problem is therefore not model capability. It is the absence of a shared, bounded tool surface that several clients can drive identically.
One workspace root, permission modes, and a staged patch primitive
The architecture is a single MCP server process bound to one workspace root. Absolute paths, parent-directory traversal and symlink escapes are rejected, and on Linux the project documents Landlock as adding kernel-level filesystem confinement. Permission modes gate network access, shell expansion, inline scripts and destructive commands. The tool registry holds 19 tools. The default safe and trusted modes advertise 18 of them; dangerous additionally advertises request_permissions, and the README states that dangerous is the only mode in which that tool can grant anything. That is a real design choice worth naming: the permission-granting tool is itself hidden until you have already accepted the least restricted mode. File mutation runs through apply_patch and apply_changes, which the README describes as staged, baseline-checked, atomic across files and supporting rollback. The baseline check is the interesting part. It implies the server records file state before a patch and refuses or rolls back when the file has moved underneath it, which is the failure mode you hit when a human edits the same file the agent is patching. Execution is split across exec_command, write_stdin, read_output and kill_command, so a REPL or debugger can stay alive under a PTY across turns, with deadline watchdogs and bounded buffers. Git is read-only in the advertised catalog: git_status, git_diff, git_log, git_show, git_blame. Nothing in the material shows a git write tool, so committing appears to be out of scope for this server.
Installing it with uvx, npx, or the desktop extra
The server is Python 3.11 or newer from PyPI. The npm package is described as a thin launcher that starts the Python server via uv or pipx, so the Node path is packaging, not a second implementation. The two documented one-liners are:
uvx coding-tools-mcp --stdio --workspace /path/to/repo npx coding-tools-mcp --stdio --workspace /path/to/repo
Client configuration is the same JSON everywhere, with command set to uvx and args set to ["coding-tools-mcp", "--stdio", "--workspace", "/path/to/repo"] under an mcpServers key. Dropping --stdio makes the server speak Streamable HTTP on http://127.0.0.1:8765/mcp. The README says both protocol eras are served on either transport, MCP 2026-07-28 in full with tools as the only advertised capability, plus the handshake era 2025-11-25 with 2025-06-18 compatibility, and that neither has sessions. A GUI is available through python -m pip install "coding-tools-mcp[desktop]" followed by coding-tools-mcp-desktop, which the README says provides per-workspace profiles, server and tunnel start and stop, credential setup and live health checks, in English and Simplified Chinese. Root AGENTS.md and CLAUDE.md files load automatically and are returned in the instructions field of initialize, or of server/discover for a client that never handshakes. Remote access uses an authenticated tunnel with CODING_TOOLS_MCP_AUTH_MODE=bearer, and the README states bearer tokens and OAuth 2.1 with PKCE including RFC 7591 dynamic registration are built in.
The 37% context reduction claim and what it does not tell you
The README states that serialized tool-result bytes dropped 37% release-over-release on a deterministic dogfood workload with unchanged task completion, and that results are summarized, paginated and capped by design. This is the project's own workload, not an independent measurement, and the README does not publish the workload, the byte counts, or the task-completion metric behind it. Treat the direction as plausible and the number as unverified. What is verifiable from the catalog is the mechanism: read_output pages long output, buffers are bounded, and search and listing tools exist as separate calls rather than one unbounded dump. The practical consequence for anyone running a long agent session is that output truncation is a design property, not a bug, and an agent that needs the tail of a long command output has to page for it. The second consequence is that the reduction is measured against this project's previous release, so it says nothing about how the server compares to a different MCP file-tool server.
Where one workspace root per process becomes the wrong tool
The confinement is the point, and it is also the constraint. One workspace root per server means a task that spans a monorepo sibling, a vendored dependency checkout, or a second repository needs a second server entry and a second client configuration. There is no documented multi-root mode. The permission modes are the second limitation. They gate classes of action, but the README's own framing puts kernel-level confinement on Linux via Landlock, which means the strongest boundary is platform-specific; on other platforms the boundary is the path checks and the mode gates. If you want to point an agent at an untrusted pull request, the documented answer is the Docker sandbox built from the repository's Dockerfile and run with -v "$PWD:/workspace", not the permission modes. The README says as much by presenting the container as the way to let an agent loose on untrusted code. A third limit is scope: git tools are read-only, so an agent that needs to commit, branch or push must do so through exec_command and whatever credentials that shell has, which puts that action back outside the structured tool surface. Finally, the catalog is version-sensitive. The README text says the registry contains 19 tools while an earlier line says the default catalog is 18 battle-tested tools; the reconciliation is that 18 are advertised in safe and trusted and request_permissions is the nineteenth, visible only in dangerous. Anyone pinning a version should confirm the advertised set rather than trust a summary sentence.
How it differs from a shell-only MCP server or a built-in editor agent
The closest alternative in kind is a minimal MCP server that exposes a single shell command tool and lets the model do everything through the shell. That approach is simpler to write and has no catalog to keep in sync, but it moves every safety decision into prompt text and shell quoting. coding-tools-mcp takes the opposite route: separate typed tools for reading, searching, patching and git inspection, with path validation applied per tool and patch application staged and baseline-checked. The cost is a larger surface to learn and a catalog whose annotations must stay truthful as the project evolves. A second alternative is the coding agent built into an editor or a vendor CLI, which typically ships its own model routing, its own file-edit format and its own approval UI. That is a more integrated product, but it is also the thing this project is designed to avoid needing: the README's pitch is that the chat client you already use gets repository access, and the server is model-neutral so the client and model can be swapped without changing the runtime contract. If you are already committed to one vendor's agent and its approval flow, this server adds a second configuration surface for little gain.
Release cadence, licence and what to check before upgrading
The repository is Apache-2.0 and not archived, with a last push of 2026-09-03. The visible release history is dense: v0.3.0rc1 and v0.3.0 both landed on 2026-08-13, with v0.2.3 earlier the same day. A release candidate and a final release on the same day, plus three tags inside one day, suggests the project is moving quickly and that a tag may not correspond to a long soak period. Pin an exact version rather than tracking latest, and read the release notes before moving, because the tool catalog and the advertised mode sets are the parts most likely to shift. Apache-2.0 permits commercial use and modification and includes an explicit patent grant, with the usual requirements around preserving notices and stating changes; that is a summary of the licence text, not legal advice, and if you redistribute the server inside a product you should read LICENSE and the NOTICE handling yourself. Maintenance cost is mostly configuration drift: each MCP client stores its own server JSON, so a change to the command, the workspace path or the auth mode has to be repeated per client. The desktop extra exists partly to manage that, with per-workspace profiles and credential setup, but it is an optional install and not a requirement for the stdio path. The Docker and tunnel integrations add their own moving parts, cloudflared or ngrok or Microsoft Dev Tunnel for the remote case, and a Cloudflare Worker control plane plus GitHub Actions for the sandbox dispatch tool, and each of those is a separate thing to keep working.
Editorial conclusion
Adopt coding-tools-mcp if you want an existing MCP chat client to read, patch, run commands and inspect git inside one repository, and you are willing to accept one workspace root per server process. Do not adopt it if your workflow needs several repositories under one agent session, or if you expect the permission modes to be a substitute for container isolation. Before wiring it into a client, verify three things from the repository itself: which of the 19 registry tools your chosen mode advertises, whether Landlock confinement applies on your kernel, and whether the git tools you plan to rely on are read-only in the version you install.
Community notes