Query IDA Pro database entities such as functions, globals, imports, and strings using filters, projection, and pagination for reverse engineering analysis.
Query IDB entities with typed filters, projection, and pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| queries | Yes | Generic entity query with filtering, projection, and pagination | |
| instance_id | Yes | 必须提供的 instance_id（或 client_id），用于将请求精确路由到特定的 IDA 实例。请先调用 instance_list 查看并选择合适的客户端 ID。 |
Changes observed during successful MCP inspections.
v2.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'Query' implies a read, but it never states read-only semantics, whether results are paginated by default, what the response shape is, or any limits. For a tool with no annotation coverage this is a meaningful omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler or repetition. It earns its brevity, though the extreme terseness leaves important behavior unstated rather than being a model of efficient completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool accepting batch/nested query objects across five entity kinds, with no output schema and no annotations, one sentence is not enough. Return values, pagination behavior, and how the typed queries compose are all left to the schema and inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every query field (kind, regex, filter, sort_by, min/max_addr, etc.) and the instance_id. The description's mention of filters/projection/pagination merely echoes the schema categories without adding syntax or semantics, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a verb (Query) and a resource (IDB entities) plus the categories of capability (filters, projection, pagination), so the basic purpose is legible. However, 'typed filters' is vague jargon and it does nothing to separate this generic tool from the many sibling query tools (func_query, imports_query, xref_query, type_query, list_globals). An agent cannot tell from the description alone which query tool to reach for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use, when-not-to-use, or alternative-tool guidance at all. With a dense family of sibling query tools, the absence of routing guidance is a real gap; the agent must fall back on guesswork or the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.