Ghidra MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| JAVA_OPTS | No | JVM options | -Xmx4g -XX:+UseG1GC |
| GHIDRA_MCP_PORT | No | Server port | 8089 |
| GHIDRA_MCP_BIND_ADDRESS | No | Bind address (default is 0.0.0.0 in Docker) | 0.0.0.0 |
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": true
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_instancesA | List known Ghidra instances from UDS discovery and the active TCP fallback. Returns JSON with each instance's project name, PID, open programs, and socket path or TCP URL. Also shows which instance is currently connected. |
| connect_instanceA | Switch the MCP bridge to a different Ghidra instance by project name. IMPORTANT: Before calling this function only the static bridge tools are exposed (list_instances, connect_instance, tool-group management, debugger proxy). After a successful connect the bridge fetches the instance's /mcp/schema and registers Ghidra analysis tools dynamically. By default all tool groups are loaded on connect. When started with --lazy, only the default groups are loaded initially and clients may need to call load_tool_group() for additional categories. Clients that cache the initial tools/list and don't honor tools/list_changed must re-list tools after this call. Use list_instances() first to see available instances. Args: project: Project name (or substring) to connect to |
| list_tool_groupsA | List all available tool groups with their tool counts and loaded status. Returns each category with: tool count, loaded status, and tool names. Use load_tool_group(group) to load a group's tools. |
| load_tool_groupA | Load all tools in a category. Accepts a category name or "all" to load everything. Use list_tool_groups() to see available categories. Args: group: Category name (e.g. "function", "datatype") or "all" |
| unload_tool_groupA | Unload all tools in a category. Default groups are protected from unloading. Args: group: Category name to unload |
| check_toolsA | Check if specific tools are callable right now. Returns status for each tool: "callable", "not_loaded" (exists but group not loaded), or "not_found" (doesn't exist). Args: tools: Comma-separated tool names, e.g. "rename_symbol,batch_set_comments,analyze_function_completeness" |
| search_toolsA | Search the full Ghidra tool catalog by keyword — including tools whose group is not currently loaded. Use this to discover the right tool without paying the context cost of loading all groups (run the bridge with --lazy and search on demand). Matches against tool name, description, and category. Each result reports whether the tool is callable right now; if not, it includes the exact load_tool_group(...) call needed to make it callable. Args: query: Space-separated keywords, e.g. "rename function" or "xref struct". limit: Maximum number of results to return (default 15). |
| import_fileA | Import a binary file from disk into the current Ghidra project. Imports the file, opens it in the CodeBrowser, and optionally starts auto-analysis. When analysis is enabled, sends a log notification when analysis completes. For raw firmware binaries, specify language (e.g. "ARM:LE:32:Cortex") and optionally compiler_spec (e.g. "default"). Without language, Ghidra auto-detects the format (works for ELF, PE, Mach-O, etc.). Args: file_path: Absolute path to the binary file on disk project_folder: Destination folder in the Ghidra project (default: "/") language: Language ID for raw binaries (e.g. "ARM:LE:32:Cortex", "x86:LE:64:default") compiler_spec: Compiler spec ID (e.g. "default", "gcc"). Uses language default if omitted. auto_analyze: Start auto-analysis after import (default: true) |
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 8 tools
The tools mostly have distinct purposes: group lifecycle management, tool discovery/status, instance management, and file import. There is some potential overlap between search_tools, check_tools, and list_tool_groups because all relate to discovering or checking tools, but the descriptions clarify when each should be used.
All tools use snake_case with a clear verb_noun pattern: load_tool_group, unload_tool_group, check_tools, search_tools, import_file, list_instances, connect_instance. Singular/plural differences such as load_tool_group versus list_tool_groups are semantically appropriate rather than inconsistent.
The eight listed tools form a well-scoped static bridge layer for connection, import, and tool-group management. Additional Ghidra analysis tools are loaded dynamically, so the static count is appropriate rather than bloated.
The static surface covers instance discovery/connect, binary import, tool-group loading/unloading, and tool search/check. Core reverse-engineering operations are not in this static list but become available after connecting and loading groups; minor lifecycle gaps such as explicit disconnect or program close/save remain.