Skip to main content
Glama

find_all_callers_recursive

Trace every direct and indirect caller of a C/C++ function across the full call graph, including function pointers, constructors, and dispatch edges, to assess the impact of a change before refactoring.

Instructions

Find all transitive C/C++ callers — who calls name, directly or indirectly, through the libclang call graph including function-pointer edges, implicit constructors, and synthetic dispatch edges. libclang-powered: follows function-pointer assignments and ISR vector registrations across the full call tree.

Use for impact analysis: "if I change this function, how far does the ripple go?" Returns callers at depth 1 (direct), depth 2 (callers of callers), up to max_depth (default 5). Results are deduplicated — each caller appears once at its shortest distance to the target.

Edge types traversed: Includes call, indirect (function pointers / ISRs), implicit_construct (constructors reachable through file-scope global objects), and dispatch (synthetic edges through event loops and thread starts).

Limitation — ambiguous name resolution: When a source-line fallback cannot disambiguate which method is called (e.g. attach() matching both Timeout::attach and SerialBase::attach), the edge is conservatively omitted to avoid false callers. If you suspect a missing caller, verify with search_bodies("target_name") and find_indirect_targets.

For a flat, single-level caller list use find_callers (faster). For the reverse direction use find_callees_recursive.

Read-only. No side effects. Requires the reference index (fw-context index — refs on by default). BFS from the target outward; performance scales with call-graph fan-out.

Args: name: Symbol name to find transitive callers of. project_root: Project root. Auto-detected if omitted. project: Project name or project_id — call list_projects to get them. Use it to ask about a project that is not the project of the current directory. It is an alternative to project_root, which takes a root path. Give one of the two, not both. max_depth: Maximum BFS depth for transitive search (default 5). limit: Maximum results (default 50). variant: Build variant (multi-build project). Omit to use default_variant. One query answers for ONE build. image: Sysbuild image within the variant. Required when the variant holds several: each image is a separate program.

Returns: list of dicts, each with: name (str — the caller), qualified_name (str), kind (str), signature (str), depth (int — distance from the target), file (str — absolute).

This tool gives no line, because one caller can hold several call
sites.  For the line of each call use ``find_callers`` on the name
that this tool reports.

When *name* matches more than one symbol, such as two classes with
a method of the same name, the answer holds the callers of all of
them.  A ``warning`` dict then comes first and names the symbols,
and each result carries ``target_qualified_name``, which tells the
symbol that it calls.  Give the full qualified name to ask about
one symbol only.

Never empty: one dict with ``error`` (cannot resolve) or ``info``
(no results) replaces the results.  Check both keys first.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesSymbol name to find transitive callers of.
imageNoSysbuild image within the variant. Required when the variant holds several: each image is a separate program.
limitNoMaximum results (default 50).
projectNoProject name or project_id — call list_projects to get them. Use it to ask about a project that is not the project of the current directory. It is an alternative to project_root, which takes a root path. Give one of the two, not both.
variantNoBuild variant (multi-build project). Omit to use default_variant. One query answers for ONE build.
max_depthNoMaximum BFS depth for transitive search (default 5).
project_rootNoProject root. Auto-detected if omitted. This field also accepts a project name or a project_id, but project is the clear field for those.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.32.0
    • changedInput schema / properties / image / description
      Previous value: -"Sysbuild image name within the variant (multi-project). Omit for all images of the variant."New value: +"Sysbuild image within the variant. Required when the variant holds several: each image is a separate program."
    • addedInput schema / properties / limit / minimum
      Added value: +1
    • addedInput schema / properties / max_depth / minimum
      Added value: +1
    • addedInput schema / properties / name / minLength
      Added value: +1
    • changedInput schema / properties / variant / description
      Previous value: -"Build variant name (multi-project). Omit to use default_variant or fail-closed. Use '*' for all variants."New value: +"Build variant (multi-build project). Omit to use default_variant. One query answers for ONE build."
  2. Changed3 schema fields changedv0.30.0
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / project
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Project name or project_id — call list_projects to get them. Use it to ask about a project that is not the project of the current directory. It is an alternative to project_root, which takes a root path. Give one of the two, not both.",
      +  "title": "Project"
      +}
    • changedInput schema / properties / project_root / description
      Previous value: -"Project root. Auto-detected if omitted."New value: +"Project root. Auto-detected if omitted. This field also accepts a project name or a project_id, but project is the clear field for those."
  3. Changed2 schema fields changedv0.25.3
    • addedInput schema / properties / image
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Sysbuild image name within the variant (multi-project). Omit for all images of the variant.",
      +  "title": "Image"
      +}
    • addedInput schema / properties / variant
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Build variant name (multi-project). Omit to use default_variant or fail-closed. Use '*' for all variants.",
      +  "title": "Variant"
      +}
  4. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and delivers richly: it discloses read-only/no side effects, BFS traversal, deduplication at shortest distance, the ambiguous-name resolution limitation, the error/info fallback dict, the absence of line numbers and why, and multi-match warning behavior. This goes far beyond a typical tool definition.

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?

Although lengthy, the description is appropriately sized for a complex tool with 7 parameters and multiple edge cases. It is front-loaded with the core purpose and edge types, then flows logically into usage, limitations, parameters, and return format. Each section earns its place with no filler; bold headers and paragraphs improve scannability.

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

Completeness5/5

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

Despite an output schema, the description adds vital context an agent needs: the warning/error/info dict shapes, the no-line-number behavior, deduplication, multi-symbol ambiguity resolution, and build/variant relationships. For a tool with this complexity, nothing essential is left unexplained.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantic context beyond the schema: 'Give one of the two, not both' for project/project_root, 'One query answers for ONE build', and 'Required when the variant holds several' for image. It also clarifies auto-detection and qualification nuances. These additions push it above baseline but not to 5 since much of the Args section repeats schema descriptions.

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

Purpose5/5

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

The description opens with a specific verb and resource: 'Find all transitive C/C++ callers — who calls *name*, directly or indirectly', and details the traversal through libclang call graphs with specific edge types. It clearly differentiates itself from sibling tools by naming find_callers and find_callees_recursive and stating their different scopes.

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

Usage Guidelines5/5

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

Explicitly states when to use the tool: 'Use for impact analysis: if I change this function, how far does the ripple go?' Then gives direct alternatives with conditions: 'For a flat, single-level caller list use find_callers (faster). For the reverse direction use find_callees_recursive.' Also recommends verification tools (search_bodies, find_indirect_targets) for a known limitation. This is model guidance.

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