Skip to main content
Glama
Sign In
Ghidra MCP Server

Ghidra MCP Server

by bethington
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

import_file

Imports a binary from disk into the current Ghidra project, opens it in CodeBrowser, and optionally runs auto-analysis; specify language for raw firmware when needed.

Instructions

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)

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "file_path": "<file_path>"
    },
    "name": "import_file"
  }
}

Input Schema

NameRequiredDescriptionDefault
languageNoLanguage ID for raw binaries (e.g. "ARM:LE:32:Cortex", "x86:LE:64:default")
file_pathYesAbsolute path to the binary file on disk
auto_analyzeNoStart auto-analysis after import (default: true)
compiler_specNoCompiler spec ID (e.g. "default", "gcc"). Uses language default if omitted.
project_folderNoDestination folder in the Ghidra project (default: "/")/

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv7.0.0
    • addedInput schema / properties / auto_analyze / description
      Added value: +"Start auto-analysis after import (default: true)"
    • addedInput schema / properties / compiler_spec / description
      Added value: +"Compiler spec ID (e.g. \"default\", \"gcc\"). Uses language default if omitted."
    • addedInput schema / properties / file_path / description
      Added value: +"Absolute path to the binary file on disk"
    • addedInput schema / properties / language / description
      Added value: +"Language ID for raw binaries (e.g. \"ARM:LE:32:Cortex\", \"x86:LE:64:default\")"
    • addedInput schema / properties / project_folder / description
      Added value: +"Destination folder in the Ghidra project (default: \"/\")"
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "import_fileOutput",
-  "type": "object"
-}New value: +null
  2. First observedv5.15.0

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only say readOnlyHint=false and destructiveHint=false; the description supplies the real behavior: the file is imported, opened in the CodeBrowser, and optionally auto-analyzed, with a log notification on completion. It omits failure behavior (unsupported format, duplicate program name) and whether analysis is long-running/blocking, so it falls short of full disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with purpose, then behavior, then the conditional parameter guidance, which is a sensible order. The trailing Args block duplicates the 100%-covered schema almost verbatim, so a few lines do not earn their place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutating import tool with no output schema, it covers the essential inputs and the analysis side effect, and the notification behavior compensates somewhat for the missing return-value description. It still leaves undefined what the call returns and what happens when a program of the same name already exists in the destination folder.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description earns one more by explaining the conditional semantics of `language` — omitting it triggers Ghidra format auto-detection — which the schema's field description does not state. The Args list otherwise largely restates the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a specific verb and resource ("Import a binary file from disk into the current Ghidra project") and names the target scope (current project). None of the sibling tools (tool-group/instance management) do anything similar, so there is no ambiguity about which tool handles binary import.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly states the condition for supplying language/compiler_spec (raw firmware binaries) versus relying on auto-detection (ELF, PE, Mach-O). It does not state any preconditions such as requiring an open/connected instance, nor any "when not to use" case, but the usage context is otherwise clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools