ghidraMCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_program_infoA | Identify the target program: name, format, language/architecture, compiler spec, image base, address range, size, entry points, and hashes. |
| list_functionsB | List functions (name and entry address), optionally filtered by a case-insensitive substring of the name. |
| list_methodsA | Deprecated: use list_functions. Lists function names only. |
| search_functions_by_nameC | Search for functions whose name contains the given substring (case-insensitive). |
| list_classesC | List class namespaces (fully qualified names). |
| list_namespacesC | List all non-global namespaces (fully qualified names). |
| list_segmentsB | List memory blocks with address range, size, and permissions. |
| list_importsC | List imported (external) symbols and their libraries. |
| list_exportsC | List exported symbols / entry points. |
| list_data_itemsC | List defined data with address, label, type, and value. |
| list_stringsB | List defined strings with their addresses, optionally filtered by a case-insensitive substring of the content. |
| get_function_by_addressA | Get the function at or containing an address: name, signature, body range, calling convention. |
| get_current_addressA | Get the address currently selected in the Ghidra GUI listing. |
| get_current_functionA | Get the function containing the address currently selected in the Ghidra GUI. |
| decompile_functionA | Decompile a function by name and return C pseudocode. Fails if the name is ambiguous; use decompile_function_by_address in that case. |
| decompile_function_by_addressB | Decompile the function at or containing an address and return C pseudocode. |
| disassemble_functionC | Disassemble the instructions in a function's body (address, bytes, instruction, end-of-line comment). |
| get_xrefs_toB | List references to an address, with the function each reference comes from. |
| get_xrefs_fromB | List references from a single instruction or data address. |
| get_function_xrefsB | List references to a function's entry point, by name or (preferably) address. |
| get_function_callsA | Function-level call graph, one level deep. Callers are call sites that reach this function; callees are calls made from anywhere in its body, including indirect calls (direct=false). offset/limit apply to each list separately. |
| read_memoryB | Read up to 4096 bytes of program memory as hex and ASCII. Unmapped or uninitialized
bytes are shown as '??' and listed in |
| rename_function_by_addressB | Rename the function at or containing an address. |
| rename_functionA | Rename a function by its current name. Fails if the name is ambiguous; prefer rename_function_by_address. |
| rename_dataC | Rename the label of defined data (or an existing symbol) at an address. |
| rename_variableA | Rename a local variable or parameter as shown in the decompiler. Identify the function by function_address (preferred) or function_name. |
| set_function_prototypeC | Set a function's signature from a C prototype, e.g. "int foo(char *buf, int len)". |
| set_local_variable_typeC | Set the data type of a decompiler variable, e.g. "char *", "DWORD", "MY_STRUCT *". |
| set_decompiler_commentB | Set the pre-comment at an address (shown in the decompiler). An empty comment clears it. |
| set_disassembly_commentB | Set the end-of-line comment at an address (shown in the disassembly). An empty comment clears it. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 30 tools
Most tools target distinct resources/actions (list vs get vs rename vs set), and the descriptions proactively resolve ambiguity (e.g. decompile_function vs decompile_function_by_address, 'prefer rename_function_by_address'). Minor overlap exists in the xref trio (get_xrefs_to, get_xrefs_from, get_function_xrefs) and between list_functions / search_functions_by_name / deprecated list_methods, but directionality and filters make each usable.
Consistent snake_case verb_noun pattern throughout, using a small predictable verb set (list_, get_, decompile_, disassemble_, rename_, set_). Variants like get_function_by_address and decompile_function_by_address follow the same convention, so nothing surprises the agent.
30 tools is heavy and pushes past the comfortable range for a single server. Reverse-engineering genuinely needs many read/analyze/write operations, but the deprecated list_methods is dead weight and several near-duplicate pairs (function vs by_address) inflate the surface.
Strong lifecycle coverage for an analysis server: discovery (imports, exports, functions, strings, data, segments), analysis (decompile, disassemble, xrefs, call graph), and modification (renames, prototypes, types, comments), plus raw memory reads. Gaps remain for active patching/writing memory, creating/undefining functions, or searching by bytes, but core workflows are covered.