Qwen DAP MCP vs UI Beats

A side-by-side look at the Qwen DAP MCP and UI Beats MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.

Qwen DAP MCP logoQwen DAP MCPDeveloper Tools · Local subprocess (stdio)Native runtime and crash-dump debugging through a local DAP-to-MCP bridge for coding agents.45FairAuth: not declaredUI Beats logoUI BeatsDeveloper Tools · Local subprocess (stdio)MCP server for UI Beats. Let your coding agent search, read and install animated React components.49FairAuth: not declared

Verdict: choose Qwen DAP MCP for developer tools work as a local process; choose UI Beats for developer tools as a local process. You can also run both side by side in one mcpServers block.

Which MCP server should you choose?

Qwen DAP MCP logoChoose Qwen DAP MCP when

  • You need dedicated capabilities in the Developer Tools domain.
  • You prefer a local stdio subprocess transport.
  • You want tools like debug_sessions, debug_compare_runs, debug_snapshot.
Explore Qwen DAP MCP

UI Beats logoChoose UI Beats when

  • You need dedicated capabilities in the Developer Tools domain.
  • You prefer a local stdio subprocess transport.
Explore UI Beats

Feature & specification comparison

Rows where the two servers differ are marked.

SpecQwen DAP MCP logoQwen DAP MCPUI Beats logoUI Beats
CategoryDeveloper ToolsDeveloper Tools
Quality signal45/100 · Fair49/100 · Fair
Install commandConfirmedConfirmed
TransportLocal subprocess (stdio)Local subprocess (stdio)
AuthNot declaredNot declared
PricingNot declaredNot declared
Required env varsNone listedNone listed
Verified ownerCommunity listingCommunity listing
GitHub stars3234
Directory activity 3 views 0 installs 0 upvotes 0 views 0 installs 0 upvotes
Tools18Not listed

Tools & capabilities

Qwen DAP MCP tools 18

  • debug_sessionsUse 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_compare_runsCompare 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. Do not use it to launch, resume, or alter either target; prepare both runtime states with the normal lifecycle tools first.
  • debug_snapshotCapture 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 errors for optional data that an adapter cannot provide.
  • debug_statusInspect 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_disconnectEnd 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_run_to_stopRun 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 process, so normal target side effects may occur before the stop. Returns the request result, terminal/stopped outcome, session status, and a bounded snapshot only when a stopped event is captured.
  • debug_diagnose_stopDiagnose 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 read-only and returns both the bounded snapshot and the derived diagnosis, including collection limitations when optional debugger evidence is unavailable.
  • debug_source_disassemblyCorrelate 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 reasoning, both correlations, operand bindings, and any best-effort collection errors.
  • debug_this_crashPreferred high-level native crash workflow. Use mode=current for an already stopped session, dump for read-only postmortem analysis, codelldb to discover CodeLLDB, lldb-dap to discover upstream LLVM lldb-dap, gdb to discover GNU GDB built-in DAP interpreter, or live with an already initialized generic DAP adapter. Do not use codelldb/lldb-dap/gdb/live when executing or attaching to the target is not authorized: those modes can run application code and cause its normal side effects, while current/dump only inspect stopped evidence. workflow.stage selects initial diagnosis, verification against a prior baseline, or the bounded autonomous cycle. Returns runtime evidence, diagnosis, verification/autonomous metadata, and debugger status with deterministic fixed/blocked/budget-exhausted outcomes where applicable.
  • debug_causal_traceBuild 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_progress_probeSample 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_runtime_reportCreate 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 correlation as standalone proof.
  • +6 more on the listing page

UI Beats tools

No tool names declared yet. Check the project README from the listing page.

Ready-to-paste client configs

Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.

Qwen DAP MCP

mcpServers (Claude Desktop / Cursor)
{
  "mcpServers": {
    "qwen-dap-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "@slp-dev1/qwen-dap-mcp"
      ]
    }
  }
}

UI Beats

mcpServers (Claude Desktop / Cursor)
{
  "mcpServers": {
    "ui-beats": {
      "command": "npx",
      "args": [
        "-y",
        "shadcn@latest"
      ]
    }
  }
}

Frequently asked questions

Qwen DAP MCP is categorized under Developer Tools and uses a local stdio subprocess. UI Beats belongs to Developer Tools and uses a local stdio subprocess. Pick Qwen DAP MCP for developer tools work and UI Beats for developer tools.

Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.

Qwen DAP MCP has no declared pricing — check the project's own site. UI Beats has no declared pricing — check the project's own site. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.

Yes. MCP clients support multiple servers: add qwen-dap-mcp and ui-beats as separate keys in the same mcpServers object, and your assistant will call tools from either one.

On AllMCPs, Qwen DAP MCP has a quality signal of 45/100 (Fair) with 3 views, 0 installs and 3 GitHub stars. UI Beats has 49/100 (Fair) with 0 views, 0 installs and 234 GitHub stars.