re-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| IDADIR | No | Path to IDA Pro installation directory | |
| GHIDRA_INSTALL_DIR | No | Path to Ghidra installation directory |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| close_databaseA | Close a database and terminate its worker process. Specify database when multiple are open. Fails if the DB is not attached to the current session unless force=True. When other sessions still use the DB, detaches this session but keeps the worker alive. |
| save_databaseA | Save the current database to disk (may take minutes for large DBs). Specify database when multiple are open. Fails if the DB is not attached to the current session unless force=True. Progress notifications are sent every 5s during long saves. |
| list_databasesA | List all open databases with metadata (includes opening/analyzing status). |
| wait_for_analysisA | Block until database(s) finish opening and optional auto-analysis. Single: pass While analysis runs, the backend thread is blocked — tool calls queue. |
| list_targetsA | List available targets (processors, loaders, languages, etc.). |
| open_databaseA | Open a binary or existing IDA database (.i64/.idb) for analysis. Returns immediately with Multiple binaries: use a separate subagent per binary. Each agent calls open_database then wait_for_analysis. Do NOT serialize open+wait calls — that blocks parallel loading. force_new=True is destructive: deletes existing .i64/.idb and all prior analysis. Use only for stale/incompatible DBs. Fat Mach-O: requires explicit fat_arch (e.g. |
| search_toolsA | Search hidden tools by regex (pinned tools excluded; use Returns one-line signatures by default. Use Hidden tools must be called via call, batch, or execute — direct calls will fail because they are not in the client tool list. |
| get_schemaA | Get parameter schemas for specific tools by name (pinned and hidden). Use after search_tools or before execute/batch to check parameter
types and return shapes. Pass Hidden tools must be called via call, batch, or execute — direct calls will fail because they are not in the client tool list. |
| executeA | Run Python code that chains tool calls. Use
When NOT to use execute
When to use executeMulti-step pipelines — chaining one tool's output into another: Cross-database parallel queries — use asyncio.gather with explicit Reference
|
| batchA | Run 2+ independent tool calls in a single request with per-item error collection. Preferred over Use
|
| callA | Call any tool by name, including hidden tools not in the client tool list. Use for single hidden-tool calls. For multiple calls, prefer batch. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| survey_binary | One-call binary triage. Produces an executive summary of the binary: what it is, what it does, key areas of interest, and recommended next steps. |
| analyze_function | Full single-function analysis. Decompiles, maps data flow, identifies strings and constants, and summarizes behavior. |
| diff_before_after | Preview the effect of renaming or retyping on decompiler output. Decompiles before and after, then shows what changed. |
| classify_functions | Classify functions by behavioral patterns to prioritize analysis effort. |
| find_crypto_constants | Scan for known cryptographic constants to identify crypto algorithms in use. |
| auto_rename_strings | Suggest function renames based on unique string references. Does not apply changes — presents suggestions for review. |
| apply_abi | Apply known ABI type information to identified functions (e.g. syscalls, Windows API wrappers, libc stubs). |
| export_idc_script | Generate an IDAPython script that reproduces all user annotations (renames, types, comments) for portability to another IDB. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| databases_resource | All open databases with worker status (supervisor-level) |
TDQS
Scored across 11 tools
Most tools have clearly distinct roles: database lifecycle, target listing, and tool discovery are well-separated. The main ambiguity is between call, batch, and execute, which all invoke tools, but the descriptions provide enough use-case distinction to guide selection.
The naming mostly follows a clear verb_noun snake_case pattern (open_database, save_database, list_databases, search_tools). The meta-tools deviate with bare verbs (execute, batch, call), and there is minor singular/plural inconsistency, but the pattern is still predictable overall.
11 tools is well within the ideal range for a purpose-built server. Each tool serves a necessary role: database lifecycle management, target discovery, hidden tool access, and execution orchestration. No tool feels redundant or superfluous.
The visible surface covers the full database lifecycle (open, wait, save, close, list) and provides meta-tools to discover and invoke hidden analysis tools. The only minor gap is that direct analysis operations are not visible in the pinned tool list, but this is clearly intentional and workable through search_tools/call/batch/execute.