ghidra-mcp

Overview Schema Source Related Servers Discussions Admin

search

Locate scalar immediates, text matches, or byte patterns in Ghidra programs with scope options for instructions, data, symbols, comments, and decompiled code.

Instructions

Search program content.

Scalar search finds instruction operand scalars/immediates and, if
requested, defined data scalar values. Pass one integer value or multiple
comma/space-separated values such as `0x27,0x67`.

Text search finds substring matches in instruction text, defined data text,
symbol names, comments, and decompiled functions depending on `where`.
`where="decompiled"` searches decompiler C output and returns matching
functions with line excerpts.

Byte search finds raw byte patterns in initialized memory. Queries accept
bytes separated by spaces or commas, or contiguous hex such as
`1d6c7ee1`. `context` controls how many bytes before and after each byte
match are included in the result. When
`include_nearby_function_pointers=true`, byte-search results also include
raw pointer-sized values in the returned context that resolve to function
entry points.

Args:
    query: Search query. For scalar search, one or more integer values.
    program: Required Ghidra project path or name to target.
    kind: Search kind: `scalar`, `text`, or `bytes`.
    where: Search scope. Scalar supports `instructions`, `data`, or `all`.
        Text also supports `symbols`, `comments`, and `decompiled`. Byte
        search currently scans initialized memory.
    limit: Maximum matches to return. Use 0 or None for no limit.
    case_sensitive: Use case-sensitive matching for text search.
    context: Bytes of context before/after byte-search matches.
    include_nearby_function_pointers: For byte search, report nearby raw
        pointers that resolve to function entry points.

Input Schema

TableJSON Schema

Name	Required	Default
`kind`	No	scalar
`limit`	No
`query`	Yes
`where`	No	instructions
`context`	No
`program`	Yes
`case_sensitive`	No
`include_nearby_function_pointers`	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.8/5.0

Behavior5/5

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

No annotations are provided, so the description carries the full transparency burden, and it succeeds. It states what each kind matches, that byte search is limited to initialized memory, that context adds surrounding bytes, and that include_nearby_function_pointers resolves pointer-sized values to function entries. It also clarifies result shape for decompiled-text searches.

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

Conciseness5/5

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

The description is long but well-organized: an intro sentence, three mode paragraphs, and an Args block that covers all parameters without repeating anything unnecessary. For an 8-parameter, three-mode tool, the length is justified and each section earns 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?

For a complex multi-mode search tool with no annotations and zero schema descriptions, this is thorough: all modes, scopes, query formats, limits, and byte-search nuances are covered. Since an output schema exists, the description need not enumerate return values, and it provides the contextual hints an agent needs to call the tool correctly.

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?

With 0% schema coverage, the Args block compensates by explaining every parameter: query accepts comma/space-separated integers, kind takes scalar/text/bytes, where enumerates mode-specific scopes, limit uses 0 or None, and byte-specific flags are tied to their mode. It provides concrete examples and clarifies defaults where behavior changes.

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 'Search program content' and then immediately distinguishes three concrete search modes: scalar, text, and byte. This is far more specific than the bare tool name and lets an agent tell it apart from sibling read tools such as list_instructions or xrefs.

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?

The description gives clear mode-specific guidance: scalar for integer/immediates, text for substrings across scopes, byte for raw patterns in initialized memory, and it notes that where='decompiled' returns functions with line excerpts. It does not explicitly name sibling alternatives or exclusion conditions, but the context is clear enough to select the right search mode.

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

Deploy Server