| name | ghidra-mcp |
| description | Use when working against a local GhidraMCP GUI or headless server, especially for binary import, metadata verification, analysis, export checks, or raw endpoint access. |
Ghidra MCP
When to use
- Verify that a local GhidraMCP server is reachable.
- Load binaries into the headless Docker server and confirm metadata or analysis output.
- Call raw HTTP endpoints without retyping
curl commands.
- Work around headless-specific constraints such as container-only file visibility.
Current local workflow
The common local setup in this environment is:
- headless server on
http://127.0.0.1:8089
- Docker container named
ghidra-mcp
- writable container data path
/data
Canonical project location:
/Users/maleick/Projects/ghidra-mcp-skill
The local skills path points here via symlink:
/Users/maleick/.codex/skills/ghidra-mcp
Use the bundled helper:
python3 /Users/maleick/Projects/ghidra-mcp-skill/scripts/ghidra_mcp.py check
Documented surface for this skill version:
- total catalog:
193
- GUI endpoints:
175
- headless endpoints:
183
- validated against the
ghidra-mcp v5.1.0 catalog in references/endpoints.json
Verify the live runtime against the catalog instead of assuming parity from the upstream release notes:
python3 /Users/maleick/Projects/ghidra-mcp-skill/scripts/ghidra_mcp.py parity --mode headless
Recommended headless sequence
- Verify connectivity.
- Copy the host binary into the container if the repo path is not mounted.
- Load the container-local path with
/load_program.
- Read
/get_metadata.
- Run
/run_analysis if needed.
- Query exports, imports, functions, or any raw endpoint.
There is no special bulk-upload endpoint. For more than one executable, repeat the same container copy and /load_program flow per file, then qualify later calls with program=<basename> when more than one program may be loaded.
One-command verification:
python3 /Users/maleick/Projects/ghidra-mcp-skill/scripts/ghidra_mcp.py verify \
/absolute/path/to/binary.exe --analyze
Multi-binary headless verification:
python3 /Users/maleick/Projects/ghidra-mcp-skill/scripts/ghidra_mcp.py verify-many \
/absolute/path/to/eqgame.exe \
/absolute/path/to/eqmain.dll \
--analyze
Raw endpoint access
For endpoints not wrapped by the helper yet, use:
python3 /Users/maleick/Projects/ghidra-mcp-skill/scripts/ghidra_mcp.py call \
POST /load_program --form file=/data/eqgame.exe
python3 /Users/maleick/Projects/ghidra-mcp-skill/scripts/ghidra_mcp.py call \
GET /get_metadata --query program=eqgame.exe
POST example:
python3 /Users/maleick/Projects/ghidra-mcp-skill/scripts/ghidra_mcp.py call \
POST /run_analysis
Program-qualified examples for the common headless sequence:
python3 /Users/maleick/Projects/ghidra-mcp-skill/scripts/ghidra_mcp.py call \
GET /list_functions --query program=eqgame.exe --query limit=20
python3 /Users/maleick/Projects/ghidra-mcp-skill/scripts/ghidra_mcp.py call \
GET /decompile_function --query program=eqgame.exe --query address=0x401000
python3 /Users/maleick/Projects/ghidra-mcp-skill/scripts/ghidra_mcp.py call \
GET /get_metadata --query program=eqgame.exe
Headless caveats observed here
- Host paths are not visible inside the Docker container unless the repo is mounted there. If needed, copy binaries into
/data first.
- Treat
/mcp/schema as the source of truth for what the current runtime exposes.
server/status refers to optional Ghidra Server integration, not whether the HTTP API itself is up.
- Some endpoints are documented for only one runtime mode even if the other mode exposes a placeholder or error stub.
Output expectations
- Prefer reporting:
- endpoint reachability
- live mode and schema count from
/get_version and /mcp/schema
- binary path used inside the container
- metadata summary: image base, memory size, function count
- whether analysis ran successfully
- any headless limitation that blocks the next step
Source
The upstream repo advertises a large API surface and both GUI/headless modes: