hyperdbg-mcp
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., "@hyperdbg-mcpdisassemble the code at address 0x7ff7a0b1c000"
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.
hyperdbg-mcp
An MCP server that exposes HyperDbg
the hypervisor-assisted, ring-0 debugger - to LLM agents.
Status: early development (v0.0.1). The design is documented in
docs/DESIGN.md. End-to-end operation requires a Windows host with HyperDbg installed and its driver loaded; the FFI layer has not yet been validated against a livelibhyperdbg.dll.
How it works
The server loads libhyperdbg.dll via ctypes (there is no HTTP API) and registers a set
of MCP tools that map to HyperDbg's command surface. Command text output is captured through
HyperDbg's message callback (see docs/DESIGN.md §2).
MCP client ──stdio──► hyperdbg-mcp (Python) ──ctypes──► libhyperdbg.dll ──► driver + VMMRelated MCP server: GDB MCP Server
Safety
HyperDbg operates at ring-0; a bad write can bugcheck the host, and memory/disassembly read back from the target may be adversarial (you may be debugging malware). The server therefore:
annotates read-only vs destructive tools (
ToolAnnotations);requires per-call confirmation (MCP elicitation) for destructive tools;
supports a hard
--read-onlymode that does not register write/script tools at all;wraps all debuggee-sourced data in an untrusted-data envelope so it is treated as inert;
writes an append-only audit log of every call.
# read-only, safest
hyperdbg-mcp --read-only
# full access (destructive tools gated behind confirmation)
hyperdbg-mcp --lib-path C:\path\to\libhyperdbg.dll --audit-log audit.jsonl
# mock backend - exercise the full tool surface with no HyperDbg / DLL
hyperdbg-mcp --mock
# Debugger Mode - connect to a remote debuggee over serial (halts it on connect)
hyperdbg-mcp --remote-com com4 --baudrate 115200Modes. Default is local VMI (single machine, debug via the local hypervisor).
Debugger Mode (--remote-com / --remote-pipe / --remote-net) connects to a separate
debuggee machine and, by default, halts it on connect - which is what gives a valid CPU context
for register/memory reads and stepping. (Register reads are not meaningful in local VMI mode
with nothing paused.)
Tools
Read (always available): hd_mem_read, hd_reg_read_all, hd_reg_read, hd_eval,
hd_disasm, hd_list_modules, hd_status.
Execution control (available in --read-only): hd_exec_continue, hd_exec_pause,
hd_exec_step.
Target-mutating (full mode only, confirmation-gated): hd_exec_command, hd_bp_set,
hd_mem_write, hd_reg_write, hd_script_run.
Development
pip install -e ".[dev]"
pytest
ruff check .Roadmap
Validate FFI against a live HyperDbg host.
Streamable-HTTP transport + progress streaming for long Intel-PT / LBR traces.
Symbol-aware helpers; richer structured outputs.
License
GPL-3.0-or-later, matching the HyperDbg project.
This server cannot be installed
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/munraimix/hyperdbg-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server