ASPNET Core Debugging MCP Server
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| threads_listB | List all threads in the debuggee. |
| debug_stepA | Single-step the debuggee. Kind: "in" (step into), "over" (step over), "out" (step out). Pass |
| breakpoint_set_exceptionA | Set the active exception breakpoint filters. Pass [] to clear. Common netcoredbg filters: "all", "user-unhandled". |
| debug_launchB | Launch a .NET program under the debugger. Returns the resulting session state. |
| evaluateA | Evaluate a C# expression in the context of a stack frame. Returns the result as a string plus a variablesReference if the result is a compound value. |
| trace_startA | Begin tracing a set of methods. Each named method gets a server-side trace breakpoint that captures the call (top stack + locals) and auto-continues — the request flows through at near-normal speed and your debug state is unaffected. If includeExceptions=true, unhandled exceptions are also captured. Use trace_get to read the captured events and trace_stop to remove the trace. One trace active at a time. |
| breakpoint_setA | Set a line breakpoint in a source file. Supports conditional, hit-count, and logpoint (logMessage) breakpoints. |
| variables_setB | Set the value of a variable or any lvalue expression (e.g. "userId" or "user.Name"). The agent can use this to test fixes by mutating state mid-run. |
| breakpoint_removeA | Remove a breakpoint by its id (line or function). |
| breakpoint_set_dataA | Set a data/watch breakpoint: break when a specific variable changes (or is read). Requires a variablesReference + name from variables_get. May not be supported by all adapters. |
| stack_exploreA | In one call: full stack + locals at every frame + a pre-rendered ASCII tree showing caller → callee with arrows. Use this instead of stacktrace_get + variables_get per frame when you want to see the whole picture at once. |
| variables_getA | Get variables for a stack frame. Defaults to the topmost frame of the last-stopped thread. Recursively expands compound values up to |
| trace_stopA | Stop the active trace and remove its breakpoints. Captured events are discarded — call trace_get first if you want to keep them. |
| breakpoint_waitA | Block until the debuggee hits a breakpoint, completes a step, or otherwise stops. Returns the stop info plus a full one-shot snapshot: the topmost stack frame, a source snippet around the stop, top-frame locals, and a peek of recent debuggee stdout/stderr (non-destructive — process_read_output still drains the full buffer). Designed so an agent in a step-inspect loop doesn't need separate inspect / read-output round trips. |
| breakpoint_set_functionA | Set a breakpoint on a function by symbol name (e.g. "Namespace.Class.Method"). |
| debug_pauseA | Pause the debuggee. Requires a thread id; defaults to the last-stopped thread if known. |
| debug_stateA | Return the current debug session state, including process id and last stop info. |
| hang_analyzeA | Diagnose why an application appears stuck. Auto-pauses if running, lists all threads, fetches the top frames of each, and classifies each thread's blocking pattern (Monitor / WaitHandle / Semaphore / Task / Thread.Join / Thread.Sleep / async await). Leaves the session paused so you can inspect further. |
| stacktrace_getA | Get the call stack of a thread. By default async state-machine frames are flattened back to their original method names (e.g. UserService.d__3.MoveNext → UserService.GetAsync) and BCL async infrastructure frames are hidden. Pass raw=true for the unmodified DAP frames. |
| trace_getA | Read events captured since trace_start, plus a pre-rendered ASCII timeline with → for method entries and ⚠ for exceptions. Does NOT clear the buffer — call trace_stop when done. |
| process_read_outputA | Drain buffered output (stdout/stderr) from the debuggee since the previous call. Returns the lines collected and removes them from the buffer. Filtering by category drains only that category — lines in other categories, and matches beyond maxLines, stay buffered for a later call. |
| breakpoint_listA | List all currently set breakpoints (line, function, and exception filters). |
| exception_autopsyA | Full exception context in one call: exception type + inner-exception chain + top stack frames + top frame's locals + source snippet around the throw + a peek of recent debuggee stdout/stderr (non-destructive — process_read_output still drains the full buffer). Call this when state.lastStop.reason == "exception". |
| debug_attachB | Attach the debugger to an already-running .NET process by PID. |
| debug_continueC | Resume execution of the debuggee. Defaults to the last-stopped thread. |
| debug_disconnectA | Disconnect the debugger and terminate the debuggee. |
| debugger_healthA | Self-diagnostic. Reports the host platform, RID, resolved netcoredbg path (or that it's missing), where the binary came from (bundled / env var / PATH), and the netcoredbg version it reports. Call this first when something looks wrong, instead of starting a real debug session to find out. |
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 distinct purpose: breakpoint management, execution control, stack inspection, tracing, and diagnostics are cleanly separated. The breakpoint_* and trace_* families are clearly differentiated by their suffixes (set, remove, list, wait, start, stop, get).
The tool names are largely predictable, with strong prefixes like debug_, breakpoint_, trace_, and stack*. Minor inconsistencies exist, such as 'threads_list' vs 'debug_state' and 'stack_explore' vs 'stacktrace_get', but the overall pattern remains comprehensible.
27 tools is on the upper end of what's reasonable for a debugger domain, covering session control, breakpoints, stepping, inspection, tracing, and diagnostics. Some redundancy exists (e.g., stack_explore bundles stacktrace_get + variables_get; debug_step can also wait like breakpoint_wait), which adds weight without adding much capability.
The domain coverage is strong: launch/attach, pause/continue/step, multiple breakpoint types, stack/variable inspection, expression evaluation, output reading, and diagnostic helpers. The main gap is a detach-without-terminate operation)Skip? Otherwise, no obvious missing capabilities for a debugger MCP server.