Skip to main content
Glama

MCP Debugger

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.

Why This Exists

Traditional AI debugging means:

  • Stop execution

  • Edit code to add debug logs

  • Adjust log levels

  • Rerun the program

  • Parse log spam

  • Repeat

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.

Related MCP server: MCP Debugger

What Makes This Different

  • ✓ Fully Autonomous: Claude decides when to debug, sets breakpoints, and investigates without human prompting

  • ✓ Real DAP Backends: Uses production debuggers (debugpy, vscode-js-debug, Delve, CodeLLDB), not mocks or interpreters

  • ✓ Expanded Locals: Inspects full object trees, compares expected vs actual values

  • ✓ Multi-Language: Same autonomous debugging across Python, JavaScript/TypeScript, Go, and Rust

This isn't "AI explains stack traces" or "human-directed debugging" — it's autonomous runtime investigation.

Claude debugs itself. No human intervention required.

Language Support

Fully functional with real debugger backends:

  • Python — debugpy

  • JavaScript / TypeScript — vscode-js-debug

  • Go — Delve

  • Rust — CodeLLDB

Debug adapters auto-install on first use.

How It Works

Claude Code → MCP Protocol → mcp-debugger → DAP → Runtime Debugger
                                                    ↓
                                              Your Program (paused)
  1. Claude detects something might be wrong (test failure, unexpected behavior, etc.)

  2. Claude autonomously decides to debug instead of guessing

  3. Breakpoints are set, program runs

  4. Claude inspects locals, compares expected vs actual values

  5. Claude identifies the discrepancy and fixes the bug

Fully autonomous — Claude invokes debugging tools on its own when investigating issues.

Installation

In Claude Code:

  1. Use /plugin to open the plugin manager

  2. Add the registry: bherbruck/mcp-debugger

  3. Install the mcp-debugger plugin

That'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.

Concrete Example

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.

Who This Is For

  • Autonomous coding agents that need to debug themselves without human intervention

  • Developers who want agents to investigate and fix bugs independently

  • Anyone building with AI agents who's tired of log-based debugging cycles

This is agent-first debugging. Claude investigates, debugs, and fixes autonomously.

Scope & Safety

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

MCP Debugger gives agents read-only runtime inspection. It's designed for dev environments where pausing execution is safe.

Known limitations: Rust multithreaded debugging behaves like a regular VS Code debugger — cross-thread symbol resolution can be limited. This is a CodeLLDB/DAP limitation, not specific to MCP Debugger.

Available Tools

Claude has access to these debugging capabilities (invoked automatically):

Session Management: create_debug_session, start_debugging, terminate_session, list_sessions Breakpoints: set_breakpoint, remove_breakpoint, list_breakpoints Execution Control: continue, pause, step_in, step_over, step_out Inspection: get_stack_trace, get_variables, expand_variable, evaluate_expression, get_source_context

You don't call these directly — Claude chooses when to use them.

Development & Architecture

Build: npm install && npm run build Test: npm test Watch: npm run dev

Architecture layers:

  1. MCP Server (src/server.ts) — Routes tool calls from Claude Code to handlers

  2. Session Manager (src/session/) — Manages debug session lifecycle and state machine

  3. DAP Client (src/dap/) — Implements Debug Adapter Protocol, handles message parsing

  4. Adapters (src/adapters/) — Language-specific debugger implementations (Python, JS/TS, Go, Rust)

See CLAUDE.md for detailed architecture notes.

License

MIT

Available Tools

21 tools
clear_tracesB

Clear all collected traces from the session

Inputs: sessionId (required).

continueA

Continue execution until the next breakpoint or program end. Use waitForBreakpoint to block until a breakpoint is hit and return variables. Use collectHits to run through multiple breakpoint hits, collecting variables at each, then return all traces.

Inputs: sessionId (required), timeout, threadId, collectHits, +1 more.

create_debug_sessionB

Create a new debug session for a specific programming language. Returns a session ID to use with other tools.

Inputs: language (required), name, executablePath.

evaluate_expressionC

Evaluate an expression in the current context

Inputs: sessionId (required), expression (required), context, frameId.

expand_variableC

Expand a complex variable to see its properties/children

Inputs: sessionId (required), variablesReference (required).

get_source_contextB

Get source code around the current execution point

Inputs: sessionId (required), file, line, linesContext.

get_stack_traceC

Get the current call stack

Inputs: sessionId (required), threadId.

get_threadsB

Get all threads in the debugged program

Inputs: sessionId (required).

get_tracesB

Get collected traces from tracepoints. Traces are stored in session state and can be queried with filtering and pagination.

Inputs: sessionId (required), file, line, limit, +2 more.

get_variablesC

Get variables in the current scope

Inputs: sessionId (required), scope, frameId.

list_breakpointsC

List all breakpoints in the session

Inputs: sessionId (required).

list_sessionsB

List all active debug sessions

Inputs: no named parameters.

pauseC

Pause program execution

Inputs: sessionId (required), threadId.

remove_breakpointC

Remove a breakpoint from a source file

Inputs: file (required), line (required), sessionId (required).

set_breakpointB

Set a breakpoint at a specific line in a source file. Use dumpFile to create a tracepoint that dumps variables to a file and auto-continues.

Inputs: file (required), line (required), sessionId (required), trace, +4 more.

start_debuggingB

Start debugging a script file. The program will run until it hits a breakpoint or completes.

Inputs: sessionId (required), scriptPath (required), cwd, env, +2 more.

step_and_traceA

Step through code N times, collecting variables at each step. Returns all traces or writes to a file. Useful for tracing execution flow.

Inputs: sessionId (required), count, timeout, dumpFile, +1 more.

step_inB

Step into the next function call

Inputs: sessionId (required), threadId.

step_outB

Step out of the current function

Inputs: sessionId (required), threadId.

step_overA

Step over to the next line (execute function calls without entering)

Inputs: sessionId (required), threadId.

terminate_sessionB

Terminate a debug session and clean up resources

Inputs: sessionId (required).

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    B3.4/5.0

    Scored across 21 tools

    Disambiguation4/5

    Tools have largely distinct purposes, but trace collection is distributed across multiple tools (set_breakpoint with dumpFile, continue with collectHits, step_and_trace, get_traces) which could cause confusion about which to use.

    Naming Consistency5/5

    All tool names follow a consistent verb_noun pattern with clear verbs (create, get, set, remove, step_*, etc.) and no mixing of naming conventions.

    Tool Count4/5

    With 21 tools, the server covers debugger functionality comprehensively. While slightly on the higher side, each tool serves a specific purpose and the count is reasonable for a full-featured debugger.

    Completeness4/5

    The tool set covers session management, breakpoints, stepping, state inspection, and tracing. Minor gaps exist (e.g., no explicit watch expressions or variable modification), but core debugging workflows are well-supported.

    Maintenance

    ActivityInactive
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      A
      quality
      D
      maintenance
      Enables AI assistants to perform interactive Python debugging with breakpoints, step execution, and variable inspection using the Debug Adapter Protocol (DAP) through an MCP server interface.
      8
      1
      MIT
    • A
      license
      A
      quality
      A
      maintenance
      Enables AI agents to perform step-through debugging of Python, JavaScript/Node.js, and Rust programs using the Debug Adapter Protocol, with support for breakpoints, variable inspection, and stack traces.
      29
      186
      MIT
    • A
      license
      Not graded
      quality
      B
      maintenance
      Enables AI agents to debug code inside VS Code by setting breakpoints, stepping through execution, inspecting variables, and evaluating expressions across multiple languages.
      581
      MIT