Mmcp.market

Qwen DAP MCP server

by SLP-DEV1·io.github.SLP-DEV1/qwen-dap-mcp·v0.18.1

Native runtime debugging via DAP-to-MCP for crashes, hangs, dumps, symbols, and forensics.

A89/100grade A
What users say
No reviews yet
Be the first
Safety scan
A89/100

full report

Adoption
Growing

2 stars351 downloads/wk

Reviews

Write one

Nobody has reviewed Qwen DAP MCP yet.

If you have run it, two minutes of your experience saves the next person an afternoon.

Qwen DAP MCP tools (67, 4 write)

write = sends, deletes, buys or posts

Read from the package source without running it. The installed server may list more.

  • debug_adapter_doctor

    Audit the active DAP session and locally installed debugger adapters, report capability support relevant to qwen-dap-mcp workflows, inspect the resolved security profile, and identify missing prerequisites such as rr. Use it during setup or when an agent workflow is unexpectedly unavailable. Do not use adapter discovery as permission to attach to or execute arbitrary targets.

  • debug_adaptive_evidence

    Collect runtime evidence in progressively richer bounded phases instead of immediately requesting a maximal snapshot. Use it when token/DAP cost matters or the amount of evidence needed is unknown: it starts with stack and small locals, expands only when symbols, exception state, or variables are insufficient, and finishes with a full runtime report when needed. Do not use it to replace deliberate

  • debug_attachwrite action

    Send a DAP attach request to an authorized local target and complete DAP configuration.

  • debug_attach_codelldb

    Attach an initialized CodeLLDB session to an authorized local native process by PID.

  • debug_attach_gdb

    Attach an initialized GDB DAP session to an authorized local process by PID. This changes debugger/target state and can stop the process; use only for targets you are authorized to inspect.

  • debug_attach_gdb_remote

    Use this to connect an initialized GDB DAP session to an explicitly authorized gdbserver TCP endpoint. Loopback hosts are allowed by default; non-loopback hosts must be listed exactly in …. Do not use this as a generic GDB target-string escape hatch: serial devices, arbitrary target syntax, and unapproved network hosts are rejected, and this tool never starts gdbserver itself.

  • debug_attach_lldb_dap

    Attach an initialized upstream LLVM lldb-dap session to an authorized local native process by PID. This can change the target process state and should only be used when attaching is explicitly permitted.

  • debug_attach_lldb_dap_remote

    Use this to connect an initialized upstream lldb-dap session to an authorized lldb-server gdbserver TCP endpoint. qwen-dap-mcp validates the structured host/port first, then generates exactly one gdb-remote host:port attach command for compatibility with older lldb-dap releases such as version 18; user-supplied LLDB commands are never accepted. Loopback is allowed by default; a non-loopback host m

  • debug_causal_trace

    Build a bounded consumer-to-writer evidence chain for one suspicious debugger-visible value. Use it after crash or differential evidence identifies a value whose runtime producers matter. It combines the current stopped snapshot with repeated watchpoint writer tracing. Do not use it for frozen dumps or unsafe-to-resume targets, and do not treat an observed writer as automatic proof of root cause.

  • debug_child_requests

    Inspect bounded DAP reverse requests such as startDebugging emitted by an adapter when a child, fork, worker, or subprocess wants a debugger session. Use it to discover child-debug opportunities without silently granting adapter-controlled process execution. This tool is read-only: qwen-dap-mcp continues to reject reverse requests by default, so do not expect it to auto-launch child sessions.

  • debug_cluster_crashes

    Group multiple previously produced qwen-dap-mcp runtime reports by their normalized crash fingerprint. Use it after opening and reporting several dumps or reproductions to identify dominant failure families without comparing unstable raw addresses. This tool only clusters supplied report identities; do not use cluster membership as proof that every crash has the same root cause.

  • debug_codelldb_info

    Locate a CodeLLDB >= 1.11.0 adapter from an explicit path, CODELLDB_PATH, common VS Code-compatible extension directories, or PATH.

  • debug_compare_runs

    Compare bounded runtime evidence from two existing stopped DAP sessions. Use this for baseline or known-good versus candidate or failing differential debugging after both sessions have reached comparable stops. It compares stack identities, locals, registers, exception state, symbol health, and modules semantically; non-null raw address-only changes are marked unstable rather than causal evidence.

  • debug_continue

    Resume one paused thread in a live debug session. Use this after inspecting a stopped state when execution should proceed to the next stop or termination; do not use it for crash dumps because postmortem targets cannot resume. This changes debuggee execution state and may allow the target to perform normal application side effects before the next stop.

  • debug_cpp_object

    Read a bounded object header from a debugger-visible pointer, decode the probable first-word vtable pointer, correlate it with loaded modules, and return surrounding bytes plus ABI context. Use it for suspected stale C++ objects, invalid virtual dispatch, or overwritten object headers. Do not use a first-word pointer as proven vtable evidence without module/symbol/source corroboration, and this to

  • debug_crash_families

    Compare supplied runtime reports using exact, semantic, and broad family fingerprints so superficially different crashes can be grouped while retaining concrete variants. Use it after debug_runtime_report or debug_dump_batch has produced v2 fingerprints. Do not use shared family membership as proof of one root cause; it is a triage relationship.

  • debug_data_breakpoint_info

    Ask the debugger for a stable dataId and supported access modes for a variable/property before creating a watchpoint.

  • debug_diagnose_stop

    Diagnose an already stopped live or postmortem debug session without changing execution state. Use this when a debugger has captured the failure and you want project-frame selection, crash classification, operand/register/variable bindings, call-chain provenance, ranked hypotheses, and a fix/rebuild/reproduce/verify plan; use debug_snapshot instead when only raw evidence is needed. The tool is rea

  • debug_disassemble

    Disassemble instructions around a DAP memoryReference.

  • debug_disconnect

    End the active DAP session and stop its local adapter process. Use this when debugging is finished or the session must be reset; do not call it when more runtime evidence is still needed. With terminateDebuggee=true it may also terminate a live target process, so this operation can destroy the current runtime state and cannot be treated as read-only.

  • debug_dump_batch

    Open a bounded set of native dump/core files from one local directory through the existing hardened postmortem adapter flow, generate runtime reports for each, and cluster them with v2 crash families. Use it for recurring crash fleets and support bundles. Do not use it on untrusted enormous directories or assume one family fingerprint proves one root cause.

  • debug_evaluate

    Evaluate an expression in the debugger. Expressions may have side effects depending on debugger/language.

  • debug_events

    Return recent asynchronous DAP events.

  • debug_evidence_bundle

    Export bounded structured debugger evidence as JSON, Markdown, or SARIF, or import a JSON/SARIF bundle for offline analysis after the original process is gone. Use it for reproducible bug reports, CI handoff, or evidence replay between sessions. Do not use imported evidence as if it were live state, and exports refuse accidental overwrite by default.

  • debug_exception_info

    Read structured exception information for a stopped thread.

  • debug_find_writer

    Temporarily watch a variable or debugger expression, resume an authorized live target, and capture the first resulting stop to identify the immediate writer candidate. Use this after a stopped-state diagnosis suggests a value was corrupted and runtime provenance is needed; do not use it for crash dumps or when resuming is unsafe. Adapters with DAP data-breakpoint support use that protocol directly

  • debug_gdb_info

    Locate and version-check a local GDB executable with the built-in DAP interpreter. Use this to verify GDB >= 14 discovery before starting a GNU debugger session; it only probes the local executable and does not launch or attach a debuggee.

  • debug_launchwrite action

    Send a DAP launch request, wait for initialization, configure optional source breakpoints, and complete DAP configuration.

  • debug_launch_codelldb

    Launch a native program through an initialized CodeLLDB session. Uses terminal=console so no runInTerminal reverse request is required.

  • debug_launch_gdb

    Launch an authorized local native program through an initialized GDB DAP session. This executes application code and may produce normal target side effects; use debug_this_crash(mode="gdb") for the higher-level diagnose/verify workflow.

  • debug_launch_lldb_dap

    Launch an authorized local native program through an initialized upstream LLVM lldb-dap session. The profile uses internalConsole so qwen-dap-mcp never needs to execute the adapter runInTerminal reverse request.

  • debug_lldb_dap_info

    Locate the upstream LLVM lldb-dap adapter from an explicit path, LLDB_DAP_PATH, PATH (including common versioned binary names), or xcrun on macOS. This only discovers a local executable and does not start a debugger or target process.

  • debug_modules

    List loaded executable images and libraries.

  • debug_open_dump

    Open a local native core/minidump with CodeLLDB, upstream LLVM lldb-dap, or GNU GDB DAP and capture bounded postmortem evidence. Use this when the failure is already recorded and no target process should execute; use debug_run_to_stop or debug_this_crash for a live reproduction instead. The tool starts only the selected local debugger adapter, never launches or resumes the crashed program, treats

  • debug_pause

    Pause a running thread and optionally wait for the resulting stopped event.

  • debug_progress_probe

    Sample a live target across short resume/pause intervals to distinguish no observed progress, same-frame execution movement, and probable busy loops. Use it when a process appears hung but a single thread snapshot cannot distinguish blocking from spinning. Do not use it when resuming the target is unsafe; sampling perturbs scheduling and is not proof of application-level progress.

  • debug_read_memory

    Read a bounded memory range through DAP. Returns base64 plus a hexadecimal rendering and rejects adapter responses larger than the requested bound.

  • debug_regression_oracle

    Classify a completed reproduction against an original crash fingerprint for git-bisect-style workflows. Use it only after debug_runtime_report or crash verification has produced stable fingerprints. It reports original-crash, changed-crash, or inconclusive; it intentionally does not label a changed crash as good, because a different downstream failure can still be a regression.

  • debug_reverse_execution

    Move a stopped live target backward using DAP reverseContinue or stepBack when the active adapter advertises reverse-execution support. Use it with record/replay-capable debuggers to inspect state before a failure without waiting for a future writer. Do not use it on ordinary adapters that lack supportsStepBack, on frozen dumps, or as a substitute for reproducible verification.

  • debug_run_to_stopwrite action

    Run one live launch or attach through an already initialized DAP adapter until the first stopped, exited, or terminated event. Use this when you need deterministic runtime evidence from a reproduction; do not use it for a postmortem dump or when executing/attaching to the local target is not authorized. Launch mode executes application code and attach mode changes debugger control of an existing p

  • debug_runtime_reportwrite action

    Create a shareable structured report from the current stopped target with normalized crash fingerprinting, Symbol Doctor status, sanitizer stderr correlation, poison-pattern memory hazard detection, ABI register-to-argument mapping, and recent debugger output. Use it only for evidence-driven triage and issue handoff. Do not treat heuristic poison patterns, ABI mappings, or sanitizer text correlati

  • debug_scopes

    Read scopes such as Locals, Arguments, or Registers for a stack frame.

  • debug_sessions

    Use this tool to list, create, or close isolated DAP sessions before routing other debugger tools with sessionId. Omit sessionId on normal debug tools only when the backward-compatible default session is intended; do not use a global session selector for concurrent work.

  • debug_set_breakpoints

    Replace simple line breakpoints for one source file.

  • debug_set_data_breakpoints

    Replace data breakpoints/watchpoints using dataIds returned by debug_data_breakpoint_info.

  • debug_set_exception_breakpoints

    Configure adapter-defined exception filters, optionally with filter conditions.

  • debug_set_function_breakpoints

    Replace function breakpoints when supported by the active DAP adapter.

  • debug_set_instruction_breakpoints

    Replace instruction breakpoints at DAP instruction references when supported by the adapter.

  • debug_set_source_breakpoints

    Replace source breakpoints for one file, including optional condition, hit condition, column and log message.

  • debug_snapshot

    Capture bounded evidence from the current stopped debug state without resuming execution. Use this when an agent needs raw stack, locals, registers, exception details, modules, or nearby instructions; prefer debug_diagnose_stop when you also want ranked crash hypotheses and project-frame selection. This is read-only with respect to the debuggee and returns best-effort evidence plus collection erro

  • debug_source_disassembly

    Correlate source locations, disassembly, registers, and pointer-like locals for the raw fault frame and the first likely project-controlled frame. Use this for low-level root-cause evidence when a crash is already stopped and instruction/operand provenance matters; prefer debug_diagnose_stop for a broader ranked diagnosis. This is read-only, does not resume the target, and returns frame-selection

  • debug_stack

    Read stack frames for a thread.

  • debug_start

    Start a local Debug Adapter Protocol process and initialize a debug session. The adapter is spawned directly without a shell.

  • debug_start_codelldb

    Auto-discover and initialize CodeLLDB using DAP over stdio. CodeLLDB 1.11.0 or newer is required.

  • debug_start_gdb

    Discover GDB >= 14 and initialize its built-in Debug Adapter Protocol interpreter over stdio. Use this before the manual GDB launch/attach helpers in the full toolset; it starts only GDB itself and does not yet run or attach a target.

  • debug_start_lldb_dap

    Discover and initialize the upstream LLVM lldb-dap adapter over local stdio. This starts the debugger adapter only; it does not launch or attach a debuggee until a separate launch/attach operation is requested.

  • debug_status

    Inspect debugger lifecycle state, the selected stop, recent DAP events, and bounded adapter stderr without changing target execution. Use this to determine whether a session is initialized, running, stopped, postmortem, exited, or failed before choosing another debug tool; it is diagnostic only and does not resume, launch, attach, or terminate the debuggee.

  • debug_step

    Step over, into, or out of the current frame and optionally wait for the next stopped event.

  • debug_symbol_doctor

    Diagnose missing or mismatched native debug symbols using current DAP module evidence, bounded local symbol-cache search, optional PE/PDB GUID-age comparison, ELF Build-ID or Mach-O UUID probing, and explicit configured symbol-server candidates. Use it before source-level root-cause claims when symbols are partial or suspicious. Do not use filename-only cache matches as proof of identity, and this

  • debug_this_crash
  • debug_this_hang

    High-level native hang workflow for all-thread triage. Use it when a live process appears stuck, deadlocked, waiting forever, or spinning and you need bounded stacks from every thread, wait-state/deadlock heuristics, and cross-thread Pointer-Provenance v2. In current mode it inspects an existing configured session and pauses a running live target when necessary; codelldb, lldb-dap, gdb, and live m

  • debug_thread_timeline

    Capture bounded all-thread stack/variable samples across short resume-pause intervals, classify waits, measure per-thread execution movement, and build a conservative lock-owner graph only from explicit debugger-visible owner thread IDs. Use this for starvation, livelock, lock contention, and deadlock investigation. Do not use it when target resumption is unsafe because sampling perturbs schedulin

  • debug_threads

    List threads in the current debuggee.

  • debug_time_travel

    Coordinate bounded record/replay debugging with rr and DAP reverse execution. Use doctor to inspect rr availability, record to execute one explicitly supplied program under rr, replay-plan to generate a loopback-only rr/GDB handoff, or reverse to move an already record/replay-capable DAP target backward. Do not use record on untrusted targets outside an isolation boundary or assume ordinary debugg

  • debug_trace_lifetime

    Trace lifetime evidence for one debugger-visible pointer or object handle using the current snapshot, sanitizer/runtime output, bounded forward writer tracing, and optional reverse stepping when supported. Use this for suspected use-after-free, stale ownership, or unexpected pointer replacement. Do not use forward tracing on a frozen dump or when resuming the target is unsafe.

  • debug_trace_value

    Build a bounded temporal write timeline for one debugger-visible variable or expression. Use this after differential or crash evidence identifies a suspicious value and repeated live-target resume is safe. The tool installs one temporary data breakpoint or watchpoint at a time, resumes to the next confirmed writer, captures bounded runtime evidence, removes only its own temporary watch, and repeat

  • debug_variables

    Expand a positive DAP variablesReference returned by a scope, variable, or evaluation result.

