Loading ToolBench
Standalone MCP Server Plugin for IDA Pro enabling LLM-powered reverse engineering workflows via 42 tools, 8 resources, and 7 guided prompts
IDAssistMCP provides 42 tools with varying quality. Strengths: all tools have descriptions (10 - 100+ chars), complete input schemas with types, verb-noun naming (get_*, create_*, list_*, etc.), and tool annotations (readOnlyHint, idempotentHint, etc.). Weaknesses: descriptions are generally brief (avg ~50 chars, well below the 194-char baseline); several tools combine multiple responsibilities (e.g., 'comments' tool handles get/set/list/remove via action enum); output schemas are not documented in code; error recovery guidance is missing; parameter interdependencies (e.g., action enums determining required fields) are not explicitly documented; security-critical operations (patch_bytes, assemble_code, export_program) lack confirmation patterns or dry-run options despite being IRREVERSIBLE.
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
Multi-action tools (comments, variables, types, bookmarks, define) use action enums to combine 3 - 4 distinct responsibilities into a single tool. This violates the single-responsibility principle and forces LLMs to reason about parameter interdependencies. For example, 'comments' with action=['get','set','list','remove'] should be split into get_comments, set_comment, list_comments, remove_comment.
Descriptions are uniformly brief (avg ~50 chars, baseline 194 chars). Most descriptions lack context for when or why to select a tool instead of a similar one. For example, 'Get function code in specified format (unified tool)' does not explain when to use get_code vs analyze_function, or what output format is returned.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 68 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 32 | - | 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
Output schemas are not documented in the source code. The tools return data structures (dicts, lists) but the expected fields, types, and nesting are not specified for LLM consumption. For example, analyze_function returns a dict with CFG and callers, but the exact structure is not documented. Without documented output schemas, LLMs cannot plan downstream tool calls.
Irreversible operations (patch_bytes, assemble_code, export_program, define with action='undefine') lack confirmation or dry-run patterns. Agents can destructively modify the IDA database without a safety check or explicit user confirmation. These should support a dry_run parameter or a separate confirm_* tool.
Error handling lacks recovery guidance. When a tool fails, responses do not suggest the next step (e.g., 'User not found. Try search_users() with a partial name.') or explain whether the error is retryable, user-fixable, or fatal. Error responses are likely simple exceptions without structured guidance.
Parameter interdependencies are not explicitly documented. Tools with action enums (comments, variables, types, bookmarks, define) do not document that the action value determines which other parameters are required. For example, 'comments' with action='set' requires the 'comment' field, but action='get' does not.
Some tool names are vague or generic. 'navigate_to' is weak; 'jump_to_address' or 'seek_address' is clearer. 'define' is ambiguous, does it define code, data, or types? Rename to 'define_code', 'define_data', or 'undefine_item' depending on intended use.
Tools accepting address or name parameters (e.g., get_code, analyze_function) do not document accepted formats. Are addresses hex strings ('0x1000'), decimal ('4096'), or both? Are names case-sensitive? The resolver helper _resolve() handles this internally, but the tool descriptions do not document expected input.
Pagination support is inconsistent. get_functions, get_strings, and search_functions_by_name accept limit/offset, but many other list/search tools do not. get_imports lacks pagination even though it may return many results. Without pagination, large result sets waste tokens and risk context window overflow.
No documented rate limits or timeout handling. If IDA analysis is slow (e.g., decompiling a large function), tools may hang indefinitely. Async task support (start_task, get_task_status) exists but is not clearly integrated with long-running analyses.