Skip to main content
Glama

find_wrapper_callers

Detect C/C++ adapter patterns by finding wrapper classes that call a driver class's methods, tracing method ownership across class boundaries.

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'. The name is case-sensitive. A bare name that names no top-level class matches the class of that name in each namespace, but not a class whose name only ends with it. The methods of a class nested in the driver class count as driver methods. 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 classes on one page (default 20, max 100). Each class comes with all of its methods and calls into the driver (call and indirect references), thus a class is never split over two pages. offset: Skip this many wrapper classes. Reads the next page; the page notice names the offset to use. variant: Variant of the build (a board, or a PlatformIO environment). On a project of more than one build, give the arguments of one build as the refusal lists them: the variant, the image, or the two. fw-context does not select a build. One query answers for ONE build. image: Image of the build: a separate program, such as the application or the bootloader. Give it when the build has an image name.

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.

The page notice ``{total, offset, shown, more, hint}`` comes
before the rows of the answer: ``total`` counts every wrapper class.  A page after the last
class gives one ``info`` dict that names the total.

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

Input Schema

NameRequiredDescriptionDefault
imageNoImage of the build: a separate program, such as the application or the bootloader. On a project of more than one build, give it when that build has an image name, as the refusal lists it.
limitNoMaximum wrapper classes on one page (default 20, max 100).
offsetNoSkip this many wrapper classes. Reads the next page.
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.
variantNoVariant of the build (a board, or a PlatformIO environment). On a project of more than one build, give the arguments of one build as the refusal lists them: the variant, the image, or the two. fw-context does not select a build for you. One query answers for ONE build.
class_nameYesDriver class name to find wrappers for. E.g. 'UART_DRIVER' or 'hal::UART_DRIVER'. Case-sensitive.
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

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.32.1
    • changedInput schema / properties / class_name / description
      Previous value: -"Driver class name to find wrappers for. E.g. 'UART_DRIVER' or 'hal::UART_DRIVER'."New value: +"Driver class name to find wrappers for. E.g. 'UART_DRIVER' or 'hal::UART_DRIVER'. Case-sensitive."
    • changedInput schema / properties / image / description
      Previous value: -"Sysbuild image within the variant. Required when the variant holds several: each image is a separate program."New value: +"Image of the build: a separate program, such as the application or the bootloader. On a project of more than one build, give it when that build has an image name, as the refusal lists it."
    • changedInput schema / properties / limit / default
      Previous value: -50New value: +20
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum wrapper method results (default 50, max 50)."New value: +"Maximum wrapper classes on one page (default 20, max 100)."
    • addedInput schema / properties / offset
      Added value: +{
      +  "default": 0,
      +  "description": "Skip this many wrapper classes. Reads the next page.",
      +  "minimum": 0,
      +  "title": "Offset",
      +  "type": "integer"
      +}
    • changedInput schema / properties / variant / description
      Previous value: -"Build variant (multi-build project). Omit to use default_variant. One query answers for ONE build."New value: +"Variant of the build (a board, or a PlatformIO environment). On a project of more than one build, give the arguments of one build as the refusal lists them: the variant, the image, or the two. fw-context does not select a build for you. One query answers for ONE build."
  2. Changed5 schema fields changedv0.32.0
    • 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."
  3. 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."
  4. 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"
      +}
  5. Addedv0.2.4

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so: it states 'Read-only. No side effects.' and the index prerequisite, plus non-obvious behaviors like the never-empty contract ('one dict with error or info replaces the results. Check both keys first') and the pagination/offset notice semantics. This is disclosure well beyond what any structured field supplies.

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

Conciseness3/5

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

Front-loaded correctly (verb+resource first), but it repeats itself: the 'UART wraps UART_DRIVER' example appears twice, and the entire Args and Returns sections largely restate the input schema and the (present) output schema. Several sentences do not earn their place.

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?

For a 7-parameter, multi-build, index-dependent query tool, the description covers preconditions, pagination, error/info fallbacks, and build scoping. Since an output schema exists, the Returns prose is redundant but harmless; nothing an agent needs to call it correctly is missing.

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?

Schema coverage is 100%, so baseline is 3, but the description adds substantial meaning the schema lacks: class_name case-sensitivity and bare-name namespace matching rules, that nested-class methods count as driver methods, that limit keeps a class intact on one page, and how variant/image interact with multi-build projects. This meaningfully exceeds 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 first sentence names a specific verb and resource ('Find C/C++ wrapper classes that call methods of a driver class') with the implementation backing ('libclang-powered adapter pattern detection'). It also explicitly distinguishes itself from siblings by naming the tools that cover the reverse and adjacent perspectives (find_callers, get_class_members).

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?

Explicit routing: '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 precondition ('Requires the reference index') and the build-selection constraint (one query answers for ONE build), leaving little to inference.

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