Loading ToolBench
MCP server for binary analysis using IDA Pro. Provides tools for opening binaries, analyzing functions, reading memory, querying cross-references, and managing IDA analysis sessions.
IDA Pilot has 28 tools with basic descriptions and parameter schemas, but significant gaps limit production readiness. Most tools have 1 - 3 parameters with type definitions and brief descriptions (avg ~80 chars), meeting minimum baseline. However, output schemas are entirely undocumented, no tool declares what fields it returns, forcing LLMs to guess. Error handling is absent: no recovery guidance, no categorization of retryable vs fatal errors. Parameter descriptions lack constraints (ranges, enums, formats). Security-critical tool py_eval is gated by a flag but lacks explicit permission documentation. Tool naming is generally clear (verb_noun pattern), but composition issues exist: get_session_progress, watch_auto_analysis, and run_auto_analysis overlap in responsibility. No pagination support visible despite tools like search and cross_search that could return large result sets. Descriptions are functional but generic, they state WHAT but rarely WHEN or WHY to call each tool.
One-call function analysis: pseudocode + metadata + xrefs + comments.
Batch-analyze up to 10 functions in parallel: pseudocode + metadata + xrefs for each. Use for call-graph traversal.
Annotate a function
Close analysis session
Get cross-references for an address
Search cross-references
Get analysis context around an address
No output schemas documented for any tool. LLMs cannot predict response structure, forcing them to guess field names and types. This breaks tool chaining and increases hallucination risk.
Generic, minimal descriptions on 18+ tools (query, inspect, prune_context, list_sessions, close_binary, save_database, etc.). Descriptions under 50 chars lack context for LLM tool selection. No guidance on WHEN to call each tool or what it returns.
No error handling or recovery guidance. Tools do not document what errors are retryable, what user actions are needed, or what to do if a session times out or a binary fails to load. LLMs cannot self-correct.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
Retrieve truncated response. Use _cache_id from any truncated output.
Get disassembly at address
Get references to an address
Get current session progress
Import metadata from external source
Inspect binary structure
List active sessions
Create a function at address
Open binary for analysis. Returns immediately; loading and auto-analysis run in the background — poll get_session_progress until ready=true before analyzing (large binaries take minutes). Set skip_analysis=true for import workflows.
Prune analysis context
Execute arbitrary Python in the IDA worker (RCE primitive — disabled by default, enable with --enable-py-eval)
Query binary metadata
Read memory at address
Run auto-analysis on the binary
Save IDA database
Search binary for patterns or strings
Set analysis note at address
Set metadata on binary elements
Set type information
One-call binary overview: segments, functions, imports, exports, strings (counts + top entries), entry point, decompiler status. Use as first call after open.
Watch auto-analysis progress
Parameter descriptions lack constraints. No enums for categorical inputs (e.g., query type), no ranges for numeric inputs (address, size), no format specs for strings. LLMs will pass invalid values without guidance.
Overlapping tool responsibilities: get_session_progress, watch_auto_analysis, and run_auto_analysis all relate to analysis state. No clear guidance on which to call when. Composition is unclear.