GhidrAssistMCP: an MCP server extension that puts Ghidra behind an HTTP endpoint

What GhidrAssistMCP adds to a Ghidra session

Ghidra is a reverse engineering platform with a large surface area: decompiler, listing, symbol table, references, project database. GhidrAssistMCP does not replace any of that. It adds a Model Context Protocol server inside the Ghidra process so an external client can call those capabilities over HTTP instead of a human clicking through the CodeBrowser. The stated audience is AI assistants, automated analysis tools, and custom scripts. The practical audience is narrower: someone who already has an MCP-capable client and wants it to read a loaded binary. The README points at GhidrAssist as a client that supports the extension out of the box, which tells you the intended pairing. The extension ships 49 built-in tools, 6 resources for program info, functions, strings, imports, exports and segments, and 7 pre-built prompts for common tasks. Those counts matter less than the shape: tools are consolidated by action, so the API is smaller than 49 separate endpoints would suggest. If you only ever decompile one function by hand, this is overhead. If you want a model to walk a binary and report back, the transport is the point.

How the server, transports and program context fit together

The extension runs an MCP server with two HTTP transports. SSE clients connect at /sse and post messages to /message; Streamable HTTP clients use /mcp. Both are documented, and choosing the wrong one for your client is the most likely first failure. Defaults are host localhost and port 8080, configurable from the control panel under Window, then GhidrAssistMCP, or from the toolbar icon. A single server is shared across all CodeBrowser windows, with focus tracking, and tool responses carry context hints about which binary is in focus. For multi-program work the README says to pass program_name, and to use list_binaries Project Path values when two files share a filename. That last detail is the honest part of the design: name-based targeting breaks down with duplicates, so path disambiguation exists. Long-running operations run asynchronously with task management, and there is a result cache for repeated queries. Both are optimizations you should not assume are free of staleness; the README does not state cache invalidation rules, so treat repeated queries against a changing program as something to check rather than trust.

Installing the extension and making a first headless connection

The README recommends the binary release. Download the latest .zip from the Releases page, then in Ghidra use File, Install Extensions, Add Extension, select the ZIP, and restart when prompted. After restart, open File, Configure, Configure Plugins, search for GhidrAssistMCP, and enable it. Ghidra 11.4 or newer is required, and the README notes testing against Ghidra 12.1 Public. Source builds need Java 25 or newer and the bundled Gradle wrapper rather than a system Gradle. Point Gradle at your install with GHIDRA_INSTALL_DIR or -PGHIDRA_INSTALL_DIR, then run the install task with Ghidra closed:

cd /path/to/GhidrAssistMCP
export GHIDRA_INSTALL_DIR=/path/to/ghidra_12.1_PUBLIC
./gradlew installExtension

The task copies the built ZIP into [GHIDRA_INSTALL_DIR]/Extensions/Ghidra and extracts it into your user Extensions folder, replacing any existing extracted copy. You can override the extraction location with -PGHIDRA_USER_EXTENSIONS_DIR. For a headless session, set the extension path and start the server as a pre-script:

export GHIDRA_USER_EXTENSIONS_DIR="$HOME/.config/ghidra/ghidra_12.1_PUBLIC/Extensions"
export GHIDRASSISTMCP_EXT="$GHIDRA_USER_EXTENSIONS_DIR/GhidrAssistMCP"
"$GHIDRA_INSTALL_DIR/support/analyzeHeadless" /tmp/ghidra-projects McpHeadless \
  -import /path/to/binary \
  -scriptPath "$GHIDRASSISTMCP_EXT/ghidra_scripts" \
  -preScript GAMCPStartServerScript.java "host=127.0.0.1" "port=8080"

Use -process binary_name instead of -import for a program already in the project. The server runs inside the analyzeHeadless JVM against the loaded currentProgram and holds a program consumer so requests do not race against database closure. To keep the session open for an interactive client, run it as a post-script with wait=true. A harness can pass completion_file=/workspace/control/session.complete; creating that file shuts the server down cleanly and lets Ghidra save and exit. Point your client at http://127.0.0.1:8080/sse for SSE or http://127.0.0.1:8080/mcp for Streamable HTTP.

Where GhidrAssistMCP is the wrong tool

The server is an HTTP listener with no authentication described in the README. The default host is localhost, which limits exposure, but anyone who can reach the port can call the tools, and the README does not document a token, TLS, or access control layer. On a shared or remote host, binding to a non-loopback address is a decision the documentation does not help you secure. Version coupling is the second constraint. Ghidra 11.4 or newer is required, and source builds need Java 25, so a team on an older Ghidra or an older JDK cannot use it without upgrading the platform itself. The install path also replaces the extracted copy in your user Extensions folder, which means a failed upgrade can leave you without the previous working extraction; the README does not document rollback. Finally, if your workflow is a human reading decompiler output in the GUI, the MCP layer adds a process, a port, and a client configuration for no benefit. This is infrastructure for programmatic access, not an analysis feature in itself.

GhidrAssistMCP compared with other Ghidra MCP bridges

The related searches surface Bethington/Ghidra MCP as a comparable project, and the meaningful difference is packaging and transport. GhidrAssistMCP is a Ghidra extension built with Gradle, installed through File, Install Extensions, with an in-GUI control panel for host, port, and per-tool toggles. It offers two HTTP transports, SSE and Streamable HTTP, so clients that only speak one of them are still covered. It also documents a headless path through analyzeHeadless with a pre-script or post-script, including wait mode and a completion_file handshake for harnesses. That headless story is the distinguishing feature: it lets a CI job or a batch pipeline import a binary, start the server, let a client work, and then close the session by touching a file. A GUI-only bridge cannot do that. The trade-off is that GhidrAssistMCP carries more moving parts, a plugin lifecycle, persistent tool configuration, and a shared server across windows, so there is more to misconfigure before the first successful call.

Licence, maintenance and upgrade cost

The repository is MIT licensed, which permits commercial use and modification with the usual attribution and warranty disclaimer. Read the LICENSE file for the exact terms; nothing here is legal advice. The repository is not archived, and the last push was on 2026-08-03, the same day as the 2.11.0 release. The two preceding releases, 2.10.0 on 2026-07-10 and 2.9.0 on 2026-06-28, show a release cadence of roughly monthly through that period. Upgrade cost is dominated by the Ghidra version requirement rather than the extension itself. Because installExtension replaces the extracted copy in your user Extensions folder, an upgrade is a replace-in-place operation, and the README does not describe keeping the old ZIP or reverting. If you pin a Ghidra version and upgrade it deliberately, this is manageable. If you follow Ghidra releases closely, budget time for re-verifying that the plugin loads and that your enabled tool set survived, since tool settings are persisted and can outlive the version that wrote them.

Editorial conclusion

Adopt GhidrAssistMCP if you already run Ghidra 11.4 or newer and want an MCP client to call decompilation and listing operations instead of driving the UI by hand, especially if you need the analyzeHeadless path for scripted sessions. Do not adopt it if you are pinned to an older Ghidra, if you cannot accept an unauthenticated HTTP listener on localhost, or if you need a documented rollback procedure, because the README does not describe one. Verify three things before committing: that the plugin appears under File, Configure, Configure Plugins after install; that your client connects on the transport you actually configured, since SSE and Streamable HTTP use different paths; and that the 49 tools you need are enabled in the Configuration tab, because tools can be switched off individually and the setting persists.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. symgraph/GhidrAssistMCP on GitHub