The problem
AI agents are good at reading decompiled code and bad at getting any. Ghidra holds everything an agent needs to reason about a binary — functions, cross-references, memory layout, decompilation — but it lives inside a desktop application with no seat for an agent at the table.
Without that access, an agent "analyzing" a binary is doing archaeology on filenames and strings, and confidently narrating guesses.
Constraints
- The agent has to see live project state, not a one-time dump. Renaming a symbol should be visible in the next decompilation it requests.
- It has to speak a protocol agents already use, which today means the Model Context Protocol, over both stdio and streamable HTTP.
- Reverse engineering sessions are stateful — open project, import binary, decompile, rename — and the tooling has to preserve that state across a sequence of calls.
- It has to run headless in Docker, because nobody wants to babysit a GUI to give an agent access.
What I built
An MCP server built on PyGhidra that exposes Ghidra projects to any MCP client: 72 canonical tools and 3 resources covering project management, binary import, function listing, decompilation, symbol renaming, cross-references, and memory inspection.
It ships as a published Docker image and as a Python package (Python 3.10+), with a CLI that can run tool sequences against a shared Ghidra server — so state built in one step (open project, import binary) carries into the next.
Outcome
An agent pointed at a binary through AgentDecompile works from the same evidence a human reverse engineer would: real decompilation, real references, real memory — and its renames and annotations land back in the shared Ghidra project where a human can pick them up.
It is the same instinct as PyKotor: take a system whose knowledge is locked inside a tool, and give it an API so the archaeology only has to happen once.