Skip to main content
Glama

get_source

Get the exact body of a C/C++ function, enum, or macro using AST-precise extents. Returns ifdef-filtered source with line numbers, so you see only code that compiles for the current build.

Instructions

Read a C/C++ function/method/enum/macro body using libclang exact extents — no guessing line numbers. Uses AST-precise {start, end} extents so you get exactly the function body. Generic file readers don't know where a function actually ends — libclang tracks exact {start, end} from the AST.

The body is ifdef-filtered: a line of an inactive #if branch comes back blank, thus the text holds only the code that compiles for this build. The line numbers do not move. source_origin says where the text came from — "index" is the filtered copy, "disk" is the file itself and holds EVERY branch. A body reaches you from the disk only when the file changed after the last index run, and stale_warning says so.

For enums, includes a constants array listing all member constants with their values. For macros, returns kind="macro" with signature (#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).

For rich context (who calls this, what does it call) use get_symbol_context instead — it returns body, callers, and callees in a single call. For the full file, use a normal file read.

Read-only. No side effects.

Args: name: Fully qualified symbol name. Returns exact function body via libclang extent. 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. 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, qualified_name, kind, file, line, signature, docstring, is_definition, is_template, is_virtual, is_pure_virtual, source (str — the function/enum/macro body, truncated at 8000 chars), warning (str, optional — when source file cannot be read)}. May also include end_line (the last line of the extent), template_usr, parent_usr, enum_value, constants (list for enums), value (raw macro definition), expanded_value (preprocessor-resolved macro value) when applicable. A declaration has no extent, thus it gets no end_line.

``line`` and ``end_line`` are the extent of the symbol, thus they
are the citation: quote ``file:line-end_line``.  Do not count the
lines of ``source`` to find the end.

``source`` carries a line-number prefix on every line — four
columns, right-aligned, then two spaces (``"  20     bool ..."``).
This tool always numbers its text.  ``read_file`` numbers its
``content`` when you pass ``line_numbers=True``, and the ``source``
of ``search_bodies`` is always bare.  Strip the prefix before you
compare the text with anything.

When the file changed after the last index run, the dict adds
``stale`` (True) and ``stale_warning`` (str).  ``source_origin`` then
tells where the body comes from: ``"disk"`` when the symbol did not
move, ``"index"`` when it did and the body comes from the index
instead.  A moved symbol never gives the code of another symbol.

``_source_truncated`` (True) marks a body that a cap cut:
``index.max_symbol_body_lines`` bounds the number of lines, and a
second cap bounds the characters.  The character cut lands in the
middle of a line, thus a body with this mark can end in an
unbalanced brace.  Read the rest with ``read_file`` and a range.

An ``ambiguous_warning`` key means that *name* matched more than one
symbol, such as two classes with a method of the same name.  This
body belongs to ONE of them, and the key names it and lists the
others.  Give the full qualified name to get one symbol only.  It is
separate from ``warning``, which reports a body that could not be
read from the disk.

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
nameYesFully qualified symbol name. Returns exact function body via libclang extent.
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 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 / 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.6/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. It discloses read-only/no side effects, ifdef-filtering behavior, stale_warning and source_origin semantics, truncation caps, line-number prefixes, ambiguous_warning, and failure modes with candidates/hints. This is exceptionally transparent.

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 long but well-organized into purpose, filtering behavior, alternatives, args, and returns. Every section adds operational detail, though some redundancy with the schema's parameter descriptions keeps it from being maximally lean.

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?

With no output schema and no annotations, the description fully explains return fields, special keys, truncation, line-number citation, stale data, ambiguity, and error handling. An agent has enough information to invoke the tool correctly and interpret its result without external documentation.

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

Parameters3/5

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

Schema description coverage is 100%, and the description's Args section mostly restates the parameter semantics already present in the schema (auto-detection, mutual exclusivity, list_projects). It adds little new meaning beyond the structured data, so the baseline of 3 is appropriate.

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 opening sentence states a specific verb and resource: 'Read a C/C++ function/method/enum/macro body using libclang exact extents.' It also distinguishes this from generic file readers and explicitly names siblings ('get_symbol_context', 'normal file read'), so an agent can tell what this tool uniquely does.

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?

Usage guidance is explicit and actionable: 'For rich context ... use get_symbol_context instead' and 'For the full file, use a normal file read.' It also gives parameter-selection rules such as 'Give one of the two, not both' for project vs project_root, 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.