Hex-Rays IDA MCP

Overview Schema Source Related Servers Discussions Admin

Bounded call graph from roots

callgraph

Read-only

Build a bounded function-call graph from root addresses with depth, node, and edge limits to control reverse-engineering traversal.

Instructions

Build bounded callgraph from roots with depth/node/edge limits.

Input Schema

TableJSON Schema

Name	Required	Description
`roots`	Yes	Root function addresses to start call graph traversal from
`max_depth`	No	Maximum depth for call graph traversal
`max_edges`	No	Max edges across the graph (default: 5000, max: 200000)
`max_nodes`	No	Max nodes across the graph (default: 1000, max: 100000)
`instance_id`	No	Optional database instance id. If omitted, use the current target.
`max_edges_per_func`	No	Max edges per function (default: 200, max: 5000)

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv20261008.0.1Oct 21, 2026

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so safety is covered. The description adds that the graph is bounded by depth/node/edge limits, which is useful behavioral context beyond annotations. However, it doesn't disclose behavior when limits are exceeded or other operational details. Score 3.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence with zero waste. It packs the action, source, and constraints into 11 words. Score 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values needn't be explained. The description covers the core operation and its bounding behavior. It omits edge-case behavior when limits are hit, but given rich structured data, it's adequately complete. Score 4.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all parameters are already documented. The description only mentions 'depth/node/edge limits', which maps directly to existing schema fields without adding syntax or usage details. Baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description specifies a clear verb+resource ('Build bounded callgraph from roots') and indicates the traversal is scoped by depth/node/edge limits. It distinguishes from a simple callees tool by emphasizing multi-level traversal with bounds, though it doesn't explicitly name a sibling. Score 4.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance or alternatives. It simply states what it does, leaving the agent to infer when a bounded callgraph is preferable to alternatives like callees or xrefs_to. Score 2.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server