Public scan report

scanner v0.1.5 · 2026-09-19 · same rubric, same numbers if you re-run it

no findings
  • Code scan101 source files scanned25/25
  • Live reliabilityno gateway calls yet and no remote to proben/a
  • Tool poisoningtools not inspected (local package is not executed); not countedn/a
  • Auth qualitylocal package, no credentials required12/15
  • Maintenancelast push 1 days ago15/15
  • Maintainer identityregistry namespace matches repository owner6/10
Overall 89/100. Components that don't apply are left out of the denominator. Any critical finding is an F.RubricAppeal a findingJSON

Install directly

Runs npx -y @slp-dev1/qwen-dap-mcp on your machine. Read the scan report first; the gateway never runs local packages.

claude mcp add qwen-dap-mcp -- npx -y @slp-dev1/qwen-dap-mcp
Add to Cursor

Qwen DAP MCP: common questions

Is Qwen DAP MCP server safe?
Yes, by our scan: it is graded A (89/100). Read the Qwen DAP MCP safety report
How do I install Qwen DAP MCP?
It runs on your machine. Copy the Claude Code, Claude Desktop or Cursor config from the install section.
Does Qwen DAP MCP need an API key?
Not as far as the registry entry and our scan can tell: no credentials are declared or required.
Is Qwen DAP MCP maintained?
The last commit was 2 days ago (2026-09-18). The latest release is v0.18.1.

More from SLP-DEV1