#163·GhidraMCP

Ghidra MCP Improvement Suggestions

Author: caryyuCreated Jun 7, 2026Updated Jun 7, 2026

Ghidra MCP Improvement Suggestions

This note summarizes generic improvement ideas observed during an interactive static-analysis workflow. It intentionally avoids project names, private module names, business context, and private addresses so it can be used as issue feedback.

Connection And Instance Discovery

  1. Instance discovery should clearly show the MCP bridge port, Ghidra project name, currently opened program, connection state, and schema loading state.
  2. When a user specifies a port that does not match the MCP configuration, provide actionable diagnostics such as detected listening ports, expected port, and connection failure reason.
  3. After connect_instance succeeds, return the currently loaded tool groups and a short list of available core tools.
  4. For lazy-loaded tool groups, clearly indicate which tools exist but are not loaded, and which tool group should be loaded.

Import And Analysis State

  1. After importing a dump or unpacked binary, expose analysis status: whether auto-analysis finished, remaining task count, failed analyzers, language, and compiler spec.
  2. Import results should include image base, entry point, section list, executable ranges, and likely original entry point when available.
  3. For dumps with missing or unfixed IAT, report whether import tables exist, whether external functions are recognized, and which thunks or indirect calls remain unresolved.

Static/Dynamic Address Mapping

  1. Provide a unified runtime-address to Ghidra-address mapping helper using module runtime base, Ghidra image base, and input address.
  2. Return absolute address, RVA, and image base for disassembly, functions, xrefs, and labels so results can be correlated with dynamic-debugger logs.
  3. Support a workflow for importing a debugger module list and applying address mappings in bulk.

Function And Decompiler Helpers

  1. Add high-level APIs for creating a function at an address, re-decompiling it, retrieving pseudocode, and listing callers/callees.
  2. When function boundaries are uncertain, return a confidence hint or warning such as “address is not inside a function” or “function may be misidentified”.
  3. Improve support for register-based calling conventions commonly seen in Delphi/C++Builder-style binaries.
  4. Support batch rename, batch comments, and batch function signature updates with per-item success/failure details.

IAT And External Function Recovery

  1. Provide semi-automated IAT recovery helpers that scan API thunks, indirect calls, and GetProcAddress result tables and generate candidate imports.
  2. Allow manually marking an address as an external function stub and binding it to a DLL name, function name, and calling convention.
  3. Provide a sorted list of unresolved calls/jumps, ranked by reference count and call-site context, to prioritize import recovery.

Debugger Collaboration

  1. Support creating Ghidra labels or comments directly from a dynamic-debugger hit address by converting runtime address to Ghidra address.
  2. Support importing debugger breakpoints, traces, and watch logs as Ghidra bookmarks or comments.
  3. Provide a “get decompiler context for current EIP/RIP” workflow to reduce manual address translation between tools.

Result Output

  1. Return structured JSON plus a short human-readable summary where practical.
  2. Support pagination or segmented output for long decompiler results, including function summary, local variables, and call graph fragments.
  3. On failure, distinguish whether the problem is incomplete Ghidra analysis, unmapped address, unloaded tool group, or MCP bridge connection failure.