ASP.NET Core Debugger — MCP Server for AI Agents

io.github.magna-nz由 GitHub 账号 magna-nz 发布v1.4.0更新于 Oct 24, 2026

MCP server giving AI agents interactive .NET / ASP.NET Core debugging via netcoredbg + DAP.

发布方自己的服务:core.blue

已验证STDIO仅桌面开发者工具安全与监控

概览

AI 生成的概览

让 AI 助手启动、附加并交互式调试 .NET 与 ASP.NET Core 进程,读取运行时值并修改状态。

可以做什么
这是一个本地 MCP 服务器,通过 Debug Adapter Protocol 把 AI 客户端连接到 netcoredbg,提供 27 个工具。涵盖会话控制(启动、附加、断开)、执行步进、行、函数、异常和数据断点,以及线程、堆栈、变量与表达式的检查,包括设置变量值。组合工具把多个调试请求合并为一次调用:exception_autopsy、stack_explore、用于死锁分类的 hang_analyze,以及用于请求跟踪的 trace_start/trace_get/trace_stop。
适用场景
当助手需要诊断正在运行的 .NET 或 ASP.NET Core 应用而不是凭源码猜测时适用:查询返回空结果、身份验证失败、请求挂起、死锁或接口变慢。适合希望助手暂停代码、读取真实运行时值,并通过修改变量验证修复方案再改代码的开发者。
运行要求
以本地进程方式通过 stdio 运行。主机需安装 .NET 10 SDK;软件包已内置适用于 linux-x64、linux-arm64、win-x64、osx-x64 和 osx-arm64 的 netcoredbg。以 .NET 全局工具安装,并按命令名注册到 MCP 客户端。未声明任何身份验证、环境变量或请求头。
安装前请注意
助手可在运行时修改程序状态,例如设置变量值,并可启动或附加到进程;这些改动会影响被调试应用,可能改变其行为或数据。它会附加到正在运行的进程,请确认目标进程。服务器本身不要求任何凭据或密钥。

安装

在 SourceWeft 中

  1. 打开 控制台中的 ASP.NET Core Debugger — MCP Server for AI Agents,将其添加到工作区。
  2. 为需要使用其工具的对话启用该服务。

Desktop only,通过 STDIO。 STDIO 服务会启动本地进程,因此需要 SourceWeft 桌面宿主。

其他 MCP 客户端

参照 仓库 中的启动说明。

README

ASP.NET Core Debugging MCP Server

[MCP Toplist]

The cross-platform .NET debugging MCP — runs on Linux, macOS, and Windows.

[CI] [NuGet] [.NET] [MCP] [Platforms] [License: MIT] [Glama Quality]

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

Why is my EF Core query returning empty?

You

GET /users/active returns [], but I know there are active users in the DB. What's the query actually doing?

Claude

I'll pause inside UserRepository.GetActiveAsync and read what EF Core actually sent.

sql
SELECT u.*FROM Users AS uWHERE u.IsActive = 1 AND u.TenantId = @__tenantId_0
@__tenantId_0 = 0

The SQL is correct; the parameter is wrong. TenantId = 0, but your tenants start at 1. ICurrentUser.TenantId is being read in the repository constructor — before the request scope resolves it. Fix: read the tenant inside the query (or apply it via HasQueryFilter with IHttpContextAccessor) instead of capturing it at construction.

Why is my JWT auth returning 401?

You

/admin/users is 401-ing for Anna, but her token looks valid to me. What does the auth handler actually see?

Claude

I'll break inside JwtBearerHandler.HandleAuthenticateAsync after her request lands.

Token signature: ✓ validClaims 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 discount at 100 fixes the bug. Test that hypothesis without me touching the code.

Claude

I'll pause inside ApplyDiscount on the next checkout and mutate discount in place.

Paused at PricingService.cs:47  discount = 250        ← bug: two promos stacked
Set discount = 100, resumed.
Result:  subtotal = $400  final    = $300  refund-service complaints: 0

Capping at 100 unblocks the flow downstream. Hypothesis confirmed — time to make the edit for real and decide where the cap belongs (ApplyDiscount itself, or upstream in PromoEngine).

My app is hung — what's actually blocking?

