MCP Plugin for Ghidra that exposes many Ghidra functionalities – such as decompiling, disassembling, and renaming – to LLMs via the Model Context Protocol (MCP)
This Ghidra MCP server has 10 tools with basic naming and schema coverage, but significant gaps in description quality, parameter documentation, and error handling. Most tools have descriptions under the 10-100 character band and lack parameter-level documentation. None of the tools show output schema documentation. Input schemas are present but minimal (most tools have only 1-2 parameters). The server exposes write operations (renameFunction, addCommentToFunction, renameLocalVariableInFunction) without confirmation or dry-run patterns, and does not declare required permissions or audit trail support. This is a typical community server, functional but not production-grade.
Add comment to function
Decompile function by name
Get function address by name
Get function callers. Returns a list of functions that call the given function.
Get references from address. Returns a list of addresses and code units that are referenced from the address.
Get references to address. Returns a list of addresses and code units that reference the address.
List all functions
Rename function
Output schemas are completely undocumented. No tool specifies what fields or structure the response contains, making it impossible for LLMs to plan downstream tool calls or extract relevant data.
Write operations (renameFunction, addCommentToFunction, renameLocalVariableInFunction) lack confirmation/dry-run patterns. Agents can destructively modify Ghidra projects without a second step to verify intent or preview changes.
Most tool descriptions are too short (<30 chars) to guide LLM selection. Average description length is 40 chars; baseline is 194 chars. Descriptions lack WHEN/WHY guidance, prerequisites, and error recovery hints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 30 | - | v1 |
Rename local variable in function
Search for strings in the program. Right now it only finds strings containing the query string. Minimum length is 5 characters.
Many parameters accept free-form strings without enums or format constraints. Example: 'address' parameter in getReferencesToAddress and getReferencesFromAddress accepts a string but does not specify format (hex, decimal, object notation?).
Tools returning lists (listFunctions, getReferencesToAddress, getReferencesFromAddress, getFunctionCallers, searchForStrings) lack pagination parameters (limit, offset, page, cursor). Large result sets will overflow context and cause failures.
No error recovery guidance. Tools have no documented error cases, recovery hints, or actionable error messages. Example: if renameFunction fails because the function doesn't exist, what should the LLM do next?
No permission gates or audit trail documentation. Write tools do not declare required permissions (e.g., write:ghidra-project), and there is no evidence of logging who called what tool when.
Parameter naming inconsistency and lack of specificity. 'functionName' vs 'name' vs 'function_name' used inconsistently. No guidance on whether 'name' accepts symbols, labels, addresses, or other identifiers. No example values or format patterns.