
pwno-mcp runs GDB + pwndbg in an isolated environment and exposes session-aware debugging, exploit-driver I/O, and helper tooling over MCP for agentic clients.
Quick Start
Launch the server with Docker and connect your MCP client.
Choose a client
Pick Claude, Cursor, OpenCode, or Codex CLI and copy a working config.
Guides
Follow task-oriented walkthroughs for first-run debugging, attach flows, exploit I/O, and multi-session work.
Reference
Jump straight to debugger, automation, and attach API details.
Why it exists
The project is built for LLM-driven binary research workflows where a stateless shell is not enough. It keeps debugger state alive across calls, supports multiple parallel sessions, and pairs low-level debugging with helper tools for process management, Python execution, repo fetching, and exploit-driver flows. You can usepwno-mcp to participate in CTFs, research, and exploit development workflows.
You can read the background story here.
Typical workflow
Launch pwno-mcp
Use the Docker flow in Quick Start. Most users start with HTTP transport and the default
http://127.0.0.1:5500/mcp endpoint.Connect your client
Pick a page under Client Setup and add the server using either HTTP or stdio.
Create a debug session
Start with
create_debug_session, then set_file, set_breakpoint, and run. The walkthrough in First Debug Session shows the full sequence.Paths passed to tools should normally resolve inside
/workspace. If you mount ./workspace from your host into the container, a host file like ./workspace/chal becomes /workspace/chal in tool calls.Runtime model
- The default HTTP endpoint is
http://127.0.0.1:5500/mcp. - The health endpoint is
http://127.0.0.1:5500/healthz. - The local attach helper API runs on
http://127.0.0.1:5501/attachin HTTP mode by default. - Most file paths passed to tools should resolve inside
/workspace. - Multi-session workflows should pass explicit
session_idvalues.
