Allows debugging Dart applications through a DAP debug adapter, including launch/attach sessions, breakpoints, and variable inspection.
Allows debugging Elixir applications through the Elixir LS debugger, including breakpoints and debug inspection capabilities.
Allows debugging Flutter applications via a dedicated DAP debug adapter, supporting launch/attach, breakpoints, and inspect/evaluate operations.
Allows debugging Kotlin applications via the Kotlin debug adapter, enabling launch/attach, breakpoints, and inspection.
Allows debugging Node.js applications through the JavaScript debug adapter, with breakpoints and other DAP debugging operations.
Allows debugging PHP applications via the PHP debug adapter, supporting launch/attach and inspection workflows.
Allows debugging Python applications using debugpy, including launch/attach sessions, breakpoints, and variable inspection.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@debug-dap-mcp launch app.py with debugpy and break at line 42"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
DAP (Debug Adapter Protocol) stdio MCP server——通过一个 debug 工具把调试能力暴露给任意 MCP 客户端（Claude Code / OpenCode 等）。适配器进程由 server 派生，按内置/用户级/项目级三层配置解析。
单工具 debug，30 个 action（launch/attach/continue/evaluate/…），参数 camelCase
每次返回统一 JSON 载荷（structuredContent 与 content[0].text 同源）
自带 14 条内置适配器记录（gdb / lldb-dap / codelldb / debugpy / dlv / js-debug-adapter / netcoredbg / kotlin-debug-adapter / rdbg / php-debug-adapter / bash-debug-adapter / dart-debug-adapter / flutter-debug-adapter / elixir-ls-debugger）
项目来源：具体实现源自 oh-my-pi（Pi 内置调试工具），本项目将其改造为独立的 MCP server 实现。
需要 Node.js ≥ 22。
npx -y @flydut/debug-dap-mcp # 临时运行
npm i -g @flydut/debug-dap-mcp # 全局安装启动后即一个 stdio MCP server；通常由 MCP 客户端作为子进程拉起，无需手动运行。
Related MCP server: Debug-MCP
.mcp.json 或项目配置）{
"mcpServers": {
"debug-dap-mcp": {
"command": "npx",
"args": ["-y", "@flydut/debug-dap-mcp"]
}
}
}全局安装后，command 可直接写 debug-dap-mcp 并清空 args。
opencode.json）{
"mcp": {
"debug-dap-mcp": {
"type": "local",
"command": ["npx", "-y", "@flydut/debug-dap-mcp"],
"enabled": true
}
}
}全局安装后，command 可简写为 ["debug-dap-mcp"]。
需要自定义 CLI 参数（如 --no-project-config）时并入 args/command 数组即可，见下文配置节。
一次 callTool 只执行一个 action（snake_case），参数 camelCase。公共参数：sessionId（缺省 = 焦点会话）、timeout（毫秒，clamp 到 [5000, 300000]，缺省 30000）。所有返回统一 JSON 载荷（snapshot 或查询族结构）。
分组 | action | 关键参数 |
会话 |
|
|
会话 |
|
|
会话 |
| —（整树终止；无会话幂等 |
会话 |
| —（整树快照 + |
断点 |
|
|
断点 |
|
|
断点 |
|
|
断点 |
|
|
断点 |
|
|
流控 |
|
|
检查 |
|
|
检查 |
| —（整树聚合） |
检查 |
|
|
检查 |
|
|
检查 |
|
|
检查 |
|
|
检查 |
|
|
底层 |
|
|
底层 |
|
|
底层 |
|
|
底层 |
|
|
底层 |
| — |
底层 |
|
|
错误统一 isError:true + JSON 错误体：{ error:true, code, message, details? }，code ∈ { usage, capability, adapter, protocol }。
attach 请求体合成序（后者逐键覆盖）：适配器 attachDefaults ⊕ 结构化参数（pid 按记录 pidArgument 映射字段名；spawn 型的 port/host）⊕ dapArguments。各适配器对字段名的差异全部是配置数据，server 无特殊分支。
pid 注入（需要适配器声明相应能力；dapArguments 补齐适配器私有必填字段）：
// gdb（内置记录够用）
{"action":"attach","pid":12345}
// dlv（pidArgument: processId 已内置；显式写法等价）
{"action":"attach","pid":12345,"adapter":"dlv"}
// debugpy 1.8+（其请求体字段名为 processId、debugpyArgs 必填，均经 dapArguments 透传；
// 也可在用户级配置给 debugpy 记录加 "pidArgument": "processId" 省去前者）
{"action":"attach","pid":12345,"adapter":"debugpy",
"dapArguments":{"processId":12345,"debugpyArgs":["--listen","127.0.0.1:0"]}}连接既有 DAP server（用户级配置给适配器加 "attachConnection": "connect"，如 dlv 的 dlv dap --listen=:5678 或 js-debug 独立 dapDebugServer）：此时 attach{port} 的 port 即该 DAP 端点，MCP 不派生进程、直接连接后发 attach 请求体。
debugpy 注意事项：python -m debugpy --listen 5678 app.py 中的 5678 是 pydevd 引擎端口，不是 DAP 端口——对它 attach{port} 不会工作（这是 debugpy 官方拓扑，非本 server 缺陷）。推荐路径是上方 pid 注入；python -m debugpy.adapter --port N 的独立 server 模式在 debugpy 1.8 存在 access-token 认证限制，第三方客户端不可直接复用。Linux 下 pid 注入还需目标进程可被 ptrace（sysctl kernel.yama.ptrace_scope=0 或同 uid 父子关系），Python 3.11+ 的 frozen modules 可能干扰注入（目标以 -X frozen_modules=off 启动更稳）。
透传即语义：断点 verified 标记、variables 的 start/count 分页效果均忠实透传各适配器行为（如 debugpy 对未解析位置的断点报 verified:true）；Windows 符号链接下 source.path 为适配器返回的真实路径。会话 terminated 后进入保留期（默认 5 min，settings.terminatedRetentionMs 可调），期间快照与 output/exitCode 仍可读且不阻塞新 launch。
三层配置按 内置 < 用户级 < 项目级 合并；settings 与 adapters 深合并，数组字段整体替换（如 args、fileTypes 被上层完全替换而非拼接）：
层 | 位置 |
内置 | 随包分发 |
用户级 |
|
项目级 |
|
用户级示例（~/.config/debug-dap-mcp/config.json）：
{
// 顶层 settings 覆盖
"settings": { "binaryPreference": ["dlv"] },
// 顶层 adapters 新增/覆盖记录（command/args/fileTypes/launchDefaults…）
"adapters": {
"my-gdb": {
"command": "gdb",
"args": ["-i", "dap"],
"fileTypes": [".c", ".cpp"],
"launchDefaults": { "request": "launch" }
}
}
}配置文件用 JSON 或 JSONC（注释）皆可。
--no-project-config）项目级 .debug-dap-mcp.json 是「信任仓库即信任配置」：恶意仓库可把适配器 command 指向任意二进制，由 server 作为子进程执行。在不可信仓库中务必以 --no-project-config 启动（禁用项目级配置）。--log-level debug 会在 stderr 记录每次解析出的最终命令行，便于审计。
诊断全部写 stderr（stdout 只承载 MCP 帧）。级别解析：--log-level <debug|info|warn|error> 优先 → 否则 DEBUG_DAP_MCP_LOG → 否则 info。
npx -y @flydut/debug-dap-mcp --log-level debug # 帧收发摘要 + 适配器最终命令行
DEBUG_DAP_MCP_LOG=debug npx -y @flydut/debug-dap-mcp # 环境变量等价物常见错误（isError:true 的 code）：
usage — 参数校验失败 / 未知 action / 适配器选择失败（消息含候选与各自未中原因）/ pid-port 或 name-variablesReference 二选一违例 / 无活动会话
capability — 适配器 capabilities 不支持该 action（如 supportsModulesRequest 缺席）
adapter — 适配器启动失败（含 stderr 摘录与 installHint）或中途崩溃（含会话 id、退出码、stderr 摘录）
protocol — DAP error response 或单请求超时
npm run build # tsc 编译到 dist/
npm run typecheck # src + test 类型检查
npm test # vitest 全套件（core + mcp + CLI + e2e）DAP (Debug Adapter Protocol) control surface. Pass one of 31 actions plus their camelCase parameters; returns a JSON payload (structuredContent mirrors it). Sessions are launched via launch/attach and targeted by sessionId (default: focused session).
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | ||
| pid | No | ||
| args | No | ||
| data | No | ||
| file | No | ||
| host | No | ||
| line | No | ||
| name | No | ||
| port | No | ||
| tail | No | ||
| count | No | ||
| start | No | ||
| action | Yes | ||
| dataId | No | ||
| levels | No | ||
| offset | No | ||
| adapter | No | ||
| command | No | ||
| context | No | ||
| frameId | No | ||
| program | No | ||
| timeout | No | ||
| threadId | No | ||
| arguments | No | ||
| condition | No | ||
| sessionId | No | ||
| accessType | No | ||
| expression | No | ||
| moduleCount | No | ||
| startModule | No | ||
| dapArguments | No | ||
| hitCondition | No | ||
| resolveSymbols | No | ||
| memoryReference | No | ||
| instructionCount | No | ||
| instructionOffset | No | ||
| variablesReference | No | ||
| instructionReference | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does disclose that the tool returns a JSON payload mirrored as structuredContent and explains session targeting defaults. However, it does not mention side effects (e.g., process launch, memory writes, mutation) or failure/error behavior for such a powerful, stateful DAP surface.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: the first establishes the core protocol and invocation model, the second covers return behavior, and the third explains session lifecycle and targeting. Every sentence earns its place, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (38 parameters, 31 actions, no output schema, no annotations), the description is too sparse to be complete. It provides a useful high-level orientation but omits action-to-parameter mappings, required DAP adapter configuration, and return payload details. An agent would need substantial external DAP knowledge to invoke this correctly across actions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 38 parameters, and the description barely compensates. It states that actions take 'their camelCase parameters' and calls out sessionId's default, but does not map actions to their required or relevant parameters. For a tool with this many parameters, an agent has almost no semantic guidance beyond raw parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a DAP control surface and explains that calls consist of an action plus its parameters, which distinguishes it from generic debugger operations. It is specific about the protocol (DAP) and the action-driven invocation model. It stops short of a 5 because there are no siblings to differentiate against, so the comparative clarity can't earn full credit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful usage context: sessions are started via launch/attach and are targeted by sessionId, defaulting to the focused session. This gives an agent actionable guidance on how to invoke it. There are no explicit when-not or alternative-tool statements, but with no sibling tools that is less critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0debugThere is only one tool, so no ambiguity exists between tools. The 31 DAP actions are internal parameters, not separate tools.
The single tool name `debug` is concise and matches the server's purpose. With only one tool, there is no conflicting naming pattern.
The entire DAP protocol is packed into one mult-i purpose dispatch tool, which feels too few for the apparent scope. A single optool acts as a god-parameter surface rather than a discoverable set.
The 31 actions likely cover the core DAP request lifecycle (launch, attach, breakpoints, stepping, evaluation, etc.), enabling complete debugging workflows. As a single control surface, there are no obvious dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Governed data discovery, exact queries, decisions, simulations, and runtime utilities over MCP.
MCP server to assist with JxBrowser development.
An MCP server that provides access to Testiny projects, test cases and test runs
The MCP server for Azure DevOps, bringing the power of Azure DevOps directly to your agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/FlyDut/debug-dap-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
