Ghidra MCP Server: 253 MCP Tools for AI-Driven Reverse Engineering

What problem Ghidra MCP Server actually solves

Ghidra is a capable reverse engineering suite with a scripting API that most users never touch, because writing a GhidraScript for every small question interrupts the analysis. An AI client can hold context across a long session and issue many small requests, but it has no way into the Ghidra database on its own. Ghidra MCP Server is the adapter between the two: a Java-side component that runs inside Ghidra and a Python-side bridge that speaks the Model Context Protocol to whatever client you point at it.

The intended user is a reverse engineer who already has Ghidra open on a binary and wants an assistant to do the mechanical parts: rename a hundred functions consistently, apply a type to every caller of an allocator, or walk a call graph and write plate comments. The README frames the project as built "by a reverse engineer who uses it daily on real binaries, not as a demo", and the tool count (253) is the headline claim. That number matters less than the split it implies: read-only wrappers around the decompiler are easy to write, while write access, batch operations and P-code emulation are where the engineering sits.

It is not a disassembler and it does not replace Ghidra. Remove Ghidra and the server has nothing to talk to. The project's own description calls it a bridge, and the pyproject.toml description for the Python package is explicit: "a thin MCP↔HTTP multiplexer exposing Ghidra reverse-engineering tools to AI clients". The Java side does the work; the Python side multiplexes.

The plugin, the bridge, and where the tools live

The architecture has two halves. On the Ghidra side there is a Java extension (the repository is Java-first, built with Gradle and Maven, with a ghidra_scripts/ directory and a src/ tree) that exposes Ghidra operations over HTTP. On the client side there is a Python package, bridge_mcp_ghidra, built by hatchling from python/bridge_mcp_ghidra, with a console entry point named bridge-mcp-ghidra. The bridge talks to Ghidra over stdlib http.client, which is why the wheel carries no requests runtime dependency; the pyproject.toml comment notes that requests is only needed by unshipped subsystems such as fun-doc and the test suite.

That split has a practical consequence. The Python package is small and easy to install, but it is useless alone. The Java plugin must be running inside a Ghidra instance, or a headless Ghidra server must be running, before any tool call returns data. The README lists both modes: GUI plugin and headless, with Docker deployment for CI/CD pipelines.

Tool naming is the part most likely to surprise you. The README carries a compatibility note: tool names are normalized for GitHub Copilot CLI and CAPI validation, exposed names use lowercase letters, digits, underscores and hyphens only, and nested HTTP paths such as /debugger/status are advertised as names like debugger_status_2 when needed to avoid collisions. So the HTTP surface and the MCP surface are not identical, and a path you see in Ghidra-side logs may not be the tool name your client calls. The README documents the normalization rule but not a full mapping table.

Installing the bridge and making a first tool call

The Python bridge ships as a package whose build backend is hatchling, and pyproject.toml declares the console entry point bridge-mcp-ghidra, which maps to bridge_mcp_ghidra.cli:main. The repository also carries a uv.lock. The README does not give a step-by-step install command sequence in the excerpt available here, so the concrete install path is the one the packaging files imply: install the package, then run the declared console script, then point your MCP client at the repository's .mcp.json.

The connection settings are the part you have to fill in yourself. The top-level .env.template is where the bridge's settings belong; copy it to .env and set the values for your Ghidra instance before starting the bridge. The README does not reproduce the template's keys in the excerpt available here, so read .env.template directly rather than guessing at variable names.

For Ghidra itself, the README's badges pin Ghidra 12.1.2 and Java 21, and the repository includes ghidra-mcp-setup.ps1 for Windows plus a docker/ directory for the headless path. The first real use is to ask the client to list the functions in the current program; if the plugin is loaded and the bridge is connected, that call returns the program's function list, and if it returns an empty result or a connection error, the Java side is not running or the .env settings do not match it.

Convention enforcement is the opinionated part

Most of the feature list is what you would expect from a Ghidra automation layer: batch operations, configurable timeouts, atomic transactions, P-code emulation, live debugger integration, Ghidra Server integration for checkout and checkin workflows. The design choice that will divide users is convention enforcement, introduced in v5.0, which moves naming and typing rules out of prompts and into the tool layer.

The README describes three tiers. Auto-fix applies silently; the example given is a count field on a uint32 being prefixed to dwCount on save. Warn lets the change through and returns a message; the example is processData being flagged as needing PascalCase with a verb. Reject blocks the change with an explanation; the example is an undefined to undefined type change being refused as a no-op.

