Loading ToolBench
Standalone MCP Server Plugin for IDA Pro providing comprehensive reverse engineering capabilities with 42+ tools for binary analysis, decompilation, patching, and symbol management
IDAssistMCP provides 42 well-named tools with comprehensive IDA Pro integration. Tool naming follows verb_noun patterns (get_code, analyze_function, patch_bytes) and clearly indicates read-only vs. write operations. Input schemas are present and mostly complete with type definitions and descriptions. However, descriptions vary significantly in quality, some are concise and actionable (e.g., 'Get function code in specified format (unified tool)'), while others are minimal (e.g., 'List variables or rename local/global variables (action parameter)'). Output schemas are not formally documented in the source, forcing agents to infer response structure. Error handling is minimal, no recovery guidance or actionable error messages are visible. Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are correctly applied via the toolAnnotations feature. The server makes good use of consolidation (6 tools use action parameters to bundle related operations), but this pattern requires careful LLM guidance to avoid misuse. Overall, the server is solidly functional for IDA automation but lacks the polish and defensive design of production-grade agent tools.
Comprehensive function analysis with CFG, callers, decompilation
Assemble instruction text and optionally patch bytes
Batch rename multiple symbols
List, set, or remove position bookmarks (action parameter)
Cancel a running async task
Get, set, list, or remove comments (action parameter)
Define a data variable at address
Output schemas not documented in tool definitions. LLMs cannot infer response structure, forcing them to guess at field names and types for chaining downstream calls. Tools that return complex objects (analyze_function, xrefs, get_classes) provide no schema documentation.
Consolidated action-parameter tools (comments, variables, types, xrefs, bookmarks) lack clear separation of semantics. A single tool with action=['set', 'remove', 'list', 'get'] creates cognitive load for LLMs deciding which action to invoke. No guidance on which action is idempotent vs. destructive.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 70 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Undefine items, force code, or create a function (IDA U/C/P)
Export the patched binary or IDA database
Get basic blocks (CFG) for a function
Get detailed information about the currently loaded binary.
Get struct/class types from type library
Get function code in specified format (unified tool).
Get address at cursor position
Get function at cursor position
Get typed data at address
Get defined data variables (non-code items)
Get all binary entry points
Get exported symbols
Look up function at address
Look up function by exact name
Get the native byte signature for a function
Get stack frame layout for a function
Get statistics about all functions
List all functions with filtering and pagination
Get imported functions by module
Get memory segments with permissions
Get strings with pagination
Get status of async task
List the currently loaded binary (IDA is single-binary).
List all async tasks
Move IDA cursor to address
Patch bytes in the IDB
Read raw bytes from the IDB
Rename any symbol (function or data)
Search for byte pattern
Search functions by name pattern and size filters
Search strings by pattern
Start an async background task
List, set, create_struct, or create_enum (action parameter)
List variables or rename local/global variables (action parameter)
Get xrefs to/from address, optionally include callers/callees
Error handling is minimal. No recovery guidance, actionable error messages, or classification (retryable vs. fatal). Tools like patch_bytes and assemble_code (IRREVERSIBLE risk) provide no confirmation steps or dry-run support. Destructive operations should include confirmation or dry-run capability.
Descriptions for consolidated tools are minimal. 'List variables or rename local/global variables (action parameter)' lacks actionable guidance on when to use 'list' vs 'rename'. No dependencies documented (e.g., 'get_functions first to find function_name_or_address').
Parameter 'function_name_or_address' is polymorphic (accepts name OR hex address) but lacks clear format guidance. No enum or pattern constraint. Descriptions should state: 'Function identifier: either a function name (string, e.g. "main") or hex address (0x1000 format)'.
'define' tool name is vague. The action enum shows ['undefine', 'code', 'function'], these are IDA-specific terms ('U/C/P' instructions) not intuitive to LLMs. Consider renaming to 'undefine_item' or 'define_item' and documenting IDA semantics clearly.
No documented pagination guidance for list tools (get_functions, get_strings, get_data_vars). While limit/offset parameters exist, no statement of result cap or guidance on expected response size. Should state: 'Returns up to {limit} items. Use offset to paginate. Total count included in response.'
Task management tools (start_task, get_task_status, cancel_task, list_tasks) lack specification of task_type enum and parameters schema. 'task_type' accepts a string with no documented valid values. LLMs cannot discover available task types without trial-and-error.