Skip to main content
Glama

explain_symbol

Get a plain-English explanation of any C/C++ symbol: its purpose, inputs, outputs, and side effects. Uses pre-computed analysis when available, with on-demand LLM fallback.

Instructions

Explain what a C/C++ symbol does in plain English — libclang-aware analysis. Uses pre-computed LLM analysis when available (instant), falls back to on-demand LLM. Falls back to macro explanation when the name matches a #define.

Read-only. No side effects — uses pre-computed LLM analysis when available (instant, generated during fw-context index --analyze), falls back to calling an LLM on-demand. Returns the symbol's purpose, inputs, outputs, and side effects.

For raw source code use get_source. For symbol metadata without explanation use lookup_symbol. For body + callers + callees use get_symbol_context.

Args: name: Symbol name to explain. E.g. uart_init, ModemMsg::send. 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. context_lines: Lines of source context around the symbol definition (default 40, max 200). Only used when no pre-computed analysis exists. 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: dict: {name, kind, file, line, signature, explanation, llm_analysis (if pre-computed)}, plus source/explain_prompt on fallback. Macro fallback returns kind="macro", signature (as #define NAME or #define NAME(a, b)), is_function_like, value (the replacement text ALONE), and expanded_value.

A ``warning`` key means that the local LLM gave no explanation —
the request timed out, or the model is not available.  The dict then
holds ``source`` and ``explain_prompt``: read the source, and answer
the prompt yourself.

When the file changed after the last index run, the dict adds
``stale`` (True) and ``stale_warning`` (str).  ``stale_warning`` is
separate from ``warning``, which the LLM error paths use.  A symbol
that moved gives its indexed body, not the code that now sits at the
stored line number.

An ``ambiguous_warning`` key means that *name* matched more than one
symbol, such as two classes with a method of the same name.  This
answer is about ONE of them, and the key names it and lists the
others.  Give the full qualified name to ask about one symbol only.
It is separate from ``warning``, which the LLM error paths use.

On failure the dict holds ``error`` with the reason.  One failure
carries more than that: when the best match for *name* is in a file
outside the project root, the dict also holds ``candidates``,
``candidates_total`` and a ``hint``.  Read them — a common name
matches many symbols, and one of the others is often inside the
project.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesSymbol name to explain. E.g. 'uart_init', 'ModemMsg::send'.
imageNoSysbuild image within the variant. Required when the variant holds several: each image is a separate program.
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. Auto-detected if omitted. This field also accepts a project name or a project_id, but project is the clear field for those.
context_linesNoLines of source context around the symbol definition.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.32.0
    • addedInput schema / properties / context_lines / minimum
      Added value: +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 / 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 does so thoroughly. It states 'Read-only. No side effects,' explains the pre-computed versus on-demand LLM fallback, and details warning, stale, ambiguous, failure, and outside-root candidate behaviors.

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 a clear opening, routing section, Args list, and Returns breakdown. However, it repeats the pre-computed/on-demand fallback sentence twice and restates 'It is separate from warning, which the LLM error paths use' for both stale and ambiguous warnings, so a small amount of tightening was possible.

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?

There is no output schema, so the description must explain return values, and it does so comprehensively: dict keys, macro fallback fields, warning semantics, stale-file markers, ambiguous matches, and failure candidates. For a tool with this behavioral complexity, nothing essential 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?

Though schema coverage is 100%, the description adds significant meaning beyond the schema: examples like 'uart_init' and 'ModemMsg::send', auto-detection of project_root, the mutual exclusivity of project and project_root, the conditional use of context_lines, and the per-build semantics of variant.

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: 'Explain what a C/C++ symbol does in plain English — libclang-aware analysis.' It distinguishes itself from sibling tools such as lookup_symbol and get_symbol_context by stating that it returns an explanation, not just metadata or raw context.

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 is provided: 'For raw source code use get_source. For symbol metadata without explanation use lookup_symbol. For body + callers + callees use get_symbol_context.' It also gives concrete parameter guidance, such as when to use project versus project_root and when image is required.

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