ghidra-mcp-aarch64

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v7.0.0
Disambiguation4/5
Most tools have clearly distinct roles: instance management, group loading, tool discovery, and file import are well separated. check_tools and search_tools are the only slightly overlapping pair, but their purposes are distinguishable: checking specific tools vs. searching the catalog.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern (list_instances, load_tool_group, search_tools, import_file). The naming convention is uniform and predictable across the entire set.
Tool Count5/5
Eight tools is well-scoped for a bridge/management layer that dynamically registers additional analysis tools after connection. Each tool serves a distinct management or setup function, and none feel redundant.
Completeness4/5
The bridge lifecycle is well covered: list/connect instances, manage tool groups, check/search tools, and import files. Minor gaps exist, such as no explicit disconnect tool or current-instance introspection, but the core workflows are supported.
Average 3.9/5 across 8 of 8 tools scored. Lowest: 1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 does disclose that the action unloads all tools in a category and that default groups are protected, but it omits whether the operation is reversible, whether it affects active instances, or how errors for invalid or protected groups are surfaced.
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 compact: one main action sentence, one protective-exception sentence, and a simple args block. It is front-loaded and contains no filler or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the description covers the core operation, the parameter, and one important safety exception. However, because there are no annotations, it lacks operational context such as where valid category names come from, whether unloading is permanent, and how protected groups behave when targeted.
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?
The input schema only states that 'group' is a required string, with 0% schema description coverage. The description adds the needed semantic meaning by explicitly defining it as 'Category name to unload,' which is essential for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Unload all tools') and identifies the resource ('a category'), making the tool's action clear and differentiating it from the load_tool_group sibling. It does not explicitly name that sibling or clarify that 'category' maps to a tool group from list_tool_groups, so differentiation is implicit rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when every tool in a category should be removed. It also provides a clear exclusion with 'Default groups are protected from unloading,' but it does not mention alternatives like load_tool_group or explain that list_tool_groups should be consulted for valid category names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral effects, but it only says 'load' without explaining side effects: whether loading a category replaces previously loaded tools, whether tools are added cumulatively, whether authentication or a connection is required, or whether the operation mutates global state. This is a meaningful transparency gap for a state-changing operation.
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 compact and front-loaded: the first sentence states the core action, the second gives a useful discoverability pointer, and the Args section adds the parameter semantics. No sentence is wasted or redundant with structured data.
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 simple one-parameter loader with an output schema available, the description covers how to invoke it and how to find valid argument values. The main omission is behavioral side-effect disclosure, but the tool is simple enough that the missing details do not prevent correct invocation.
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?
The input schema provides only a bare string declaration with no description, so schema coverage is 0%. The description compensates by explaining the parameter as 'Category name' and providing concrete examples ('function', 'datatype') plus the special value 'all', and points to list_tool_groups() for discovering valid options. This is adequate for a single parameter.
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 states a precise verb and resource: 'Load all tools in a category.' It further clarifies the special 'all' mode that loads everything. This is distinct from the sibling unload_tool_group and is clearly positioned by the pairing of 'load' and 'category.'
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 usage context by telling the agent to call list_tool_groups() to discover available category names. It does not explicitly state when not to use this tool or compare it to alternatives like search_tools, but the prerequisite guidance is practical and sufficient for a single-purpose loader.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It appropriately discloses that the tool checks live callability and explains the meaning of each returned status. It does not explicitly state that it has no side effects, but the non-mutating check behavior is strongly implied by the description and status values.
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?
Every sentence earns its place. The core purpose comes first, the status vocabulary follows immediately, and the parameter guidance is compact with an example. No filler or redundancy.
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 simple one-parameter tool with an output schema, the description is fully sufficient. It covers what the tool does, what it returns, and how to format the argument. Nothing essential is missing for an agent to select and invoke it 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?
The schema only says 'tools' is a string with no description coverage. The description fully compensates by explaining that it accepts comma-separated tool names and providing a concrete example. This gives the agent the exact format needed to call the tool successfully.
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 clearly states a specific verb-resource pairing: 'Check if specific tools are callable right now.' It also defines the tool's output statuses (callable, not_loaded, not_found), which differentiates it from sibling tools like search_tools or list_tool_groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: verify whether specific tools are callable before invoking them. However, the description does not explicitly state when to prefer this over alternatives, such as list_tool_groups or load_tool_group, nor does it mention conditions when it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden and does so thoroughly. It discloses that only static tools are available before connect, that the bridge fetches /mcp/schema and dynamically registers tools after connect, that --lazy mode limits initial tool groups, and that clients caching tools/list must re-list after the call. This is rich, non-obvious behavioral context that significantly aids correct invocation.
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 longer than average but every sentence contributes useful operational context: prerequisites, dynamic registration, lazy loading, and caching caveats. The main action and parameter note are front-loaded, with important caveats following in an organized manner. It is somewhat dense but not wasteful.
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 state-changing connection tool with no annotations, the description is remarkably complete: it explains pre-conditions, post-conditions, lazy-loading implications, and client caching consequences. It does not detail failure modes or what happens if the project name is ambiguous, but the provided output schema covers return structure and the core guidance is sufficient for correct use.
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?
The input schema only says 'project' is a required string, but the description adds 'Project name (or substring) to connect to,' clarifying both the meaning and matching behavior. Since schema description coverage is 0%, this parameter note meaningfully compensates, though it could go further with details like case sensitivity or exact-match fallback.
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: 'Switch the MCP bridge to a different Ghidra instance by project name.' This clearly states the action and object, and it naturally distinguishes from siblings like list_instances, which only lists instances, and load_tool_group, which manages tool groups after connection.
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 explicit prerequisite guidance: 'Use list_instances() first to see available instances.' It also explains when the tool is needed, noting that before connecting only static bridge tools are exposed and that analysis tools are registered dynamically after a successful connect. It does not explicitly discuss when not to use the tool, but there are no true alternatives among the listed siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return content in detail: category, tool count, loaded status, and tool names. Since the tool takes no parameters and is inherently a read/list operation, this level of transparency is appropriate, though it does not mention edge cases or error behavior.
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 extremely concise: two sentences that state what the tool does, what it returns, and which sibling to use for the next step. Every sentence earns its place and the action is front-loaded.
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 zero-parameter listing tool with an output schema available, the description covers the essential facts: what is listed, what information will be returned, and how to proceed if the goal is to load a group rather than merely list it. Nothing important is missing.
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?
The tool has zero parameters, so there is no parameter semantics to explain. The description correctly focuses on outputs rather than inputs, matching the baseline for a no-parameter tool.
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 clearly states the action ('List all available tool groups') and the resource ('tool groups'), and it specifies exactly what information is returned. This distinguishes it from siblings like list_instances and load_tool_group by naming the resource and the related action.
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 provides clear context for when to use the tool: it lists groups, and if you need to actually load a group, it points to load_tool_group(group). It does not explicitly state when not to use it or exhaustively compare with all siblings, but the guidance is sufficient for this simple listing tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that the tool imports the file, opens it in CodeBrowser, optionally runs auto-analysis, and sends a log notification when analysis finishes. This is good coverage, though it does not describe edge-case behaviors such as overwriting or import failures.
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 front-loaded with the primary purpose, then adds focused behavioral context and a compact Args list. Every sentence adds value, and the formatting makes it easy for an agent to scan.
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 covers return values and the description covers behavior, parameters, defaults, and analysis flow, nothing critical is missing for selecting and invoking this tool. The guidance on raw firmware versus auto-detected formats is especially valuable context.
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, so the description must fully compensate. It explains every parameter, gives defaults, provides concrete language examples, and clarifies how compiler_spec relates to the language default. This goes well beyond the schema alone.
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: 'Import a binary file from disk into the current Ghidra project.' It clearly distinguishes this from the sibling tools, which manage instances and tool groups rather than importing files.
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 conditional guidance for when to specify language and compiler_spec versus relying on auto-detection for known formats. It does not discuss alternatives because the sibling tools are unrelated, but the context for using the tool correctly is well stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds valuable behavior: it searches unloaded groups, matches name/description/category, reports whether each tool is immediately callable, and provides the exact load_tool_group(...) call when needed. The search semantics are clearly read-only, though it doesn't explicitly state side-effect-free behavior.
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 well-structured and front-loaded: first the purpose, then the key behavioral promise, then parameter details. Every sentence adds value, and the practical usage hint about --lazy is relevant rather than filler.
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?
The description covers purpose, when to use it, parameter semantics, and interesting return behavior. An output schema exists to formalize the result shape, and no annotations are needed for a clearly read-only search operation. Nothing essential is missing for correct invocation.
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?
Schema description coverage is 0%, so the description fully compensates. It explains query as space-separated keywords with concrete examples, and explains limit as the maximum result count with its default. This is clear, actionable parameter documentation beyond 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 states a specific verb ('Search'), a clear resource ('the full Ghidra tool catalog'), and a distinguishing scope: it searches by keyword including tools whose group is not currently loaded. This clearly differentiates it from siblings like list_tool_groups and load_tool_group.
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?
Explicitly tells the agent when to use this tool: to discover the right tool on demand while avoiding the context cost of loading all groups, especially with --lazy. It doesn't spell out when-not-to-use or name alternatives, so it stops just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ghidra-mcp-aarch64 MCP server](https://glama.ai/mcp/servers/nawidodo/ghidra-mcp-aarch64/badges/card.svg)](https://glama.ai/mcp/servers/nawidodo/ghidra-mcp-aarch64)

Score Badge

Copy to your README.md:

[![ghidra-mcp-aarch64 MCP server](https://glama.ai/mcp/servers/nawidodo/ghidra-mcp-aarch64/badges/score.svg)](https://glama.ai/mcp/servers/nawidodo/ghidra-mcp-aarch64)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nawidodo/ghidra-mcp-aarch64'

If you have feedback or need assistance with the MCP directory API, please join our Discord server