npx claudepluginhub bherbruck/mcp-debuggerMulti-language debugging plugin for Claude Code using Debug Adapter Protocol. Debug JavaScript/TypeScript, Python, Go, and Rust with real breakpoints, stepping, and variable inspection.
bherbruckShare bugs, ideas, or general feedback.
A Claude Code plugin that enables fully autonomous debugging — coding agents pause programs, step through execution, inspect locals, and compare expected vs actual values using real debuggers. No human intervention. No log statements.
This is a game changer for AI-assisted development. Claude autonomously investigates bugs by debugging itself, finding discrepancies between expected and actual runtime state. It works today.
Traditional AI debugging means:
This wastes tokens, time, and iteration cycles.
MCP Debugger eliminates all of that.
No debug logs. No log levels. No reruns. No code edits. Claude pauses your running program, inspects the actual state, and tells you what's wrong — in one shot.
Result: Faster debugging, fewer tokens spent on log spam, and no polluted git diffs from print statements.
This isn't "AI explains stack traces" or "human-directed debugging" — it's autonomous runtime investigation.
Claude debugs itself. No human intervention required.
Fully functional with real debugger backends:
Debug adapters auto-install on first use.
Claude Code → MCP Protocol → mcp-debugger → DAP → Runtime Debugger
↓
Your Program (paused)
Fully autonomous — Claude invokes debugging tools on its own when investigating issues.
In Claude Code:
/plugin to open the plugin managerbherbruck/mcp-debuggermcp-debugger pluginThat's it. Claude autonomously uses it when investigating issues — no commands needed.
Optional: Add to your CLAUDE.md to encourage autonomous debugging over print statements:
## Debugging
Use the mcp-debugger plugin for debugging instead of adding print/log statements.
Set breakpoints and inspect variables using real debuggers.
Requirements: Language runtimes for what you want to debug (Python 3.7+, Node.js 18+, Go 1.18+, Rust). Debug adapters install automatically on first use.
Scenario: A test fails. Expected return value, got None instead.
Claude (autonomously): Test failure detected. Instead of guessing or adding logs, I'll debug this to see what's actually happening at runtime.
[Claude creates debug session, sets breakpoint at process_orders(), runs code]
Paused at line 47 in process_orders()
Stack frame:
process_orders() → validate_items() → calculate_total()
Expanded locals at breakpoint:
orders = [
Order(id=1, items=[...], total=150.00, status='pending'),
Order(id=2, items=[], total=0.00, status='pending'), ← suspicious
Order(id=3, items=[...], total=200.00, status='pending')
]
valid_orders = []
[Claude steps into validate_items(), inspects]
Found it: Order #2 has an empty items list. The function returns None
when items is empty instead of raising an exception or returning an
empty result.
The bug is in line 52 — it returns early without a value when
len(order.items) == 0.
[Claude fixes the bug to return an empty result instead of None]
Claude found and fixed this autonomously. No log statements added. No human debugging. Just runtime inspection, expected vs actual comparison, and a fix.
This is agent-first debugging. Claude investigates, debugs, and fixes autonomously.
Intended for: Local development and debugging environments Not intended for: Production runtime debugging (yet) Agent capabilities: Inspect state, set breakpoints, evaluate expressions Agent limitations: Cannot modify code through the debugger