What we tested
We compiled a small C program that asks for a password, checks it with a per-byte XOR against a hidden key, and stripped its symbols, so only the entry point keeps a name. We installed Ghidra 12.1.4 and Java 21 on an Apple silicon Mac, built Ghidra's decompiler, and connected Claude Code to each server in turn, headless over stdio: pyghidra-mcp 0.3.0 and GhidraMCP 2.0 with its headless option. Both runs got the same request: find the password and explain the check, without running the binary or using other disassemblers. The test sessions also had a few of our own general skills loaded.
What we found
- Both solved it. Each run found the password tidepool-41, explained the length check and the XOR loop correctly, and said it had not run the program to confirm. pyghidra-mcp took 7 turns, 32 seconds and $0.16 at API prices; GhidraMCP took 8 turns, 25 seconds and $0.18.
- The answers came from the same decompiler. Both servers returned identical decompiled C, so the difference was in the tools around it. pyghidra-mcp's decompile_function returned the function with its callees in one call; with GhidraMCP the agent also read the assembly to check the loop condition.
- The tool sets differ in shape. pyghidra-mcp listed 20 tools, built around a project of binaries and a search index. GhidraMCP listed 28, closer to Ghidra's own menus, with separate calls for segments, classes, namespaces and comments.
- Setup was the hard part on macOS. The decompiler had to be built from the Ghidra folder first, and a project path under a dot folder stopped pyghidra-mcp from starting at all. Once running, neither server needed anything else.
- pyghidra-mcp leaves more behind. It downloaded a 167 MB embedding model into ~/.cache/chroma and kept a ChromaDB index next to the project. GhidraMCP left only the Ghidra project.
This is one small binary with one model, so read it as an example, not a benchmark.