You

/reports hangs 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 another SqlConnection from 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: await all the way down in ReportService, or don't hold a connection across the awaited call.

Where is a slow request actually spending its time?

You

GET /order/42 takes 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 caching EnrichmentService.Enrich or moving it off the request path.

More examples →

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 process

A 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

  1. Install the tool — needs the .NET 10 SDK.
    bash
    dotnet tool install -g AspNetCoreDebuggerMcp --prerelease
    The package bundles prebuilt netcoredbg for linux-x64, linux-arm64, win-x64, osx-x64, and osx-arm64 — no separate install needed.
  2. Register with Claude — either the quick CLI command:
    bash
    claude mcp add aspnetcore-debugger -- aspnetcore-debugger-mcp
    …or edit .mcp.json (project-scoped) / ~/.claude.json (global) / claude_desktop_config.json (Claude Desktop) directly:
    json
    {  "mcpServers": {    "aspnetcore-debugger": {      "command": "aspnetcore-debugger-mcp"    }  }}
  3. Just chat with Claude. /mcp confirms 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.

OSArchitecturesStatus
Linuxx64, arm64✅ Supported (Samsung prebuilt)
macOSIntel (x64), Apple Silicon (arm64)✅ Supported (arm64 built by us, since Samsung doesn't ship one)
Windowsx64✅ 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)

CategoryToolsWhat it's for
Sessiondebug_launch, debug_attach, debug_disconnect, debug_stateStart, attach to, or stop a debug session
Executiondebug_continue, debug_pause, debug_step, breakpoint_waitDrive the debuggee and wait for it to stop
Breakpointsbreakpoint_set, breakpoint_set_function, breakpoint_set_exception, breakpoint_set_data, breakpoint_remove, breakpoint_listLine, function, exception, and data breakpoints
Inspectionthreads_list, stacktrace_get, variables_get, variables_set, evaluate, stack_exploreExamine and mutate program state
Exception Autopsyexception_autopsyOne call: exception chain + top frames + locals + source snippet
Hang / Deadlockhang_analyzeAuto-pause, classify each thread's blocking pattern (Monitor / Task / Semaphore / async / …)
Request Tracingtrace_start, trace_get, trace_stopServer-side request tracing — auto-instrument a call chain and capture arguments at every entry
Process I/Oprocess_read_outputDrain the debuggee's stdout/stderr
Healthdebugger_healthQuick check that netcoredbg loaded and the bundled binary is reachable

Full tool reference with parameters →

How this compares

ProjectLicensePlatformsApproach.NET
aspnetcore-debugger-mcp (this)MITLinux + macOS + Windowsnetcoredbg via DAP, ASP.NET-focused composites (request tracing, hang analysis)Native, .NET 10
debug-mcpAGPL-3.0Linux only (Win/macOS planned)ICorDebug direct, Roslyn code navNative, .NET 10
mcp-debugger—Cross-platformDAPVia external debugger
dap-mcp—Cross-platformDAPVia external debugger
LLDB MCPNCSACross-platformNative LLDBNo

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

License

MIT — see LICENSE. Built on netcoredbg (MIT) and the ModelContextProtocol SDK (MIT).

来源:README.md,提交 bad2872

工具

0
SourceWeft 尚未在沙箱中启动过该软件包,因此其工具未知。

版本历史

1
  1. v1.4.0最新Sep 16, 2026

评分

已满足适用检查项的 50%

该评分衡量此收录条目的完整程度,依据注册中心条目、端点与公开来源计算得出。它不是对服务器本身的评价,也不表示服务器安全或当前可用:可连通性是带日期的检查结果,评分也不包含安装量或用户评价。

  • 近 30 天内可连通25 分

    请保持端点能够响应 MCP 握手;SourceWeft 每 30 天探测一次。

  • 已声明认证方式10 分

    请在注册中心条目中声明凭据请求头,或保持端点能够响应探测,以便判定其认证方式。

  • 已列出工具15 分

    请让服务器在无凭据时响应 tools/list,或发布可在沙箱中无凭据启动的软件包。

  • 描述必需15 分
  • 图标10 分
  • 文档15 分
  • 许可证10 分

其他 Core 集成