The argument for this is stated plainly: an AI agent produces consistent output across sessions and models without a style guide pasted into every prompt. The argument against is equally plain, and the README does not make it. If your team's conventions differ from the ones baked in, the tool layer becomes an obstacle you have to work around, and the README does not document how to reconfigure or disable the tiers. It also does not document rollback for an auto-fixed rename, which is the tier most likely to surprise someone mid-session. The completeness scoring tool, analyze_function_completeness, returns a 0 to 100 percent score with structural deductions forgiven and log scaling to stop one bad category from dominating; the README explains the scoring philosophy but not the exact weights, so treat the number as a relative signal rather than an absolute grade.

Where it breaks down or is the wrong tool

The clearest limitation is version coupling. The README pins Ghidra 12.1.2 and Java 21, and the project's own changelog shows releases at roughly monthly cadence through mid-2026 (5.14.1 in June, 5.14.2 later in June, 6.0.0 in July). A plugin that reaches into Ghidra internals will break when Ghidra changes those internals, and the sponsor pitch in the README names "compatibility updates" as one of the things funding pays for. If you cannot upgrade Ghidra and Java on the project's schedule, budget for the plugin lagging behind a Ghidra release.

Second, the tool surface is large and the naming is normalized. With 253 tools and a documented collision-avoidance scheme that renames nested paths (debugger_status_2), anything that hardcodes tool names in prompts or scripts is fragile across versions. The README documents the rule but not a stable mapping, so treat tool names as an interface that can shift.

Third, this is the wrong tool if you want read-only, low-commitment exploration. It grants write access to your Ghidra database, including renaming, typing and structure creation, and the convention tiers can act on their own. If you are analyzing an untrusted binary in a throwaway project, that is fine. If you are working in a shared Ghidra Server repository where other analysts have uncommitted work, an agent with write access and auto-fix behavior is a risk you should think about before connecting it. The README documents Ghidra Server integration as a feature, not as a guarded mode.

Compared with IDA MCP and hand-written scripts

The obvious alternative is an equivalent MCP server for IDA Pro, which people search for directly (ghidra mcp vs ida mcp). The difference is not the protocol, which both implement, but the host application. IDA is commercial and its plugin API is long-established; Ghidra is open source, scriptable in Java and Python, and free to run headless in a container. If your organization already licenses IDA and your workflows are built around its decompiler output, an IDA-side MCP server keeps you in the tool your analysts know. If you need to run analysis in CI without per-seat licensing, the Ghidra path is the one that fits, which is why this project ships a docker/ directory and a headless mode.

The second alternative is writing your own GhidraScripts and calling them yourself. That is genuinely viable for a narrow workflow: one script, one question, no protocol layer. What you give up is the conversational loop. An AI client can chain calls, inspect intermediate results and decide what to do next, which is hard to express as a fixed script. What you gain is total control over naming and typing, with no tool layer second-guessing you. The honest split is that this project is worth its complexity when the work is exploratory and repetitive at the same time, and not worth it when you already know the exact sequence of operations you want.

Licence, maintenance and what an upgrade costs

The project is Apache-2.0, and the Python package declares the same licence in pyproject.toml. Apache-2.0 is permissive and includes a patent grant, which matters if you are embedding the bridge in an internal tool. It also means you can fork the Java plugin if upstream compatibility updates stop arriving. The repository has a NOTICE file alongside LICENSE, which is the standard Apache-2.0 arrangement; if you redistribute, read both rather than assuming the LICENSE file alone is the whole story. None of this is legal advice, and the interaction between Apache-2.0 and Ghidra's own licence is something to check with whoever handles licensing where you work.

On maintenance: the last push to the default branch was on 2026-09-04, and the most recent release listed is v6.0.0 from 2026-07-25. The repository is not archived. The README asks for stars and for sponsorship, and names compatibility updates and production hardening as what that funding covers, which is a fair signal about where the maintenance effort goes.

The upgrade cost is real but bounded. There are two moving parts to keep in sync: the Java plugin against your Ghidra version, and the Python bridge against the MCP SDK constraint in pyproject.toml, which is mcp>=1.28.1,<2.0.0. A major MCP SDK release would require a bridge update before you can move. On the Ghidra side, the plugin and the Ghidra version move together, so an upgrade is a two-step operation with a test pass in between on a binary whose analysis you already trust.

Editorial conclusion

Adopt it if you already work inside Ghidra and want an AI client to drive renaming, typing, commenting and batch analysis on real binaries; the convention tiers and batch operations are the parts that save time, and the headless Docker path is what makes CI use realistic. Do not adopt it if you need a stable tool surface across upgrades, if you cannot run Ghidra 12.1.2 with Java 21, or if you object to a tool layer that rejects some of your renames. Before committing, check the compatibility note in the README about normalized tool names, confirm which mode you will run (GUI plugin or headless), and read the .env.template to see which settings the bridge expects.

Frequently asked questions

Official sources

1. bethington/ghidra-mcp on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases