Development

Develop, test, and verify the Coding Tools MCP runtime.

Development

This page is for contributors and maintainers working on the xyTom/coding-tools-mcp repository.

Important code areas

Area	What to inspect
coding_tools_mcp/server.py	CLI parser, transports, auth, MCP request handling, tool registry, schemas, runtime policy, command execution, file tools, Git tools, and diagnostics.
coding_tools_mcp/__init__.py	Package version exported to server metadata.
pyproject.toml	Python version, package metadata, dependencies, optional extras, and CLI entry point.
tests/	Regression tests for protocol, schemas, safety gates, command behavior, and tool output.
scripts/ and docs/	Helper scripts and operational notes, including remote or tunnel workflows.
benchmarks/	Runtime and dogfood benchmark helpers.

Local setup

git clone https://github.com/xyTom/coding-tools-mcp.git
cd coding-tools-mcp
python -m venv .venv
. .venv/bin/activate
python -m pip install -e '.[dev,image]'

Use .[dev] when you only need linting and typing dependencies. Use .[image] when working on image inspection behavior.

Run the server from source

python -m coding_tools_mcp.server --stdio --workspace /path/to/workspace

or after editable install:

coding-tools-mcp --workspace /path/to/workspace

Checks

The project declares dev dependencies for ruff and mypy. Run the repository’s test and check commands before changing tool behavior, schemas, or safety policy.

Typical local checks are:

python -m pytest
python -m ruff check .
python -m mypy coding_tools_mcp

If a repository script or CI config defines a different authoritative command set, prefer that command set.

Schema changes

When adding or changing a tool:

• Update the tool implementation.
• Update input_schemas().
• Update tool annotations and registry metadata.
• Add or update tests for argument validation, output shape, profile exposure, and failure diagnostics.
• Update the Tools reference page.

Safety changes

Changes to exec_command, path resolution, environment inheritance, Landlock handling, auth, or permission modes should be treated as high-risk. Update tests and documentation together, and make sure the Security boundaries and Limitations pages still match the implementation.

Documentation sync

Documentation should follow code first, then tests and implementation notes, then README. Do not document a tool, flag, environment variable, or behavior unless it is visible in code or supporting repository artifacts.