IDA MCP

Official

by HexRaysSA

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.7.0
Disambiguation5/5
Each tool targets a distinct action: opening, listing, saving, closing, executing Python, or fetching API references. Even 'reference' is clearly separate from 'execute_python' since it returns documentation-style reference text rather than running code. There is no meaningful overlap or ambiguity among the six tools.
Naming Consistency4/5
Most tools follow a clear verb_noun pattern: open_database, save_database, close_database, list_databases, execute_python. The only outlier is 'reference', which lacks a verb or explicit object and breaks the otherwise consistent naming convention.
Tool Count5/5
Six tools is well-scoped for an IDA database management and execution server. Each tool serves a necessary lifecycle or discovery purpose, and none feel redundant or gratuitous.
Completeness4/5
The core workflow of discovering, opening, executing in, saving, and closing databases is fully covered, plus API reference lookup. A minor gap is the lack of an explicit create/new database operation, though that may be intentionally handled outside this server's responsibilities.
Average 3.8/5 across 6 of 6 tools scored. Lowest: 2.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- Last stable release on August 27, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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

Behavior2/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 for behavioral disclosure. It only states the target type and says nothing about side effects, lifecycle implications, or what happens when a GUI instance is or is not available. Even though the schema mentions set_current and GUI availability, the description itself adds minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but it is under-specified rather than appropriately concise. It omits useful context and leaves the meaning of key terms to inference, so brevity comes at the cost of clarity.
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?
Given that the schema documents both parameters and an output schema exists, a basic invocation is possible. However, the overall definition lacks explanation of the GUI versus idalib worker distinction, tool-choice semantics relative to siblings, and behavioral consequences, so it is only minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-level meaning, but both path and set_current are already well documented in the schema, including the default value and relationship to execute_python().
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a verb ('Attach') and a resource ('GUI database or shared managed idalib worker'), so it is not a tautology. However, 'GUI database' and 'idalib worker' are undefined jargon, and it does not explicitly distinguish itself from sibling tools like reference or list_databases. The purpose is recognizable but vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use open_database versus close_database, list_databases, or execute_python. No prerequisites, exclusions, or alternative conditions are stated. The only hint is buried in the set_current parameter schema, not in the main description.
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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only states that the tool saves a database; it does not explain what saving entails, whether it overwrites existing state, whether it requires an open database, or what errors may occur.
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 a single, front-loaded sentence with no wasted words. It states the action, the resource, and the scope ('active GUI or idalib database') efficiently.
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 low-complexity tool with one fully documented parameter and an output schema, the description is nearly sufficient. However, the lack of annotations and the presence of lifecycle siblings like open_database and close_database suggest that a bit more context about prerequisites or effects would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already explains that instance_id is optional and that omission targets the current database. The description adds little beyond the schema, which is acceptable because the parameter meaning is already fully documented.
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 names a specific action ('save') and a specific resource ('active GUI or idalib database'), so the tool's purpose is immediately clear. It also distinguishes itself from the sibling lifecycle tools such as open_database, close_database, and list_databases.
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 phrase 'active ... database' implies the tool should be used on a database that is already open or targeted, which gives some contextual guidance. However, it does not explicitly state when to use this tool instead of close_database, when saving is necessary, or what happens if no active database exists.
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?
There are no annotations, so the description carries the burden of behavioral disclosure. The word 'Discover' suggests a read-only listing operation, and 'registered' indicates it returns pre-configured databases. However, it does not explicitly state the absence of side effects or mention any connection/auth requirements.
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 a single, front-loaded sentence with no filler. Every word contributes to identifying the tool's purpose.
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?
The tool is simple with no parameters and has an output schema, so the description is largely sufficient. However, it omits any contextual detail about when to call it, such as 'use before opening or saving a database,' which would make the intent fully complete.
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 the baseline is 4. There is no additional parameter meaning needed.
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 action ('Discover') and a clear resource ('registered GUI and idalib databases'). It is immediately distinguishable from the sibling tools such as save_database, open_database, and close_database, which perform different operations.
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 this tool is used to discover existing databases before interacting with them, but it does not explicitly say when to use it versus alternatives or provide exclusions. The sibling context helps, but the description itself offers no explicit guidance.
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?
There are no annotations, so the description carries the burden of behavioral disclosure. 'Look up' implies a read-only operation and 'plain-text' discloses the return format, but it does not explicitly state side-effect profile, behavior on unknown queries, or dependence on an active domain beyond the word 'active.'
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?
A single, direct sentence conveys the action, target, and output with no filler or redundancy. The key scoping detail ('active ida-domain API') is front-loaded.
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 lookup tool, this is mostly adequate, but the description leaves some gaps: no output schema exists, yet return details are only 'plain-text IDA reference,' and there is no mention of no-match behavior or what 'active ida-domain API' precisely means.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the query parameter is already documented as 'Class, method, or reverse-engineering concept.' The description adds no material meaning beyond what the schema provides, so the baseline score of 3 applies.
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 names a specific action ('Look up'), a specific resource ('the active ida-domain API'), and a concrete output ('plain-text IDA reference'). It is clearly distinct from sibling tools that manage databases or execute Python.
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 clearly implies this tool is for retrieving IDA reference information about a class, method, or concept. It does not explicitly name alternatives or state when not to use it, but the purpose is clear enough for an agent to route to it.
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 present, the description carries full behavioral burden and does so well. It discloses that other clients are not disrupted, that orphaned execution is cancelled on final lease, that the call blocks until closing finishes, and that GUI databases are never affected.
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?
Three dense sentences with no filler. The main purpose is front-loaded, followed by key edge-case behavior and an exclusion. Every sentence adds meaningful information.
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 low parameter complexity, full schema coverage, and existing output schema, the description is sufficient. It covers purpose, side effects, blocking behavior, lease semantics, and GUI exclusion without needing to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, instance_id, is fully documented in the input schema with its default and behavior when omitted. The description adds no extra parameter detail, but the schema already provides complete coverage, so baseline 3 is appropriate.
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?
Description states a specific action: 'Release this MCP server's handle' rather than closing a database outright. This clearly distinguishes close_database from siblings like open_database, save_database, list_databases, and reference.
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?
Provides clear context on when to use the tool: releasing a handle, potentially on a final lease, and explicitly excludes GUI databases with 'GUI databases are never closed here.' It does not name a specific alternative tool for GUI database closing, but the when-not condition is clear.
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 fully carries the burden and does so well: it discloses cross-call persistence, automatic invocation of run(db)/execute(db)/main(db), single/trailing expression return, captured stdout/stderr, and timeout behavior excluding the autoanalysis wait. This goes well beyond typical 'executes code' descriptions.
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 main description is one focused sentence with the key output promise front-loaded, and the longer parameter descriptions are dense but organized around distinct semantics. No filler or repetition of the schema.
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?
The definition is nearly complete: it explains environment, state persistence, invocation conventions, timeout, target selection, and output capture, and the output schema covers return shape. It lacks an explicit warning that arbitrary Python may mutate the database or cause side effects, which is more salient because no annotations exist.
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?
All three parameters are described with 100% coverage, and the code parameter description adds substantial operational meaning: the execution environment, available globals (db, ida_domain), required reference() pattern, persistence, and return conventions. The timeout and instance_id descriptions also clarify defaults and exclusions.
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?
States a specific action ('Execute Python') and return behavior ('result plus captured stdout and stderr'), which clearly differentiates it from the database-lifecycle siblings. The function-style invocation rules in the code parameter further pin down what the tool does.
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 instructs the agent to call reference(query) first and not guess the API shape, and states that code runs against an already-open database. It does not explicitly contrast with siblings, but the prerequisite and persistence guidance give clear context.
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:

[![ida-mcp MCP server](https://glama.ai/mcp/servers/HexRaysSA/ida-mcp/badges/card.svg)](https://glama.ai/mcp/servers/HexRaysSA/ida-mcp)

Score Badge

Copy to your README.md:

[![ida-mcp MCP server](https://glama.ai/mcp/servers/HexRaysSA/ida-mcp/badges/score.svg)](https://glama.ai/mcp/servers/HexRaysSA/ida-mcp)

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/HexRaysSA/ida-mcp'

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