// the find
LaurieWired/GhidraMCP
MCP Server for Ghidra
GhidraMCP is a Ghidra plugin plus Python bridge that exposes Ghidra's decompiler and analysis functions over MCP, letting an LLM drive reverse engineering tasks like decompiling functions, renaming symbols, and listing imports/exports. It's aimed at reverse engineers and security researchers who want to hook Claude, Cline, or another MCP client directly into a live Ghidra session instead of scripting the Ghidra API by hand.
The split architecture (Java plugin running an HTTP server inside Ghidra, separate Python bridge speaking MCP) means the actual RE logic stays in Ghidra's own process and API rather than reimplementing analysis, which is the right call for correctness. Transport-agnostic bridge script supports both stdio and SSE, so it works with fundamentally different client models (Claude Desktop's subprocess style vs. Cline's persistent server). 10k+ stars and active client examples (Claude Desktop, Cline, 5ire) show it's actually being used across the MCP ecosystem, not just a proof of concept.
No versioned protocol or schema for the tool calls documented anywhere in the README — you're trusting an HTTP server bolted onto Ghidra with no auth, bound to localhost:8080 by default, which is fine for a single-user desktop tool but the README doesn't even mention the security implication of an LLM (or anything on your network) getting unauthenticated write access to rename symbols in your binary analysis. Build-from-source requires manually copying seven jars out of your local Ghidra install, meaning the build isn't reproducible without a matching Ghidra install and there's no CI artifact pinning which Ghidra version those jars come from. There's a single test file (AppTest.java) and no indication of actual test coverage for the plugin's HTTP endpoints. Java plugin and Python bridge versions can drift silently since there's no version negotiation between them beyond hoping you downloaded matching release assets.