Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Ghidra MCP Server list all functions in the binary at /path/to/malware.exe"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
This project lets you use Ghidra in headless mode to extract rich binary analysis data (functions, pseudocode, structs, enums, etc.) into a JSON file, and expose it to LLMs like Claude via Model Context Protocol (MCP).
It turns Ghidra into an interactive reverse-engineering backend.
Decompiles a binary using Ghidra headless mode
Extracts:
Function pseudocode, names, parameters, variables, strings, comments
Data structures (structs), enums, and function definitions
Outputs to ghidra_context.json
MCP server exposes tools like:
list_functions(), get_pseudocode(name)
list_structures(), get_structure(name)
list_enums(), get_enum(name)
list_function_definitions(), get_function_definition(name)
Related MCP server: Ghidra MCP Server
macOS (tested)
Python 3.10+
Ghidra 11.3.1+
Java 21 (Temurin preferred)
MCP client (e.g. Claude Desktop)
brew install --cask temurin@21Then set it:
export JAVA_HOME=$(/usr/libexec/java_home -v 21)
echo 'export JAVA_HOME=$(/usr/libexec/java_home -v 21)' >> ~/.zshrc
source ~/.zshrcCheck it:
java -versionShould say: openjdk version "21.0.x"...
Download and extract Ghidra 11.3.1
cd ghidra_mcp
gcc -Wall crackme.c -o crackmemcp install main.pyThis registers the MCP server so Claude or other clients can access it.
mcp dev main.pyThis enables hot reload and developer logs.
Tool | Description |
| Run Ghidra on a binary |
| All functions |
| Decompiled pseudocode |
| All structs |
| Details of a struct |
| All enums |
| Enum values |
| All function prototypes |
| Return type & args |
Analyze the binary file located at using Ghidra installed at . First, set up the analysis context using both paths, then list all functions in the binary. Examine the main entry point function and provide a high-level overview of what the program does.
➡️ Fix: Install Java 21, not 17 or 24:
brew install --cask temurin@21
export JAVA_HOME=$(/usr/libexec/java_home -v 21)spawn uv ENOENT (Claude Desktop can't find your UV binary)➡️ Claude can't locate uv by name. To fix:
Run in your terminal:
which uvExample output:
/Users/yourname/.cargo/bin/uvOpen your Claude Desktop config file:
open ~/Library/Application\ Support/Claude/claude_desktop_config.jsonUpdate it like so:
{
"mcpServers": {
"ghidra": {
"command": "/Users/yourname/.cargo/bin/uv",
"args": [
"--directory",
"/Users/yourname/Documents/ghidra_mcp",
"run",
"main.py"
]
}
}
}Restart Claude Desktop. You should now see your custom MCP tools.
The operation couldn’t be completed. Unable to locate a Java Runtime.➡️ Fix: Java not installed or JAVA_HOME is unset. Follow setup instructions above.
File | Purpose |
| MCP server with tools |
| Ghidra script that extracts JSON |
| Sample C binary |
| Compiled binary to test |
Get details of a specific enum by name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'gets details' but doesn't specify what those details include, whether it's a read-only operation, potential errors, or response format. This leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized and front-loaded, clearly stating the core action without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what details are returned, potential behaviors, or how it fits with sibling tools, making it inadequate for a tool with one parameter and no structured support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions the parameter 'name' but doesn't add meaning beyond what the schema implies (e.g., format, examples, or constraints). This fails to address the coverage gap adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get details') and resource ('a specific enum by name'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'list_enums' or 'get_structure', which would require specifying what details are retrieved or how this differs from listing enums.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't specify when to use 'get_enum' instead of 'list_enums' or other sibling tools, nor does it mention prerequisites or contexts for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific function definition by name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'gets details' but doesn't specify what details are returned, whether it's a read-only operation, error handling, or any constraints. This leaves significant gaps for a tool with unknown behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't explain what 'details' are returned, how to handle errors, or provide context for the single parameter, making it insufficient for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions the parameter 'name' but doesn't add meaning beyond what the schema's title 'Name' implies, such as format, examples, or scope. With 1 undocumented parameter, this is inadequate compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get details') and resource ('specific function definition by name'), making the purpose understandable. However, it doesn't differentiate this tool from similar siblings like 'get_enum', 'get_structure', or 'list_function_definitions' beyond specifying it's for function definitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'list_function_definitions' or 'get_pseudocode'. The description implies usage for retrieving details of a known function by name, but lacks explicit context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get pseudocode for a specific function by name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe how it behaves—e.g., whether it returns a single result or multiple, error handling for invalid names, format of the pseudocode output, or any side effects. This leaves significant gaps in understanding the tool's operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core action and target, making it easy to parse quickly. Every part of the sentence contributes directly to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of retrieving pseudocode (which may involve parsing or transformation), no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't address what the output looks like, error conditions, or how it interacts with sibling tools, leaving the agent with insufficient context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, with one parameter 'name' documented only by its title. The description adds minimal semantics by specifying it's 'for a specific function by name', implying 'name' refers to a function identifier. However, it doesn't clarify format (e.g., case sensitivity, naming conventions) or provide examples, which is insufficient given the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get pseudocode') and the target ('for a specific function by name'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential siblings like 'get_function_definition' or 'list_functions', which might retrieve similar information but in different formats or scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_function_definition' and 'list_functions' available, there's no indication of whether this tool is preferred for pseudocode retrieval, what distinguishes it from those tools, or any prerequisites for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific structure by name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a read operation ('Get details'), which implies it's non-destructive, but doesn't address permissions, rate limits, error handling, or what 'details' include. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized for a simple lookup tool and front-loads the core purpose effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't explain what 'details' are returned, error cases (e.g., invalid name), or how this fits with sibling tools. For a tool in this context, more guidance is needed to help an agent use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions the parameter 'name' and implies it's used to identify a specific structure, but doesn't explain format constraints, valid values, or how it relates to other tools (e.g., if names come from 'list_structures'). This adds minimal semantic value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get details') and resource ('specific structure by name'), making the purpose unambiguous. However, it doesn't differentiate this tool from its sibling 'list_structures', which might also retrieve structure information but in a list format rather than by specific name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list_structures' or other sibling tools. It doesn't mention prerequisites, error conditions, or contextual constraints, leaving the agent with minimal usage direction beyond the basic operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all enum names from the loaded binary.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe the return format (e.g., list of strings, JSON array), pagination behavior, error conditions, or whether this is a read-only operation. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose with zero wasted words. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the output looks like (e.g., format, structure), potential errors, or dependencies on other tools like setup_context. For a tool in a binary analysis context with siblings, more contextual information would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (though trivial since there are no parameters). The description doesn't need to explain parameters, so it meets the baseline expectation for parameterless tools. No additional parameter semantics are required or provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all enum names') and the resource ('from the loaded binary'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate this tool from its sibling 'get_enum' (which presumably retrieves details for a specific enum), leaving room for potential confusion about when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_enum' or other list_* siblings. It lacks context about prerequisites (e.g., whether setup_context must be called first) or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all function definition names from the loaded binary.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it's a list operation but doesn't describe output format, pagination, sorting, or potential errors. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states what the tool does without any fluff. It's front-loaded with the core action and resource, making it immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema, the description adequately covers the basic purpose but lacks details about output format, error conditions, or differentiation from siblings. Given the simplicity of the tool, it's minimally viable but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the lack of inputs. The description appropriately doesn't add parameter details, maintaining focus on the tool's purpose without unnecessary repetition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('function definition names from the loaded binary'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_functions' or 'get_function_definition', which could cause confusion about scope or output format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list_functions' or 'get_function_definition'. It mentions 'loaded binary' as context but doesn't specify prerequisites, exclusions, or comparative use cases with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all function names from the loaded binary.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool lists function names but doesn't describe the return format (e.g., array of strings, pagination), performance characteristics (e.g., speed, memory usage), or any constraints (e.g., binary must be loaded, may be read-only). This leaves significant gaps for an agent to understand how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core functionality without unnecessary words. It's front-loaded with the essential action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate but incomplete. It lacks behavioral details (e.g., return format, prerequisites) and usage context compared to siblings, which are important for an agent to operate effectively in this server environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter details, so it appropriately focuses on the tool's purpose. A baseline of 4 is justified since no parameters exist to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('function names from the loaded binary'), making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from its siblings like 'list_function_definitions' or 'get_function_definition', which likely provide more detailed function information rather than just names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether a binary must be loaded first), compare it to siblings like 'list_function_definitions' for more details, or specify use cases (e.g., for quick overview vs. in-depth analysis).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all structure names from the loaded binary.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe return format, pagination, sorting, error conditions, or performance characteristics. For a list operation with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately conveys the core functionality without unnecessary words. It's appropriately sized for a zero-parameter tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should provide more context about what 'structure names' means, how they're formatted, whether the list is complete or filtered, and what happens if no binary is loaded. The current description is too minimal for a tool that presumably returns structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't waste space discussing parameters that don't exist, maintaining focus on the tool's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('structure names from the loaded binary'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_enums' or 'list_functions', which would require more specific scope definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_structure' or other list tools. It doesn't mention prerequisites (e.g., whether a binary must be loaded first) or contextual constraints, leaving usage decisions ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Ghidra headless decompilation to export binary context.
| Name | Required | Description | Default |
|---|---|---|---|
| ghidra_path | No | /Users/tomi/Downloads/ghidra_11.3.1_PUBLIC | |
| binary_path | No | /Users/tomi/Documents/ghidra_mcp/crackme |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'headless decompilation' and 'export binary context', implying a potentially resource-intensive or setup-oriented operation, but doesn't clarify critical aspects like whether this is a one-time setup, what permissions are needed, if it modifies files, or what the output format is. The description is too vague for a tool that likely performs significant processing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and outcome, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by 'headless decompilation' and 'export binary context', along with no annotations, 0% schema description coverage, and no output schema, the description is inadequate. It doesn't explain what 'binary context' includes, how the output is structured, or any behavioral traits, leaving significant gaps for an AI agent to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The tool description doesn't mention any parameters at all, failing to compensate for the schema gap. However, with only 2 parameters (both with default values and clear titles like 'Ghidra Path'), the baseline is moderate since the titles are somewhat self-explanatory, but the description adds no value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run Ghidra headless decompilation') and the outcome ('export binary context'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate this tool from its siblings (like get_pseudocode or list_functions), which all appear to work with Ghidra decompilation outputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing Ghidra installed), when this tool is appropriate (e.g., initial setup vs. querying), or how it relates to sibling tools like get_pseudocode that might depend on its output.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
get_enumget_function_definitionget_pseudocodeget_structurelist_enumslist_function_definitionslist_functionslist_structuressetup_contextEvery tool has a clearly distinct purpose with no ambiguity. The 'get_' tools retrieve specific details for different binary elements (enum, function definition, pseudocode, structure), while the 'list_' tools enumerate names for those same elements, and 'setup_context' performs a distinct initialization task. There is no overlap in functionality that could cause misselection.
Tool names follow a highly consistent verb_noun pattern throughout. All tools use snake_case with clear prefixes: 'get_' for retrieval, 'list_' for enumeration, and 'setup_' for initialization. This predictable naming scheme makes it easy for agents to understand and select the appropriate tool.
With 9 tools, the server is well-scoped for its purpose of binary analysis with Ghidra. Each tool earns its place by covering distinct aspects of binary inspection (enums, functions, structures, pseudocode) and initialization. This count is typical for a domain-specific server and avoids being too thin or overwhelming.
The tool surface provides comprehensive read-only coverage for binary analysis, including listing and retrieving details for key elements like functions, structures, and enums, plus pseudocode and setup. A minor gap exists in write operations (e.g., modifying or creating elements), but agents can effectively work around this for analysis tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Codebase intelligence for agents: 152 structured artifacts across 21 programs, one call.
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Hunt zero-days by talking to binaries. 40+ tools. Hosted, OAuth + SSO, invite: hi@byteray.ai
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Bamimore-Tomi/ghidra_mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
