ghidra-mcp

Overview Schema Source Related Servers Discussions Admin

xrefs

Resolve an address, label, or function to list its incoming and outgoing cross-references, including reference types and context. Optionally scan memory for raw pointer-byte matches to uncover non-recorded references.

Instructions

Get incoming and outgoing cross-references for an address, label, or function.

The target is resolved through Ghidra's `toAddr()` helper, so normal
address strings, exact label names, and exact function names are accepted.

The response is JSON containing the resolved address plus both incoming and
outgoing references, including reference type and nearby label/function
context for the opposite end of each edge.
When `include_pointer_bytes` is true, initialized memory is also scanned
for raw pointer-sized values equal to the resolved address. These are byte
matches, not Ghidra reference records.

Args:
    target: Address, exact label name, or exact function name to inspect.
    program: Required Ghidra project path or name to target.
    include_pointer_bytes: Also scan memory for raw pointer-byte matches.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`target`	Yes
`program`	Yes
`include_pointer_bytes`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Sep 15, 2026

TDQS

A4.5/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full behavioral burden. It discloses target resolution through Ghidra's toAddr(), JSON output shape, both incoming/outgoing edges, reference types, nearby label/function context, and raw pointer-byte scan behavior. It also explicitly distinguishes byte matches from Ghidra reference records.

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?

The description is well structured and front-loaded with the primary purpose, followed by helpful resolution and response details. It is slightly repetitive with the pointer-bytes explanation appearing twice, but every sentence adds enough value to justify its place.

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

Completeness5/5

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

Given the output schema exists, the description already covers the necessary context: target resolution, required parameters, optional behavior, and response content. The description is complete enough for an agent to call the tool correctly without needing further documentation or annotations.

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

Parameters5/5

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

The input schema has 0% description coverage, and the description fully compensates by explaining each of the three parameters: target's accepted forms, program as the required Ghidra project path/name, and include_pointer_bytes as the memory-scan switch. This provides all semantics missing from 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 description opens with a specific verb and resource: 'Get incoming and outgoing cross-references' for an address, label, or function. It clearly states the tool's scope and differentiates it from sibling tools such as list_instructions, labels, and address_info.

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 gives clear guidance on what target forms are accepted (address strings, exact label names, exact function names), the required program parameter, and the optional pointer-byte scan. It does not explicitly compare against an alternative tool or say when not to use it, but the context is strong enough for an agent to select it appropriately.

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

Deploy Server