MCP Debugger
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_debug_sessionB | Create a new debug session for a specific programming language. Returns a session ID to use with other tools. |
| start_debuggingB | Start debugging a script file. The program will run until it hits a breakpoint or completes. |
| terminate_sessionB | Terminate a debug session and clean up resources |
| list_sessionsB | List all active debug sessions |
| 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. |
| get_tracesB | Get collected traces from tracepoints. Traces are stored in session state and can be queried with filtering and pagination. |
| clear_tracesB | Clear all collected traces from the session |
| remove_breakpointC | Remove a breakpoint from a source file |
| list_breakpointsC | List all breakpoints in the session |
| 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. |
| pauseC | Pause program execution |
| step_inB | Step into the next function call |
| step_overA | Step over to the next line (execute function calls without entering) |
| step_outB | Step out of the current function |
| 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. |
| get_stack_traceC | Get the current call stack |
| get_variablesC | Get variables in the current scope |
| expand_variableC | Expand a complex variable to see its properties/children |
| evaluate_expressionC | Evaluate an expression in the current context |
| get_source_contextB | Get source code around the current execution point |
| get_threadsB | Get all threads in the debugged program |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 21 tools
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.
All tool names follow a consistent verb_noun pattern with clear verbs (create, get, set, remove, step_*, etc.) and no mixing of naming conventions.
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.
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.