ghidra-mcp-aarch64
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| JAVA_OPTS | No | JVM options (default: -Xmx4g -XX:+UseG1GC) | -Xmx4g -XX:+UseG1GC |
| GHIDRA_MCP_PORT | No | Server port (default: 8089) | 8089 |
| GHIDRA_SERVER_USER | No | Username for connecting to a shared Ghidra Server. Defaults to user.name system property. | |
| GHIDRA_DEBUGGER_URL | No | URL of the standalone debugger server. When set, the bridge's 22 debugger_* proxy tools are registered. | |
| GHIDRA_MCP_FILE_ROOT | No | When set to a directory path, filesystem-path endpoints canonicalize the input and require it to fall under this root. Prevents path-traversal. | |
| GHIDRA_MCP_AUTH_TOKEN | No | When set, every HTTP request must carry Authorization: Bearer <token>. Timing-safe comparison. /mcp/health, /health, /check_connection are exempt. | |
| GHIDRA_SERVER_PASSWORD | No | Password for connecting to a shared Ghidra Server, suppressing the password dialog. | |
| GHIDRA_MCP_BIND_ADDRESS | No | Bind address (default: 0.0.0.0 in Docker) | 0.0.0.0 |
| GHIDRA_MCP_ALLOWED_HOSTS | No | Additional hosts allowed for HTTP transports' CORS/origin checks, in addition to loopback and the bind host. | |
| GHIDRA_MCP_ALLOW_SCRIPTS | No | Set to 1, true, or yes to enable /run_script_inline and /run_ghidra_script. Off by default. | false |
| GHIDRA_MCP_REQUIRE_PROGRAM_SELECTORS | No | Set to 1 to make the bridge refuse any program-scoped call that omits a program selector. | 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
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_instancesD | – |
| 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
Most tools have clearly distinct roles: instance management, group loading, tool discovery, and file import are well separated. check_tools and search_tools are the only slightly overlapping pair, but their purposes are distinguishable: checking specific tools vs. searching the catalog.
All tool names follow a consistent snake_case verb_noun pattern (list_instances, load_tool_group, search_tools, import_file). The naming convention is uniform and predictable across the entire set.
Eight tools is well-scoped for a bridge/management layer that dynamically registers additional analysis tools after connection. Each tool serves a distinct management or setup function, and none feel redundant.
The bridge lifecycle is well covered: list/connect instances, manage tool groups, check/search tools, and import files. Minor gaps exist, such as no explicit disconnect tool or current-instance introspection, but the core workflows are supported.