Skip to main content
Glama

lookup_symbol

Find C/C++ symbols by exact or prefix name via libclang. Discovers build-conditional, template-instantiated, and macro-expanded names that text search misses.

Instructions

Look up a C/C++ symbol by name via libclang index — exact or prefix matching. Finds symbols text-based search can miss: build-conditional code, template instantiations, macro-expanded names. Macros are extracted via clang -dM -E during indexing so #ifdef-conditional macros resolve correctly for the active build config. Prefer this over search_code when you know the exact symbol name or a prefix (uart_ finds all UART symbols). Use search_code for keyword/concept search.

Read-only: yes. May auto-reindex stale files (non-blocking).

Args: name: Symbol name (exact match) or prefix (set exact=False). E.g. 'uart_init' finds the exact function; 'uart_' finds all symbols starting with 'uart_'. project_root: Project 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. exact: True = exact name match, False = prefix LIKE match (default). limit: Maximum results of one page (default 50, max 100). offset: Skip this many results (default 0). A common method name lives in many classes — read and write match dozens of symbols — and this walks past the ones already seen. The page notice names the offset to use. The order is stable (a definition first, then the line, then the file and the USR), thus two pages never overlap and never skip a symbol. 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[dict]: The page notice leads the answer — total, offset, shown, more — where total counts every symbol the name matches. Read it before you conclude that a page holds them all. Each symbol that follows has name, qualified_name, kind, file, line, signature, docstring, is_definition, is_template, is_virtual, is_pure_virtual fields, and class — the class, struct or union that declares the symbol, absent for a free function. class is what tells two same-name methods apart at a glance. Enum constants include enum_value with the integer value. Macro results include kind="macro", signature (how the macro is invoked: #define NAME, #define NAME() or #define NAME(a, b)), is_function_like, value (the replacement text ALONE — the parameter list is not part of it), and expanded_value (preprocessor-resolved value). May also include template_usr, parent_usr, and llm_analysis ({summary, inputs, outputs}) when available. A model wrote the text in llm_analysis, and the code did not — use it to find a symbol, and quote signature, docstring, or get_source instead. When no results found, may include _did_you_mean with suggested symbol names. When no symbol matches, the list is empty — there is then no page notice, because there is no page. An info entry comes back for one case only: an offset past the end of an answer that does hold rows.

**Note:** C++ constructors share their name with the enclosing
class, so ``lookup_symbol("Foo")`` may return both ``class Foo``
and ``constructor Foo::Foo()``.  Use the ``kind`` field to
filter when you need a specific symbol type.

A symbol that comes from the relaxed prefix fallback carries
``_fallback: True`` — the name is not an exact match of *name*.

A list with one dict that holds an ``error`` key means that the
project has no index, or that the lookup failed.  Read that key
before you read the result fields.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesSymbol name. Exact match if exact=True, prefix LIKE match otherwise. E.g. 'uart_init' or 'uart_'.
exactNoTrue = exact name match, False = prefix LIKE match (default).
imageNoSysbuild image within the variant. Required when the variant holds several: each image is a separate program.
limitNoMaximum results returned (capped at 100, default 50).
offsetNoSkip this many results. Pages through a name that many classes share, such as 'read' or 'write'.
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.
project_rootNoProject root directory. Auto-detected from CWD 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 / name / minLength
      Added value: +1
    • addedInput schema / properties / offset
      Added value: +{
      +  "default": 0,
      +  "description": "Skip this many results. Pages through a name that many classes share, such as 'read' or 'write'.",
      +  "minimum": 0,
      +  "title": "Offset",
      +  "type": "integer"
      +}
    • 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 directory. Auto-detected from CWD if omitted."New value: +"Project root directory. Auto-detected from CWD 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. Changed1 schema field changedv0.7.0
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum results returned (default 50)."New value: +"Maximum results returned (capped at 100, default 50)."
  5. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/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 — and it does so comprehensively. It discloses the read-only nature ('Read-only: yes'), side effects ('May auto-reindex stale files (non-blocking)'), the error-key edge case, the empty-list case with no page notice, the _fallback flag, the C++ constructor name-collision quirk, and even flags that llm_analysis text was model-written ('A model wrote the text... the code did not').

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?

The structure is sound and front-loaded — purpose, then usage, then params, then returns — but the Returns section is verbose, repeating details an output schema would already carry (the full field list). Much of the length is justified by behavioral context (page-notice reading instruction, error key, llm_analysis caveat), but a trim of redundant field enumeration would tighten it without loss.

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 complex tool — 8 parameters, 1 required, multi-case return format, error handling, pagination — the description is remarkably complete. It covers the page-notice semantics, empty-result behavior, error-key case, did_you_mean suggestions, fallback flag, and the C++ constructor quirk. With an output schema present, the return-format detail exceeds necessity but adds behavioral value an output schema cannot capture.

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 baseline is 3, but the description adds genuine meaning beyond the schema: the offset parameter's pagination rationale with stable ordering guarantee ('two pages never overlap and never skip a symbol'), the image parameter's requirement rationale ('each image is a separate program'), and the project vs project_root mutual-exclusion guidance. These exceed what the schema documents.

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?

States a specific verb, resource, and mechanism: 'Look up a C/C++ symbol by name via libclang index — exact or prefix matching.' It clearly differentiates from search_code by naming what makes it unique ('Finds symbols text-based search can miss: build-conditional code, template instantiations, macro-expanded names') and explicitly names the sibling it should be preferred over.

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 when-to-use guidance: 'Prefer this over search_code when you know the exact symbol name or a prefix... Use search_code for keyword/concept search.' Also gives concrete routing examples (uart_ finds all UART symbols) and instructs calling list_projects for the project parameter. Nothing is left to inference.

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