MCP Debugger
# mcp-debugger
<div align="center">
<img src="assets/logo.png" alt="MCP Debugger Logo - A stylized circuit board with debug breakpoints" width="400" height="400">
</div>
**A headless, agentic debugger over MCP β let your AI agents debug running programs in eight languages.**
[](https://github.com/debugmcp/mcp-debugger/actions/workflows/ci.yml)
[](https://codecov.io/gh/debugmcp/mcp-debugger)
[](https://www.npmjs.com/package/@debugmcp/mcp-debugger)
[](https://hub.docker.com/r/debugmcp/mcp-debugger)
[](./LICENSE)
[](https://scorecard.dev/viewer/?uri=github.com/debugmcp/mcp-debugger)
[](https://www.bestpractices.dev/projects/13543)
## π― Overview
mcp-debugger is a Model Context Protocol (MCP) server that exposes step-through debugging as structured tool calls. It lets AI agents set breakpoints, inspect variables, evaluate expressions, and step through running programs across eight languages β driving real language debuggers through the Debug Adapter Protocol (DAP).
**No IDE required.** mcp-debugger runs anywhere Node.js runs: CI runners, Docker containers, Kubernetes pods, SSH boxes, and the sandboxes that cloud coding agents live in. It's the debugger for where IDEs can't go.
### When to use mcp-debugger vs an IDE-bound debug server
Microsoft's [DebugMCP](https://github.com/microsoft/DebugMCP) exposes VS Code's debugger over MCP and is a good choice when your agent works *inside* a running VS Code. The two projects make different structural trade-offs:
| | mcp-debugger | microsoft/DebugMCP |
|---|---|---|
| Runs headless (CI, containers, k8s, cloud agents) | β
standalone Node process | β requires a running VS Code |
| Transports | stdio + Streamable HTTP | Streamable HTTP (localhost) |
| Distribution | npx, npm, Docker image | VS Code Marketplace extension |
| Remote attach without an IDE | β
debugpy / rdbg / JDWP, incl. pods via port-forward | β |
| Per-session process isolation | β
one proxy process per session | shares the VS Code instance |
| Java hot-swap (`redefine_classes`) | β
| β |
| Debuggee output as subscribable MCP resource | β
| β |
| In-IDE debugging UX alongside the agent | β
read-only IDE mirror ([`expose_session`](docs/tool-reference.md#expose_session)) β the IDE joins the *agent's* live session | β
native |
| Logpoints without pausing (prod-safe value watching) | β
[`logMessage` breakpoints](docs/tool-reference.md#set_breakpoint) | β
via VS Code |
| Content/function-addressed breakpoints (`statement:`, `function:`, `expectedContent`) | β
agent-native addressing that survives edits | β |
| Secret redaction on by default | β
variable/evaluate/output masking + least-privilege mode | β |
| Kubernetes ephemeral debug sidecar (native attach-by-PID) | β
[`kubectl debug` flow](docs/kubernetes.md) | β |
| C/C++ | β
via CodeLLDB (launch + attach-by-PID) | β
via VS Code extensions |
| PHP | β | β
via VS Code extensions |
| Languages | Python, JS/TS, Ruby, Rust, Go, Java, .NET, C/C++ | Python, JS/TS, Ruby, Rust, Go, Java, .NET, C/C++, PHP |
If your agent runs in a terminal, a pipeline, or a cloud sandbox β or needs to attach to a process on another machine β you want mcp-debugger.
> π **v0.24.0** β **C/C++ debugging** lands (CodeLLDB: prebuilt binaries, auto-compiled single sources, attach by PID), alongside statement/function-addressed breakpoints, logpoints, `restart_debugging`, breakpoint management tools, buffered `get_output`, break-on-uncaught-exceptions by default, a read-only IDE mirror (`expose_session`), default-on secret redaction, and a multi-language Docker image (Python, JS, Java, Rust, C/C++ native; Ruby attach). See the [CHANGELOG](./CHANGELOG.md) for the full release history.
## β¨ Key Features
- π **Multi-language support** β Clean adapter pattern for any language
- π **Python debugging via debugpy** β Full DAP protocol support
- π **Ruby debugging via rdbg** β Launch and attach workflows, including remote attach to containers and Kubernetes pods
- π¨ **JavaScript (Node.js) debugging via js-debug** β VSCode's proven debugger
- π¦ **Rust debugging via CodeLLDB** β Debug Rust & Cargo projects (Linux/macOS; Windows needs the GNU toolchain β see [Rust on Windows](docs/rust-debugging-windows.md))
- πΉ **Go debugging via Delve** β Full DAP support for Go programs
- β **Java debugging via JDI bridge** β Launch and attach modes with JDK 21+
- π· **.NET/C# debugging via netcoredbg** β Debug .NET applications with full DAP support
- βοΈ **C/C++ debugging via CodeLLDB** β Launch prebuilt binaries or lone source files (auto-compiled), attach by PID; core dumps and gdbserver/rr targets via config pass-through
- π§ͺ **Mock adapter for testing** β Test without external dependencies
- π°οΈ **Out-of-IDE & remote attach** β Attach over host/port to a process on another machine or inside a container (Python via debugpy, Ruby via rdbg, JavaScript via the V8 inspector, Java via JDWP) with source-path mapping, or by PID for native code (C/C++). Python and Ruby attach *direct-connect* β the debug engine already runs inside the target, so no local Python or Ruby is needed; JavaScript, Java, .NET and C/C++ spawn a local adapter instead; of those, only Java (a JDK) and .NET (netcoredbg) need a toolchain you install, since the JavaScript and C/C++ debug engines ship with the package. `list_supported_languages` reports per-mode availability with reasons
- π― **Breakpoints that survive edits** β Address by content (`statement: "total = sum(prices)"`), by symbol (`function: "main"`), or assert line content with `expectedContent`; anchors re-resolve across `restart_debugging` and weak matches warn loudly
- πͺ΅ **Logpoints** β `set_breakpoint` with `logMessage: "x={x}"` streams interpolated values into `get_output` without pausing β prod-safe value watching on hot paths
- π§° **Full breakpoint lifecycle** β `list_breakpoints` / `remove_breakpoint` / `clear_breakpoints` work live mid-run; `restart_debugging` relaunches with the same config and re-applies everything in one call
- π‘ **Buffered program output** β `get_output` returns debuggee stdout/stderr with a cursor, and each session exposes its transcript as a subscribable MCP resource
- π₯ **Crash-state debugging by default** β Launch sessions pause on uncaught exceptions with stack and locals live (`breakOnExceptions`; exception class/message surfaced via `lastStop`)
- πͺ **Read-only IDE mirror** β `expose_session` opens a loopback, token-gated DAP endpoint so a human's IDE can inspect the agent's live session without taking control
- βΈοΈ **Kubernetes debugging** β port-forward attach for interpreted runtimes, `kubectl debug --target` + attach-by-PID for native processes ([recipe](docs/kubernetes.md), [turnkey manifests](examples/kubernetes/))
- π **STDIO and Streamable HTTP transports** β Works with any MCP client (legacy SSE transport is deprecated)
- π¦ **Zero-runtime dependencies** β Self-contained bundles via esbuild + tsup
- β‘ **npx ready** β Run directly with `npx @debugmcp/mcp-debugger` - no installation needed
- π³ **Docker and npm packages** β Deploy anywhere
- π€ **Built for AI agents** β Structured JSON responses for easy parsing
- π **Secret redaction on by default** β Credential-shaped values (API keys, tokens, private keys) are masked as labeled placeholders in variable, evaluate, and output results before they reach the agent ([details](./docs/tool-reference.md#secret-redaction); opt out with `DEBUG_MCP_NO_REDACT=1`)
- π‘οΈ **Path validation** β Prevents crashes from non-existent files
- π **AI-aware line context** β Intelligent breakpoint placement with code context
- β
**Comprehensive test suite** β unit, integration, and end-to-end coverage across every adapter ([CI status](https://github.com/debugmcp/mcp-debugger/actions/workflows/ci.yml))
## π§ Agent Skill
Tools tell an agent *what* it can do; a skill teaches it *how to debug well*. This repo ships an [agent skill](skills/debugging/) covering the session golden path, root-cause discipline (bisection over line-by-line stepping), attach/remote recipes, and per-language quirks:
```bash
# Claude Code (user-level)
cp -r skills/debugging ~/.claude/skills/mcp-debugger
# Cross-agent directories (Copilot CLI and friends)
cp -r skills/debugging ~/.agents/skills/mcp-debugger
```
The server also serves condensed guidance in-band: MCP `instructions` on connect, plus a `debugging-workflow` prompt any MCP client can request. See [skills/debugging/README.md](skills/debugging/README.md) for details.
## π¬ See It In Action
- **[Auto-debug failing CI tests](.github/actions/debug-failing-test/)** β a composite GitHub Action that launches mcp-debugger + an agent on a test failure and posts the root-cause analysis
- **[Sick pod walkthrough](examples/sick-pod/)** β attach to a misbehaving Python service in Kubernetes via port-forward ([tutorial](docs/jit-diagnostics/README.md))
- **[Native sick pod](examples/sick-pod-cpp/)** β same story for compiled code: ephemeral debug sidecar + attach-by-PID, no in-process agent required
## π Quick Start
> **Requirements:** Node.js 22+ for the server. Each language you debug also needs its own toolchain installed (Python + debugpy, Ruby + the `debug` gem / `rdbg`, Node.js, Go + Delve, JDK 21+, .NET SDK, the Rust toolchain, or a C/C++ compiler β g++/clang++, only needed for source-file launch). Not sure what's installed? Run `npx @debugmcp/mcp-debugger doctor` for a per-adapter toolchain report.
>
> **CodeLLDB platform note (npx/npm installs):** the CodeLLDB debug engine ships as per-platform optional dependencies (`@debugmcp/codelldb-win32-x64`, `-darwin-x64`, `-darwin-arm64`, `-linux-x64`, `-linux-arm64`) β npm installs exactly the one matching your platform, so Rust and C/C++ debugging work out of the box everywhere npm serves. If you install with `--omit=optional`, set `CODELLDB_PATH` to a [CodeLLDB release](https://github.com/vadimcn/codelldb/releases) binary instead, or use the Docker image.
### For MCP Clients (Claude Desktop, etc.)
Add to your MCP settings configuration:
```json
{
"mcpServers": {
"mcp-debugger": {
"command": "node",
"args": ["C:/path/to/mcp-debugger/dist/index.js", "stdio", "--log-level", "debug", "--log-file", "C:/path/to/logs/debug-mcp-server.log"],
"disabled": false,
"autoApprove": ["create_debug_session", "set_breakpoint", "get_variables"]
}
}
}
```
### For Codex CLI, desktop, and IDE
Register the published stdio server with the Codex CLI:
```bash
codex mcp add mcp-debugger -- npx -y @debugmcp/mcp-debugger stdio
codex mcp list
```
Codex stores this entry in `~/.codex/config.toml`. The ChatGPT desktop app, Codex CLI,
and Codex IDE extension share that configuration when they run on the same Codex host.
Restart the active desktop client or IDE extension (or start a new CLI session), then use
`/mcp` to confirm that `mcp-debugger` is connected. See the official
[Codex MCP documentation](https://developers.openai.com/codex/mcp) for configuration and
troubleshooting details.
Developing mcp-debugger itself? Use the restartable [source dev proxy](tools/dev-proxy/README.md#codex-cli-desktop-and-ide)
instead of the published package.
### For Claude Code CLI
For Claude Code users, we provide an automated installation script:
> **Prerequisite**: The Claude CLI must be installed and available on your PATH before running the installation script. See [Claude Code documentation](https://claude.ai/code) for installation instructions.
```bash
# Clone the repository
git clone https://github.com/debugmcp/mcp-debugger.git
cd mcp-debugger
# Run the installation script
./scripts/install-claude-mcp.sh
# Verify the connection (use 'claude mcp list' if claude is on your PATH)
claude mcp list
```
**Important**: The `stdio` argument is required to prevent console output from corrupting the JSON-RPC protocol. See [CLAUDE.md](CLAUDE.md) for detailed setup and troubleshooting.
### For the pi coding agent
pi has no built-in MCP support β MCP servers reach it through the community
[`pi-mcp-adapter`](https://github.com/nicobailon/pi-mcp-adapter) extension. The published
`@debugmcp/mcp-debugger` package is itself a pi package (from v0.25.0): it ships the
`mcp-debugger` agent skill and a server entry for the adapter, so one install registers both:
```bash
pi install npm:pi-mcp-adapter # prerequisite: the MCP bridge for pi
pi install npm:@debugmcp/mcp-debugger # registers the stdio server and the mcp-debugger skill
pi list # shows the package, its skill, and its MCP server
```
The adapter namespaces contributed servers by package, so the tools appear under
`debugmcp_mcp-debugger__mcp-debugger`; `mcp({ search: "breakpoint" })` finds them either way.
The server entry runs the published package via `npx`. To debug a source build instead,
register the [dev proxy](tools/dev-proxy/README.md) in the adapter's own config.
### Using Docker
```bash
docker run -i --rm -v $(pwd):/workspace debugmcp/mcp-debugger:latest
```
> The Docker image debugs **Python, JavaScript, Java, Rust, and C/C++** natively (toolchains + a shared vendored CodeLLDB are included), plus the mock adapter. **Ruby is attach-only** in the image (the adapter ships without a Ruby runtime β attach to any `rdbg --open` process, local or remote). Only **Go and .NET** are disabled in the container β run those via npm/npx next to your local toolchain. Host-built Rust/C++ binaries debugged in the container get an auto-derived source map back to `/workspace`. `list_supported_languages` reports per-mode availability (`modes.launch` / `modes.attach`) with reasons. See [Docker support](./docs/docker-support.md).
### Using npm
```bash
npm install -g @debugmcp/mcp-debugger
mcp-debugger --help
```
Or use without installation via npx:
```bash
npx @debugmcp/mcp-debugger --help
```
### Over the network (Streamable HTTP)
`stdio` is the default and is what most clients want. When the server has to run somewhere else
β a CI runner, a container, a Kubernetes pod β start it on a port instead:
```bash
mcp-debugger http --port 3001 # or: node dist/index.js http -p 3001
```
and point the client at it:
```json
{
"mcpServers": {
"mcp-debugger": {
"type": "http",
"url": "http://127.0.0.1:3001/mcp"
}
}
}
```
Each HTTP client gets its own isolated server: debug sessions are never visible to another
client. A client that disconnects without `DELETE /mcp` keeps its debug sessions β and any
paused attach target β alive until the server reaps it: 2 minutes after its SSE stream
dropped (`MCP_HTTP_STREAM_LOST_SESSION_MS`), or 30 minutes idle if it never opened one
(`MCP_HTTP_STALE_SESSION_MS`). `GET /health` lists what each session is holding.
The port defaults to 3001, and the server listens on `127.0.0.1` only. `--bind 0.0.0.0` (or
`MCP_HTTP_BIND=0.0.0.0`) listens on every interface β pair it with `--allowed-host` for the names other
machines will use; `--bind localhost` means `127.0.0.1`, and only IP addresses are accepted. `GET /health`
on the same port answers a liveness check and reports the bound address and port under `listening`. The
legacy `sse` subcommand still exists but is deprecated β use `http`.
The server accepts only loopback `Host` headers by default β `localhost`, `127.0.0.1`, `[::1]` β
as DNS-rebinding protection for an unauthenticated endpoint that can spawn processes and attach to
PIDs. A client on another machine reaches it through a port-forward or an SSH tunnel
(`ssh -L 3001:127.0.0.1:3001 user@server`, then `http://127.0.0.1:3001/mcp`), or you bind an
interface with `--bind`; any other `Host` gets a 403 that says so. To accept a service name directly β `http://mcp-debugger:3001/mcp` on a
container network β start the server with `--allowed-host mcp-debugger` (repeatable) or
`MCP_HTTP_ALLOWED_HOSTS=mcp-debugger` (comma-separated). That opt-in means another access control
fronts the server; there is no wildcard. Browser clients are checked against the same list by
their `Origin`, so a cross-site page cannot drive the debugger. The deprecated `sse` subcommand
applies the same allowlist and accepts the same flag.
## π How It Works
mcp-debugger exposes debugging operations as MCP tools that can be called with structured JSON parameters:
```json
// Tool: create_debug_session
// Request:
{
"language": "python", // or "ruby", "javascript", "rust", "go", "java", "dotnet", "cpp", or "mock" for testing
"name": "My Debug Session"
}
// Response:
{
"success": true,
"sessionId": "a4d1acc8-84a8-44fe-a13e-28628c5b33c7",
"message": "Created python debug session: My Debug Session"
}
```
## π οΈ Available Tools
All **28 tools** below are implemented β see the [tool reference](docs/tool-reference.md) for parameters and response shapes.
| Tool | Description | Status |
|------|-------------|--------|
| `create_debug_session` | Create a new debugging session | β
Implemented |
| `list_debug_sessions` | List all active sessions | β
Implemented |
| `list_supported_languages` | Show available language adapters | β
Implemented |
| `set_breakpoint` | Set a breakpoint in a file | β
Implemented |
| `list_breakpoints` | List a session's breakpoints with verified state | β
Implemented |
| `remove_breakpoint` | Remove a breakpoint by id or file+line | β
Implemented |
| `clear_breakpoints` | Remove all breakpoints (optionally per file) | β
Implemented |
| `start_debugging` | Start debugging a script | β
Implemented |
| `restart_debugging` | Relaunch with the same config, breakpoints re-applied | β
Implemented |
| `attach_to_process` | Attach debugger to a running process | β
Implemented |
| `detach_from_process` | Detach debugger from a process | β
Implemented |
| `expose_session` | Open a read-only DAP mirror endpoint so an IDE can attach and inspect | β
Implemented |
| `unexpose_session` | Close the mirror endpoint and disconnect IDE clients | β
Implemented |
| `get_stack_trace` | Get the current stack trace | β
Implemented |
| `list_threads` | List all threads in the debug session | β
Implemented |
| `get_scopes` | Get variable scopes for a frame | β
Implemented |
| `get_variables` | Get variables in a scope | β
Implemented |
| `get_local_variables` | Get local variables in current frame | β
Implemented |
| `step_over` | Step over the current line | β
Implemented |
| `step_into` | Step into a function | β
Implemented |
| `step_out` | Step out of a function | β
Implemented |
| `continue_execution` | Continue running | β
Implemented |
| `pause_execution` | Pause running execution | β
Implemented |
| `evaluate_expression` | Evaluate expressions in debug context | β
Implemented |
| `get_source_context` | Get source code context | β
Implemented |
| `get_output` | Read captured debuggee output (stdout/stderr) | β
Implemented |
| `close_debug_session` | Close a session | β
Implemented |
| `redefine_classes` | Hot-swap changed Java classes into a running JVM (Java only) | β
Implemented |
## ποΈ Architecture: Dynamic Adapter Loading
Version 0.10.0 introduces a clean adapter pattern that separates language-agnostic core functionality from language-specific implementations:
```
βββββββββββββββ ββββββββββββββββββ ββββββββββββββββ βββββββββββββββββββ
β MCP Client ββββββΆβ DebugMcpServer ββββββΆβSessionManagerββββββΆβ AdapterRegistry β
βββββββββββββββ ββββββββββββββββββ ββββββββββββββββ βββββββββββββββββββ
β β
βΌ βΌ
ββββββββββββββββ βββββββββββββββββββ
β ProxyManager ββββββββ Language Adapterβ
ββββββββββββββββ βββββββββββββββββββ
β
βββββββββββββ¬ββββββββββββ¬ββββββββββββΌββββββββββββ¬ββββββββββββ¬ββββββββββββ¬ββββββββββββ¬ββββββββββββ
β β β β β β β β β
βββββββΌββββββββββββΌββββββββββββΌββββββββββββΌββββββββββββΌββββββββββββΌββββββββββββΌββββββββββββΌββββββββββββΌβββββ
βPython ββRuby ββJavaScriptββRust ββGo ββJava ββ.NET ββC/C++ ββMock β
βAdapter ββAdapter ββAdapter ββAdapter ββAdapter ββAdapter ββAdapter ββAdapter ββAdapter β
ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
```
### Adding Language Support
Want to add debugging support for your favorite language? Check out the [Adapter Development Guide](./docs/architecture/adapter-development-guide.md)!
## π‘ Example: Debugging Python Code
Here's a complete debugging session example:
```python
# buggy_swap.py
def swap_variables(a, b):
a = b # Bug: loses original value of 'a'
b = a # Bug: 'b' gets the new value of 'a'
return a, b
```
### Step 1: Create a Debug Session
```json
// Tool: create_debug_session
// Request:
{
"language": "python",
"name": "Swap Bug Investigation"
}
// Response:
{
"success": true,
"sessionId": "a4d1acc8-84a8-44fe-a13e-28628c5b33c7",
"message": "Created python debug session: Swap Bug Investigation"
}
```
### Step 2: Set Breakpoints
```json
// Tool: set_breakpoint
// Request:
{
"sessionId": "a4d1acc8-84a8-44fe-a13e-28628c5b33c7",
"file": "C:\\path\\to\\buggy_swap.py",
"line": 2
}
// Response:
{
"success": true,
"breakpointId": "28e06119-619e-43c0-b029-339cec2615df",
"file": "C:\\path\\to\\buggy_swap.py",
"line": 2,
"verified": false,
"message": "Breakpoint set at C:\\path\\to\\buggy_swap.py:2"
}
```
### Step 3: Start Debugging
```json
// Tool: start_debugging
// Request:
{
"sessionId": "a4d1acc8-84a8-44fe-a13e-28628c5b33c7",
"scriptPath": "C:\\path\\to\\buggy_swap.py"
}
// Response:
{
"success": true,
"state": "paused",
"message": "Debugging started for C:\\path\\to\\buggy_swap.py. Current state: paused",
"data": {
"message": "Debugging started for C:\\path\\to\\buggy_swap.py. Current state: paused",
"reason": "breakpoint"
}
}
```
### Step 4: Inspect Variables
First, get the scopes:
```json
// Tool: get_scopes
// Request:
{
"sessionId": "a4d1acc8-84a8-44fe-a13e-28628c5b33c7",
"frameId": 3
}
// Response:
{
"success": true,
"scopes": [
{
"name": "Locals",
"variablesReference": 5,
"expensive": false,
"presentationHint": "locals",
"source": {}
},
{
"name": "Globals",
"variablesReference": 6,
"expensive": false,
"source": {}
}
]
}
```
Then get the local variables:
```json
// Tool: get_variables
// Request:
{
"sessionId": "a4d1acc8-84a8-44fe-a13e-28628c5b33c7",
"scope": 5
}
// Response:
{
"success": true,
"variables": [
{"name": "a", "value": "10", "type": "int", "variablesReference": 0, "expandable": false},
{"name": "b", "value": "20", "type": "int", "variablesReference": 0, "expandable": false}
],
"count": 2,
"variablesReference": 5
}
```
## π Documentation
- πΊοΈ [Roadmap](./ROADMAP.md) β Path to 1.0: stability criteria, near-term themes, non-goals
- π [Tool Reference](./docs/tool-reference.md) β Complete API documentation
- π¦ [Getting Started Guide](./docs/getting-started.md) β First-time setup
- ποΈ [Architecture Overview](./docs/architecture/README.md) β Multi-language design
- π§ [Adapter Development](./docs/architecture/adapter-development-guide.md) β Add new languages
- π [Dynamic Loading Architecture](./docs/architecture/dynamic-loading-architecture.md) β Runtime discovery, lazy loading, caching
- π§© [Adapter API Reference](./docs/architecture/adapter-api-reference.md) β Adapter, factory, loader, and registry contracts
- π [CHANGELOG](./CHANGELOG.md) β Release history and upgrade notes
- π [Python Debugging Guide](./docs/python/README.md) β Python-specific features
- π [Ruby Debugging Guide](./docs/ruby/README.md) β Ruby debugging with `rdbg`, including remote attach
- π¬ [Case Study: the initialize response that never came](./docs/case-studies/rdbg-initialize-response-stall.md) β mcp-debugger debugging itself to root-cause a Ruby launch stall
- π¬ [Case Study: attaching the debugger to itself](./docs/case-studies/self-attach-fork-release-and-the-500ms-ack-window.md) β live-patching a running mcp-debugger through its own `evaluate_expression` to catch a race strace couldn't see
- π¬ [Case Study: the pause that always succeeded](./docs/case-studies/js-attach-pause-and-the-smart-stepper.md) β reading js-debug's own CDP trace to catch its smart-stepper eating user pauses on idle servers
- π¬ [Case Study: the trace that couldn't name its socket](./docs/case-studies/trace-that-couldnt-name-its-socket.md) β measure-fix-measure on the diagnostics themselves: one scripted attach run, before and after, as the acceptance test
- π¨ [JavaScript Debugging Guide](./docs/javascript/README.md) β JavaScript/TypeScript features
- πΉ [Go Debugging Guide](./docs/go/README.md) β Go debugging with Delve
- β [Java Debugging Guide](./docs/java/README.md) β Java debugging with JDI bridge
- π· [.NET Debugging Guide](./docs/dotnet/README.md) β .NET/C# debugging with netcoredbg
- βοΈ [C/C++ Debugging Guide](./docs/cpp/README.md) β CodeLLDB launch, auto-compile, attach-by-PID, core dumps, remote stubs
- π¦ [Rust Debugging Guide](./docs/rust-debugging.md) β CodeLLDB setup ([Windows specifics](docs/rust-debugging-windows.md))
- π³ [Docker Support](./docs/docker-support.md) β Container languages, attach modes, host-binary source mapping
- βΈοΈ [Kubernetes Debugging](./docs/kubernetes.md) β Turnkey attach recipes: registry-free manifests, per-language presets, ephemeral debug sidecar
- π [JIT Diagnostics Tutorial](./docs/jit-diagnostics/README.md) β Debug live services in Kubernetes, incl. the ephemeral-sidecar flow for compiled code
- π€ [Agent Debugging Guide](./docs/agent-debugging-guide.md) β Correct tool usage patterns for AI agents
- β οΈ [Known Issues](./docs/KNOWN_ISSUES.md) β Current caveats and workarounds
- π©Ί [Diagnostics](./docs/diagnostics.md) β `mcp-debugger doctor`, per-language prerequisites, failure signatures, env-var reference
- π§ [Troubleshooting](./docs/troubleshooting.md) β Common issues & solutions
## π€ Contributing
We welcome contributions! See [CONTRIBUTING.md](./CONTRIBUTING.md) for guidelines.
```bash
# Development setup
git clone https://github.com/debugmcp/mcp-debugger.git
cd mcp-debugger
# Install dependencies and vendor debug adapters
pnpm install
# Vendored debug engines (Microsoft's js-debug; CodeLLDB, shared by Rust and C/C++)
# are downloaded automatically and verified against committed SHA-256 digest pins
# Build the project
pnpm build
# Run tests
pnpm test
# Check adapter vendoring status
pnpm vendor:status
# Force re-vendor all adapters (if needed)
pnpm vendor:force
```
### Debug Adapter Vendoring
The project automatically vendors debug adapters during `pnpm install`:
- **JavaScript**: Downloads Microsoft's js-debug from GitHub releases
- **Rust & C/C++**: Download a single shared copy of CodeLLDB for the current platform (`packages/codelldb-common`)
- **Integrity**: Every download is verified against the pinned SHA-256 digests in the packages' `vendor-manifest.json`; mismatches fail the build
- **CI Environment**: Set `SKIP_ADAPTER_VENDOR=true` to skip vendoring
To manually manage adapters:
```bash
# Check current vendoring status
pnpm vendor:status
# Re-vendor all adapters
pnpm vendor
# Clean and re-vendor (force)
pnpm vendor:force
# Clean vendor directories only
pnpm clean:vendor
```
### Running Container Tests Locally
We use [Act](https://github.com/nektos/act) to run GitHub Actions workflows locally:
```bash
# Build the Docker image first
docker build -t mcp-debugger:local .
# Run tests with Act (use WSL2 on Windows)
act -j build-and-test --matrix os:ubuntu-latest
```
See [tests/README.md](./tests/README.md) for detailed testing instructions.
## π Project Status
- β
**Production Ready**: v0.24.0 with eight language adapters, 28 tools, and polished multi-language distribution
- β
**Clean architecture** with a dynamic adapter pattern
- β
**Python Β· Ruby Β· JavaScript/TypeScript Β· Go Β· Java Β· .NET/C#**: Full step-through debugging
- π¦ **Rust**: Full support on Linux/macOS/Windows (Windows requires the GNU toolchain; MSVC is not supported by CodeLLDB)
- βοΈ **C/C++**: Full step-through debugging via CodeLLDB (launch + attach-by-PID; on Windows prefer MinGW/DWARF β MSVC PDB fidelity is partial)
- π’ **Runtime**: Node.js 22+
- π **Active Development**: Regular updates and improvements β see the [Roadmap](./ROADMAP.md) for the path to 1.0
## ποΈ Who Maintains This
mcp-debugger is stewarded by **Sycamore LLC** and led by John Franklin ([@debugmcpdev](https://github.com/debugmcpdev)). The project uses an agent-first development model with human accountability: AI agents write most of the code; a human maintainer makes every merge, release, and security decision. See [MAINTAINERS.md](./MAINTAINERS.md), [GOVERNANCE.md](./GOVERNANCE.md), and [SUPPORT.md](./SUPPORT.md) (including commercial support).
Supply-chain posture: pinned CI actions, OIDC trusted publishing, sigstore provenance on every npm package, SBOMs attached to releases, and an [OpenSSF Scorecard](https://scorecard.dev/viewer/?uri=github.com/debugmcp/mcp-debugger) score we actively maintain β details in [SUPPLY-CHAIN-SECURITY.md](./SUPPLY-CHAIN-SECURITY.md). Report vulnerabilities via [SECURITY.md](./SECURITY.md).
## π License
MIT License - see [LICENSE](./LICENSE) for details.
## π₯ Contributors
- [@Poyraxx](https://github.com/Poyraxx) β Ruby adapter (rdbg)
- [@swinyx](https://github.com/swinyx) β Go adapter (Delve)
- [@roofpig95008](https://github.com/roofpig95008) β Java adapter (JDI bridge)
## π Acknowledgments
Built with:
- [Model Context Protocol](https://github.com/anthropics/model-context-protocol) by Anthropic
- [Debug Adapter Protocol](https://microsoft.github.io/debug-adapter-protocol/) by Microsoft
- [debugpy](https://github.com/microsoft/debugpy) for Python debugging
- [debug](https://github.com/ruby/debug) for Ruby debugging
---
**Give your AI agents a real debugger β in any language.**
TDQS
Scored across 21 tools
Most tools are clearly distinct (session lifecycle, breakpoints, stepping, inspection), but start_debugging vs create_debug_session vs attach_to_process have some overlap in session creation. get_variables vs get_local_variables is intentional convenience but could cause confusion.
Consistent verb_noun pattern (create_, list_, set_, get_, step_, continue_, pause_, attach_, detach_, close_, evaluate_). Minor deviation: redefine_classes uses a verb_object pattern but is still readable and consistent with the style.
21 tools is on the heavier side but appropriate for a full debugger surface covering session lifecycle, breakpoints, stepping, inspection, and evaluation. Each tool maps to a standard debugger operation, so the count is justified.
Covers the core debugger lifecycle well: create/attach/start, breakpoints, stepping, continue/pause, threads, stack, scopes, variables, evaluation, and source context. Minor gaps: no remove_breakpoint, no disconnect/terminate distinction beyond detach/close, and no explicit session selection parameter on inspection tools (assumed current session).