bethington/ghidra-mcp is a production-grade Model Context Protocol server exposing 209 Ghidra tools to AI clients, enabling authorized reverse engineers to decompile, document, and debug binaries with agent-driven workflows.
| Tool | bethington/ghidra-mcp — a Java Ghidra plugin plus Python MCP bridge exposing 209 tools for AI-powered reverse engineering |
| Category | Reverse engineering automation / Model Context Protocol server |
| Primary Use | Driving Ghidra decompilation, function documentation, P-code data-flow analysis, and debugging from MCP-capable AI clients on binaries you are authorized to analyze |
| Safe Use | Intended for authorized malware analysis, CTF work, vulnerability research on software you own or are licensed to assess, and defensive research in isolated lab environments |
| Telemetry Note | Purely local tooling: the plugin listens on 127.0.0.1:8089 and the bridge runs locally, so defenders should simply verify the Ghidra extension and bridge-mcp-ghidra process on analyst workstations; the tool itself contacts no external infrastructure |
bethington/ghidra-mcp sits at the intersection of two trends that have matured rapidly over the past two years: the Model Context Protocol as the standard transport between AI agents and tooling, and the resurgence of AI-assisted reverse engineering. The project bills itself as a production-ready MCP server that bridges Ghidra's analysis engine with modern AI clients, and the headline number is genuinely unusual — 209 MCP tools, which the README claims is roughly three times the surface of any competing implementation. What makes it interesting for professionals is not raw tool count but the design posture: it was written by a reverse engineer who uses it daily on real binaries, and that shows up everywhere in the architecture, from convention enforcement to batch operations aimed at cutting agent loop overhead.
The deployment model is a two-piece split. On one side is a Java Ghidra extension, GhidraMCP-<version>.zip, installed through Ghidra's standard **File > Install Extensions** flow and enabled as GhidraMCPPlugin via **File > Configure > Utility > Configure**. On the other is a Python wheel, ghidra_mcp_bridge, that the MCP client spawns as its server process. The extension embeds an HTTP endpoint in the running Ghidra instance, and the bridge proxies MCP tool calls to it. A quick health check is available after enabling the plugin: curl http://127.0.0.1:8089/check_connection, which returns a JSON status blob including server_kind and version. The loopback binding is worth noting from a defensive standpoint — the analysis surface stays local to the analyst's workstation.
Version coupling is strict, and the README is explicit about it: the extension targets Ghidra 12.1.4 and Java 21 exactly, and will only load in the Ghidra build it was compiled against. The bridge requires Python 3.10 through 3.13 and recommends uv for installation. The repository also publishes a clear stability contract — tagged releases such as 7.0.0 are stable, main and release candidates are feature-complete beta, and the dev branch is explicitly experimental with tools merged, renamed, and refactored freely. Anyone building automation on top should pin a tagged release and treat the dev API as unstable, which is honest signaling that many projects skip.
The tool surface itself divides into several clusters. Function-level analysis covers decompilation, call graphs, cross-references, and a analyze_function_completeness scoring tool that rates documentation quality from 0–100%. Data-flow analysis works through what the README calls PCode-graph value propagation — forward and backward tracking from any variable or register using Ghidra's intermediate representation. Structure discovery automates struct/union/enum creation with field analysis and naming suggestions, while string tooling supports regex search, quality filtering, and string-anchored function discovery — the latter being a genuinely useful heuristic for locating the code that touches interesting constants in a binary.
What distinguishes this from read-only MCP wrappers is write access. The tool set supports renaming, retyping, commenting, structure creation, and label management directly through MCP calls. That is what makes the documentation workflows practical rather than decorative: an agent can decompile a function, infer semantics, apply a Hungarian-notation naming scheme, add a plate comment, and have the changes persist in the Ghidra project. Batch operations wrap this for scale — the README claims a 93% reduction in API calls for bulk renaming and commenting — and there is a cross-binary documentation transfer feature that uses SHA-256 function hash matching to propagate annotations across binary versions automatically. Document once, apply everywhere is the pitch, and for anyone maintaining analysis across a product's update cycle, that alone justifies the tooling.
The most architecturally interesting feature is the convention enforcement layer introduced in v5.0. The problem it addresses will be familiar to anyone who has run multiple AI sessions over the same codebase: four functions doing the same thing, named four different ways, because each session had no shared contract. Rather than solving this with prompt engineering, the project moves naming rules, type safety, and documentation standards into the tool layer with three tiers. Auto-fix silently normalizes — a count field on a uint32 becomes dwCount on save. Warn lets a change through but returns a style warning, such as flagging processData as needing PascalCase with a verb. Reject blocks no-op or invalid changes outright, like an undefined → undefined type change. For teams, this eliminates a whole class of review friction; for agents, it produces consistent output across sessions without pasting a style guide into every prompt.
Dynamic analysis arrived in v5.4.0 and comes in two flavors. P-code emulation uses Ghidra's EmulatorHelper to run a function in isolation — the README's example use case is brute-force API hash resolution in milliseconds, a task that traditionally means either manual RE of the hash routine or writing a custom script. Live debugger integration is heavier: sixteen /debugger/* endpoints built on Ghidra's TraceRmi framework, supporting launch, interrupt and resume, stepping, breakpoints, register and memory reads, stack traces, and ASLR-aware translation between static and dynamic addresses. Backend support depends on platform — dbgeng for Windows PE targets, gdb/lldb otherwise — and the debugger tooling is GUI-plugin-only, not available in headless mode. The bridge can additionally proxy twenty-two debugger_* tools to an external debugger server, but this is explicitly opt-in.
Script execution deserves a security note. The server can list and run Ghidra scripts, including inline script code, but running them is gated behind GHIDRA_MCP_ALLOW_SCRIPTS=1. That is the right default: arbitrary script execution inside a Ghidra instance is effectively arbitrary code execution on the analyst's machine, and any MCP client that can reach the server could otherwise trigger it. Professionals deploying this should leave the gate closed unless a specific workflow demands it, and treat an enabled flag as a standing escalation path in their threat model for the workstation.
Headless operation rounds out the picture for automation at scale. A headless server mode runs full analysis without the Ghidra GUI, and the project is Docker-ready for CI/CD pipelines — a natural fit for triage pipelines that need decompilation or completeness scoring on every submitted sample. Multi-program support allows switching between and comparing open binaries, and there is full Ghidra Server integration for repository management, version control, checkout/checkin workflows, and multi-user collaboration, which positions the tool for team environments rather than solo analysis only. Analysis control is programmatic too: Ghidra analyzers can be listed, configured, and triggered through MCP.
Installation from release artifacts avoids any build step entirely: download the extension zip and the bridge wheel from the releases page, install the extension in Ghidra, then uv tool install the wheel, and finally point the MCP client at the absolute path of bridge-mcp-ghidra. The README's warning about absolute paths is a practical one — clients launched from GUIs or services do not inherit shell PATH, and a bare command name fails with spawn ENOENT, a troubleshooting rabbit hole the docs preempt. Compatibility handling for MCP clients is also thought through: tool names are normalized to lowercase letters, digits, underscores, and hyphens for GitHub Copilot CLI validation, with nested HTTP paths like /debugger/status advertised under names such as debugger_status_2 to avoid collisions.
Repository signals support the production-ready claim. The project carries an Apache-2.0 license, a CI test workflow badge, an OpenSSF Scorecard badge, active discussions, and roughly 5.6k stars — strong traction for a specialized RE tool. The topics list (ai, binary-analysis, ghidra-extension, mcp-server, reverse-engineering, static-analysis) accurately reflects the stack: Java plugin, Python bridge, MCP glue. For authorized professionals — malware analysts, vulnerability researchers working on licensed targets, CTF practitioners, and defenders studying attacker tooling in isolated labs — ghidra-mcp currently represents the most complete attempt to make Ghidra a first-class citizen in agentic AI workflows, and its opinionated convention layer is a pattern other tool-bridge projects would do well to copy.
bethington/ghidra-mcp.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.