cpp-debug-mcp
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 | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| gdb_start_sessionC | Start a GDB debugging session for a compiled C++ executable. |
| gdb_end_sessionA | End a GDB debugging session and clean up resources. |
| gdb_runB | Start program execution in GDB. |
| gdb_set_breakpointB | Set a breakpoint at a location. |
| gdb_delete_breakpointC | Delete a breakpoint. |
| gdb_list_breakpointsA | List all breakpoints in the session. |
| gdb_continueA | Continue program execution until next breakpoint or exit. |
| gdb_stepB | Step through program execution. |
| gdb_backtraceB | Get the current call stack (backtrace). |
| gdb_list_variablesB | List local variables in a stack frame. |
| gdb_evaluateB | Evaluate a C++ expression in the current debugging context. |
| gdb_read_memoryC | Read raw memory at an address. |
| gdb_thread_infoB | List all threads and their states. |
| gdb_raw_commandA | Execute a raw GDB command (with safety restrictions). Blocked commands: shell, python, pipe, source. |
| gdb_open_consoleA | Open an interactive GDB console so the programmer can step through code themselves. Creates a tmux session with a full GDB console attached to the same debug session. Both Claude (via MCP tools) and the programmer (via the console) can control GDB simultaneously. Requires tmux to be installed. |
| gdb_close_consoleA | Close the interactive GDB console for a session. |
| lsp_start_sessionB | Start a clangd LSP session for static analysis of C++ code. |
| lsp_end_sessionB | End a clangd LSP session. |
| lsp_diagnosticsB | Get compile errors and warnings for a C++ file from clangd. |
| lsp_hoverB | Get type and documentation info at a specific code position. |
| lsp_goto_definitionB | Find where a symbol is defined. |
| lsp_find_referencesB | Find all references to a symbol. |
| lsp_document_symbolsB | List all symbols (functions, classes, variables) in a file. |
| lsp_signature_helpB | Get function signature help at a call site. |
| inspect_variable_with_typeA | Inspect a variable combining GDB runtime value with LSP type information. Gets the variable's current value from GDB and its type/documentation from clangd for a complete picture. |
| diagnose_crash_siteA | Diagnose a crash by combining GDB backtrace with LSP static analysis. When the program has stopped (e.g., SIGSEGV), this tool gathers:
|
| analyze_functionA | Analyze a function using both GDB and LSP. Sets a temporary breakpoint at the function, gets its signature and references from clangd, and retrieves local variables if the program is stopped there. |
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 27 tools
Each tool has a clearly distinct purpose, with GDB and LSP tools separated by prefix, and combined tools like analyze_function and diagnose_crash_site uniquely bridging the two domains. No two tools are ambiguous in their function.
All tools follow a consistent naming pattern: gdb_ for GDB operations, lsp_ for LSP operations, and descriptive names for combined tools. The pattern is predictable and aids agent understanding.
27 tools is on the higher side, but the server covers two distinct domains (runtime debugging and static analysis), each with a reasonable set of operations. The count is justified by the comprehensive scope, though a slight reduction could improve focus.
The tool surface covers the full debugging lifecycle (session management, breakpoints, stepping, memory inspection, backtraces) and comprehensive LSP features (diagnostics, navigation, signature help). Minor missing features like watchpoints or program restart are present via raw commands, so no critical gaps.