GitHub
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
作者提供的说明(英文原文)
MCP server giving AI agents interactive .NET / ASP.NET Core debugging via netcoredbg + DAP.
这三项永远不会合并成一个分数:意见、测量和人气是不同的东西。
我们还没有为它写通俗的介绍。下面是我们从注册中心读取到的事实。
选择你使用的 AI 应用,然后复制设置。
你用的是哪个应用?
在上方选择你的应用。我们会记住它,下次按钮会显示“安装到 …”。
打开 Claude Desktop → Settings → Developer → Edit Config,把下面的内容粘贴到 claude_desktop_config.json
{
"mcpServers": {
"aspnetcore-debugger": {
"command": "dnx",
"args": [
"AspNetCoreDebuggerMcp",
"--yes"
]
}
}
}在终端中运行这条命令
claude mcp add aspnetcore-debugger -- dnx AspNetCoreDebuggerMcp --yes粘贴到项目中的 .cursor/mcp.json,或 ~/.cursor/mcp.json
{
"mcpServers": {
"aspnetcore-debugger": {
"command": "dnx",
"args": [
"AspNetCoreDebuggerMcp",
"--yes"
]
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
粘贴到项目中的 .vscode/mcp.json
{
"servers": {
"aspnetcore-debugger": {
"type": "stdio",
"command": "dnx",
"args": [
"AspNetCoreDebuggerMcp",
"--yes"
]
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
这个服务器在你的电脑上运行,而 ChatGPT 只能连接互联网上的服务器。请选择其他应用。
你的选择通过 Cookie 保存在这台设备上,无需账户。
这些设置是根据作者在注册中心的条目生成的。如果 README 的写法不同,请以 README 为准。
它在你的电脑上运行;安装后,工具列表会显示在你的 AI 应用中。
我们检查的是任何人都能看到的信息;我们没有阅读代码。不适用的检查项不计入总数。 · 检查于 2026年11月7日
注册名称已通过 GitHub 账户 magna-nz 验证,该账户拥有此仓库
我们还没有从 GitHub 读取这个仓库
我们还没有从 GitHub 读取这个仓库
它在你的电脑上运行,没有互联网端点
在你的电脑上运行,改用本地设置
它在你的电脑上运行;我们只能读取互联网端点的工具列表
与注册中心里这个分类中所有活跃的服务器比较。只有当发布者拥有该仓库时,星标数才计入。
它在 1 项适用的基础检查中通过了 1 项。我们没有阅读代码。在添加密钥或令牌之前,请先看看这个服务器要求哪些权限,并使用只具备所需权限的密钥。
注册中心没有列出必需的密钥,不过有些服务器会在首次使用时要求你登录。
它在你的电脑上运行。你的 AI 应用会在需要时启动它,数据不会经过作者的服务器(除非它自己调用在线服务)。
GitHub 仓库最后更新于–,最新版本(1.4.0)于2个月前进入注册中心。
支持 MCP 的应用,例如 Claude Desktop、Claude Code、Cursor 和 VS Code。你的电脑上还需要有 .NET。
同一分类中有:GitHub, Desktop Commander, Cloudflare MCP
同一分类中其他作者的服务器,按星标数排序。
如何看卡片:★ GitHub 星标i三大支柱:评价 · 检查 · 使用情况i更新 = 最新版本发布到注册中心的时间i
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
MCP server for terminal commands, file operations, and process management
Cloudflare MCP servers
按原文从作者的仓库复制。PopNx MCP 没有审查或背书其内容。HTML、图片和脚本已被移除。链接会离开本站。
An MIT-licensed [MCP](https://modelcontextprotocol.io/) 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.
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.
`sql
SELECT u.*
FROM Users AS u
WHERE 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.TenantIdis 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.
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.
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: 0
`
Capping at 100 unblocks the flow downstream. Hypothesis confirmed — time to make the edit
for real and decide where the cap belongs (
ApplyDiscountitself, or upstream in
PromoEngine).
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 another
SqlConnectionfrom 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.
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 caching
EnrichmentService.Enrichor moving it off the request path.
More examples →
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.
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.
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" } } }
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 →
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.
| Category | Tools | What it's for |
|---|---|---|
| Session | debug_launch, debug_attach, debug_disconnect, debug_state | Start, attach to, or stop a debug session |
| Execution | debug_continue, debug_pause, debug_step, breakpoint_wait | Drive the debuggee and wait for it to stop |
| Breakpoints | breakpoint_set, breakpoint_set_function, breakpoint_set_exception, breakpoint_set_data, breakpoint_remove, breakpoint_list | Line, function, exception, and data breakpoints |
| Inspection | threads_list, stacktrace_get, variables_get, variables_set, evaluate, stack_explore | Examine and mutate program state |
| Exception Autopsy | exception_autopsy | One call: exception chain + top frames + locals + source snippet |
| Hang / Deadlock | hang_analyze | Auto-pause, classify each thread's blocking pattern (Monitor / Task / Semaphore / async / …) |
| Request Tracing | trace_start, trace_get, trace_stop | Server-side request tracing — auto-instrument a call chain and capture arguments at every entry |
| Process I/O | process_read_output | Drain the debuggee's stdout/stderr |
| Health | debugger_health | Quick check that netcoredbg loaded and the bundled binary is reachable |
Full tool reference with parameters →
| 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 |
| debug-mcp | AGPL-3.0 | Linux only (Win/macOS planned) | ICorDebug direct, Roslyn code nav | Native, .NET 10 |
| mcp-debugger | — | Cross-platform | DAP | Via external debugger |
| dap-mcp | — | Cross-platform | DAP | Via external debugger |
| LLDB MCP | 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.
MIT — see LICENSE. Built on netcoredbg (MIT) and the ModelContextProtocol SDK (MIT).