ASPNET Core Debugging MCP Server
The ASP.NET Core Debugging MCP Server lets an AI agent interactively debug .NET/ASP.NET Core applications across Linux, macOS, and Windows using netcoredbg via the Debug Adapter Protocol — enabling real runtime inspection, mutation, and analysis instead of guesswork.
Session Management
Launch (
debug_launch), attach to (debug_attach), and disconnect from (debug_disconnect) a .NET debuggeeInspect current session state (
debug_state) and verify debugger health/platform info (debugger_health)
Execution Control
Continue (
debug_continue), pause (debug_pause), and single-step into/over/out of code (debug_step)Wait for a breakpoint hit with automatic context (
breakpoint_wait)
Breakpoints
Set line (
breakpoint_set), function (breakpoint_set_function), exception (breakpoint_set_exception), and data/watch (breakpoint_set_data) breakpoints — with optional conditions, hit counts, and logpointsList (
breakpoint_list) and remove (breakpoint_remove) breakpoints
State Inspection & Mutation
List threads (
threads_list), get call stacks (stacktrace_get), and inspect variables (variables_get) with recursive expansionMutate variable values at runtime (
variables_set) and evaluate C# expressions in a stack frame context (evaluate)Explore the full stack in one call — all frames, locals, and an ASCII tree (
stack_explore)
Composite Diagnostics
Exception autopsy: full exception chain + stack frames + locals + source snippet in one call (
exception_autopsy)Hang/deadlock analysis: auto-pause and classify every thread's blocking pattern (Monitor, Task, Semaphore, async, etc.) (
hang_analyze)Request tracing: auto-instrument methods to capture arguments and call chains at near-normal speed without manual breakpoints (
trace_start,trace_get,trace_stop)
Process I/O
Read buffered stdout/stderr output from the debuggee (
process_read_output)
Provides tools for debugging .NET and ASP.NET Core applications, including launching, breakpoints, stepping, inspection, expression evaluation, exception analysis, hang analysis, and request tracing.
ASP.NET Core Debugging MCP Server
The cross-platform .NET debugging MCP — runs on Linux, macOS, and Windows.
An MIT-licensed MCP server that lets an AI agent (Claude, etc.) debug your .NET / ASP.NET Core app — netcoredbg bundled for every platform, nothing extra to install.
Instead of "I think the bug is around line 42, try this", the agent runs your code, pauses it, reads the actual runtime values, mutates state to test a fix, and answers grounded in what it actually saw.
Contents
See it in action — 5 conversations showing the agent at work
How it works — architecture diagram
Use it in 3 steps — install + register with Claude
Platforms — supported OS / architecture matrix
Tools (27) — full tool surface grouped by purpose
How this compares — vs. other .NET / DAP MCPs
Docs — install, examples, tool reference, limits
See it in action
Why is my EF Core query returning empty?
You
GET /users/activereturns[], but I know there are active users in the DB. What's the query actually doing?
Claude
I'll pause inside
UserRepository.GetActiveAsyncand read what EF Core actually sent.SELECT u.* FROM Users AS u WHERE u.IsActive = 1 AND u.TenantId = @__tenantId_0 @__tenantId_0 = 0The SQL is correct; the parameter is wrong.
TenantId = 0, but your tenants start at 1.ICurrentUser.TenantIdis being read in the repository constructor — before the request scope resolves it. Fix: read the tenant inside the query (or apply it viaHasQueryFilterwithIHttpContextAccessor) instead of capturing it at construction.
Why is my JWT auth returning 401?
You
/admin/usersis 401-ing for Anna, but her token looks valid to me. What does the auth handler actually see?
Claude
I'll break inside
JwtBearerHandler.HandleAuthenticateAsyncafter her request lands.Token signature: ✓ valid Claims built: name : anna role : User iss : https://auth.staging.example aud : app-api exp : 2026-05-26T14:12:00Z (not expired)The token validates fine — but the claim is
role=User. Your endpoint is[Authorize(Roles="Admin")]. So the 401 is correct: Anna isn't actually an admin yet upstream. Either her IdP record needs updating, or this policy is wrong.
Test a fix without restarting
You
I think capping
discountat 100 fixes the bug. Test that hypothesis without me touching the code.
Claude
I'll pause inside
ApplyDiscounton the next checkout and mutatediscountin place.Paused at PricingService.cs:47 discount = 250 ← bug: two promos stacked Set discount = 100, resumed. Result: subtotal = $400 final = $300 refund-service complaints: 0Capping at 100 unblocks the flow downstream. Hypothesis confirmed — time to make the edit for real and decide where the cap belongs (
ApplyDiscountitself, or upstream inPromoEngine).
My app is hung — what's actually blocking?
You
/reportshangs forever in staging. Attach and tell me why.
Claude
Attached. Ran
hang_analyze.Thread 12 (HTTP request) → blockedOnTask at ReportService.cs:38 Task.Wait() on T#14 Thread 14 (worker) → blockedOnMonitor at SqlConnectionPool.cs:91 waiting for SqlConnection (pool max=5, in-use=5)Classic sync-over-async deadlock. Thread 12 calls
.Wait()on a task that itself needs to open anotherSqlConnectionfrom a fully-held pool. The connection it's holding can't be released until the task completes; the task can't proceed until a connection frees up. Fix:awaitall the way down inReportService, or don't hold a connection across the awaited call.
Where is a slow request actually spending its time?
You
GET /order/42takes 800ms. I don't want to set breakpoints all over — just show me where the time is going.
Claude
I'll auto-instrument your order pipeline and fire the request. Each entry logs the timestamp + arguments, then resumes — the code runs near-normal speed.
[+ 4ms] → OrderController.GetOrder() id=42 [+ 6ms] --→ OrderService.LookupOrder() id=42 [+ 9ms] ----→ OrderRepository.FetchById() id=42 [+ 14ms] ------→ SqlClient.ExecuteQuery() sql="SELECT * FROM orders WHERE id=42" [+ 287ms] ----→ EnrichmentService.Enrich() raw="rows(...)" [+ 781ms] ------→ HttpClient.PostAsync() url="https://crm.internal/enrich"Time is in the CRM enrichment HTTP call — 500ms inside
HttpClient.PostAsync. DB itself was 5ms. Worth cachingEnrichmentService.Enrichor moving it off the request path.
How it works
Claude (MCP client)
│ MCP (stdio / JSON-RPC)
▼
aspnetcore-debugger-mcp ← this server
│ DAP (Debug Adapter Protocol)
▼
netcoredbg ← Samsung's MIT-licensed .NET debugger, child process
│ ICorDebug
▼
target .NET processA protocol bridge with agent-friendly composites on top — exception_autopsy, stack_explore,
hang_analyze, and the trace tools — that bundle multiple DAP requests into a single tool call.
Use it in 3 steps
Install the tool — needs the .NET 10 SDK.
dotnet tool install -g AspNetCoreDebuggerMcp --prereleaseThe package bundles prebuilt
netcoredbgforlinux-x64,linux-arm64,win-x64,osx-x64, andosx-arm64— no separate install needed.Register with Claude — either the quick CLI command:
claude mcp add aspnetcore-debugger -- aspnetcore-debugger-mcp…or edit
.mcp.json(project-scoped) /~/.claude.json(global) /claude_desktop_config.json(Claude Desktop) directly:{ "mcpServers": { "aspnetcore-debugger": { "command": "aspnetcore-debugger-mcp" } } }Just chat with Claude.
/mcpconfirms it's connected. From there, describe what you want — "why does this endpoint return null" — and the agent picks the right tools.
Full install + troubleshooting →
Platforms
Bundled netcoredbg binary is selected at runtime — no per-platform install dance.
OS | Architectures | Status |
Linux | x64, arm64 | ✅ Supported (Samsung prebuilt) |
macOS | Intel (x64), Apple Silicon (arm64) | ✅ Supported (arm64 built by us, since Samsung doesn't ship one) |
Windows | x64 | ✅ Supported (Samsung prebuilt) |
Requires the .NET 10 SDK on the host. The MCP server itself is a cross-platform .NET global tool — same install command everywhere.
Tools (27)
Category | Tools | What it's for |
Session |
| Start, attach to, or stop a debug session |
Execution |
| Drive the debuggee and wait for it to stop |
Breakpoints |
| Line, function, exception, and data breakpoints |
Inspection |
| Examine and mutate program state |
Exception Autopsy |
| One call: exception chain + top frames + locals + source snippet |
Hang / Deadlock |
| Auto-pause, classify each thread's blocking pattern (Monitor / Task / Semaphore / async / …) |
Request Tracing |
| Server-side request tracing — auto-instrument a call chain and capture arguments at every entry |
Process I/O |
| Drain the debuggee's stdout/stderr |
Health |
| Quick check that netcoredbg loaded and the bundled binary is reachable |
Full tool reference with parameters →
How this compares
Project | License | Platforms | Approach | .NET |
aspnetcore-debugger-mcp (this) | MIT | Linux + macOS + Windows | netcoredbg via DAP, ASP.NET-focused composites (request tracing, hang analysis) | Native, .NET 10 |
AGPL-3.0 | Linux only (Win/macOS planned) | ICorDebug direct, Roslyn code nav | Native, .NET 10 | |
— | Cross-platform | DAP | Via external debugger | |
— | Cross-platform | DAP | Via external debugger | |
NCSA | Cross-platform | Native LLDB | No |
Different sweet spots: this project is the MIT, cross-platform option, with ASP.NET-flavoured composites on top of a DAP. debug-mcp goes deeper into runtime internals via ICorDebug but is Linux-only and AGPL today.
Docs
Install & configure — 3 steps, both Claude Code & Desktop, troubleshooting
What you can do with it — 7 things you can ask Claude to do for you
Full tool reference — every parameter on every tool
Known limits — when not to use this tool, adapter & tracing limits
Contributing — repo layout, tests, dev loop
License
MIT — see LICENSE. Built on netcoredbg (MIT) and the ModelContextProtocol SDK (MIT).
Maintenance
Latest Blog Posts
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/magna-nz/aspnetcore-debugger-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server