fw-context-mcp

Overview Schema Source Related Servers Discussions Admin

find_wrapper_callers

Identify C/C++ wrapper classes that call driver methods, revealing adapter patterns like UART wrapping UART_DRIVER. Uses libclang to trace method ownership across classes.

Instructions

Find C/C++ wrapper classes that call methods of a driver class — libclang-powered adapter pattern detection. Traces method ownership across class boundaries to reveal the wrapper/adapter architecture (e.g. UART wraps UART_DRIVER). Text-based search cannot distinguish which class owns each method call.

Returns wrapper methods grouped by wrapper class, showing which driver methods each wrapper calls. Useful for understanding the adapter/wrapper architecture (e.g. UART wraps UART_DRIVER).

For the reverse perspective — finding who calls a specific driver method — use find_callers. For class member listing use get_class_members.

Read-only. No side effects. Requires the reference index (fw-context index — refs on by default).

Args: class_name: Driver class name to find wrappers for. E.g. 'UART_DRIVER' or 'hal::UART_DRIVER'. 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. limit: Maximum wrapper method results (default 50, max 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: wrapper_class (str — "(global)" for a free function), method_count (int), methods (list of dicts — each with method, qualified_name, kind, file (str — absolute path of the file that holds the body of that method), and calls (list of dicts — driver_method (str) and line (int) of each call into the driver))).

The path sits on the method, not on the class, because one wrapper
class often spans several files.

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
`image`	No	Sysbuild image within the variant. Required when the variant holds several: each image is a separate program.
`limit`	No	Maximum wrapper method results (default 50, max 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.
`class_name`	Yes	Driver class name to find wrappers for. E.g. 'UART_DRIVER' or 'hal::UART_DRIVER'.
`project_root`	No	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.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.32.0Sep 17, 2026

addedInput schema / properties / class_name / minLength
```
Added value: +1
```

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

changedInput schema / properties / limit / description

Previous value: -"Maximum wrapper method results (default 50)."New value: +"Maximum wrapper method results (default 50, max 50)."

addedInput schema / properties / limit / minimum
```
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. 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."

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.2.4Jun 18, 2026

TDQS

A4.6/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses read-only behavior ('Read-only. No side effects.'), the requirement for the reference index, the non-empty result contract (error/info dicts replace results), and the rationale for path placement on methods rather than classes. It doesn't mention rate limits or failure modes beyond the error key, but the disclosed behaviors are substantial and useful.

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

Conciseness4/5

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

The description is well-structured with clear sections: purpose, example, return format, and usage notes. It is longer than minimal but every section earns its place — the return format detail is essential for a tool with a complex nested output. The front-loading of purpose and the sibling routing early in the text is effective. Slight redundancy exists ('adapter pattern detection' and 'adapter/wrapper architecture' are repeated), but it's not wasteful.

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?

The tool has 6 parameters, a complex nested output schema, and no annotations. The description covers the tool's purpose, prerequisites, parameter selection guidance, return structure, and edge-case behavior (error/info dicts). The output schema exists, so the description doesn't need to explain every field, but it adds the critical 'path sits on the method, not on the class' insight and the 'never empty' contract. Nothing an agent needs to call this correctly is missing.

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 description coverage is 100%, so the baseline is 3. The description adds value by explaining the relationship between project and project_root ('alternative to project_root... Give one of the two, not both'), clarifying that variant answers for ONE build, and giving concrete examples for class_name. The limit's max is already in the schema, but the description reinforces it. This exceeds the baseline.

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 states a specific verb and resource: 'Find C/C++ wrapper classes that call methods of a driver class' and immediately distinguishes it from text-based search and sibling tools. It names the exact pattern (adapter detection) and gives a concrete example (UART wraps UART_DRIVER), making the tool's purpose unmistakable.

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?

The description explicitly says when to use this tool vs alternatives: 'For the reverse perspective — finding who calls a specific driver method — use find_callers. For class member listing use get_class_members.' It also states the prerequisite (requires the reference index) and explains why text-based search is insufficient. This is exemplary routing guidance.

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