Headless Ghidra MCP server for LLM-assisted reverse engineering
YAGMCP provides 8 tools for Ghidra-assisted reverse engineering with HTTP transport via fastmcp. All tools have names, descriptions, and input schemas. However, there are significant gaps in parameter documentation, output schema documentation, and error handling guidance. Tool descriptions are present but many are quite brief (some under 100 chars). Parameter descriptions exist but lack detail on format constraints, valid ranges, and dependencies. No output schemas are documented, LLMs cannot infer what fields to expect in responses, making tool chaining difficult. Error handling and recovery guidance are absent. The server shows good foundational structure but lacks the depth needed for production-grade agent integration.
Decompile a function, then ask the LLM to analyze it with a custom prompt.
Decompile a function from a Ghidra program and return pseudo-C source.
Get all cross-references or calls originating from a given address.
Get all cross-references pointing to a given address.
Health check for the YAGMCP server
List functions in a Ghidra program, optionally filtered by name substring.
List all programs/binaries in a Ghidra repository.
No output schemas documented for any tool. LLMs cannot infer response structure, field names, or types. This forces trial-and-error reasoning about what data is available for downstream tool calls and context extraction.
Parameter descriptions lack constraints and format guidance. E.g., 'address' param for get_xrefs_to/from says 'hex format, with or without 0x prefix' but does not specify byte width, alignment, or what happens with invalid addresses. 'filter' param in list_functions lacks range/length limits and case-sensitivity details.
No error handling or recovery guidance in tool descriptions. Callers do not know: what errors are retryable? What should the LLM do if a repository/program/function is not found? Are there partial-failure modes?
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 71 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
List all available Ghidra repositories on the server.
Tool descriptions do not specify pagination support or result limits. list_functions and list_repositories may return hundreds of items; no indication of whether they are capped, paginated, or streamed. LLMs have no guidance on expected result size or when to use filters.
analyze_function tool description does not clarify its output format or how the LLM response is structured. Is it a plain-text analysis? Structured JSON? How should an agent use the result in downstream reasoning?
decompile_function description is brief (62 chars) and lacks context on pseudo-C format, line numbers, variable names, or confidence levels. Agents cannot assess code quality without knowing what Ghidra's decompiler produces.
No tool chain guidance. When an agent calls list_repositories → list_programs → decompile_function, descriptions do not clarify what IDs/names flow between tools or whether the IDs returned by one are valid inputs to the next.