fw-context-mcp

Overview Schema Source Related Servers Discussions Admin

find_indirect_call_sites

Find C/C++ function pointer call sites that text search misses. Resolves invocations through fields or variables like driver.onData(buf,len) to answer where a callback is actually called.

Instructions

Find indirect call sites where a C/C++ function pointer field or variable is invoked. libclang-powered: resolves calls through function pointers (e.g. driver.onData(buf, len)), which text-based search cannot detect.

Returns locations where a function pointer is called through a field access (driver.onData(buf, len)) or variable dereference (stored_callback(42)).

Read-only. No side effects. Use this to answer "where is this function pointer invoked?" as opposed to find_callers which answers "who calls this function?" and find_references which answers "where is this symbol read or assigned?"

For the reverse query — which functions are assigned to a given field or parameter — use find_indirect_targets.

Requires the reference index (fw-context index — refs on by default).

Args: name: Name of the function pointer field or variable. E.g. "onData" finds every call through a field named onData. Uses three-tier resolution: exact name, exact qualified, suffix LIKE. project_root: Project root directory. 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. limit: Maximum results (default 50, max 200). 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: file, line, expr_text (the callee expression, e.g. "driver.onData"), target_usr, target_name, fn_ptr_type (the function pointer type signature), caller (enclosing function name), caller_kind.

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

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Name of the function pointer field or variable to find call sites of. E.g. 'onData' finds all calls through Driver::onData.
`image`	No	Sysbuild image within the variant. Required when the variant holds several: each image is a separate program.
`limit`	No	Maximum results (default 50).
`project`	No	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.
`variant`	No	Build variant (multi-build project). Omit to use default_variant. One query answers for ONE build.
`project_root`	No	Project root directory. 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

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.32.0Sep 17, 2026

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 / 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."

Changed3 schema fields changedv0.30.0Sep 5, 2026

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 directory. Auto-detected if omitted."New value: +"Project root directory. Auto-detected if omitted. This field also accepts a project name or a project_id, but project is the clear field for those."

Changed2 schema fields changedv0.25.3Aug 16, 2026

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"
+}

Addedv0.8.4Jun 27, 2026

TDQS

A5/5.0

Behavior5/5

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

No annotations are present, so the description carries the full burden. It discloses that the tool is read-only with no side effects, explains the libclang-backed mechanism and its limitation versus text search, and reveals the non-obvious return contract: results are never empty and may contain an `error` or `info` key that must be checked.

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?

The description is long but every sentence earns its place: purpose, examples, sibling differentiation, prerequisites, parameter semantics, and return format are each addressed without fluff or repetition. The most critical scoping information is front-loaded before the parameter details.

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?

Given the tool's complexity (6 parameters, output schema, cross-tool distinctions), the description is remarkably complete. It covers prerequisites, parameter alternatives, error behavior, return dict fields, and expected usage, leaving no obvious gap an agent would need to guess about.

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

Parameters5/5

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

Although the schema already documents all parameters (100% coverage), the description adds substantial meaning: the three-tier resolution strategy for `name`, the mutual-exclusivity rule for `project` vs `project_root`, the note that one query answers for ONE build for `variant`, the per-image program semantics for `image`, and the maximum limit of 200. These details go well beyond the schema text.

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 precise verb+resource: 'Find indirect call sites where a C/C++ function pointer field or variable is invoked.' It further clarifies with concrete examples like `driver.onData(buf, len)` and explicitly differentiates this tool from `find_callers` and `find_references`, so an agent can immediately tell them apart.

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?

It states exactly when to use the tool ('where is this function pointer invoked?') and when not to, naming the alternatives: `find_callers` for 'who calls this function?' and `find_references` for 'where is this symbol read or assigned?'. It also directs the reverse query to `find_indirect_targets` and notes the prerequisite of the reference index.

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