Skip to main content
Glama

read_symbol

Read-only

Return the source of a single function, class, method, variable, or config key without reading the whole file. Use depth options to fetch full code, interface, or signature.

Instructions

Return the source of one symbol (function, class, method, variable) or the value of a config key, without reading the whole file. Read-only. "full" is the text replace_function and delete_symbol take: decorators, a JS/TS export, a C++ template <...> header and code that only wraps the symbol (a Go type, a closure's key, a C typedef) included, a C/C++ class ending with its ;. It starts at the symbol's first byte, the later lines at their file indentation. "interface" gives a class's header, fields and method signatures (bodies as ...), indented as in the class, or a function's signature; "signature" the signature or class header alone, after decorators. Both refuse a variable, constant, field, type alias or macro, saying what it is. A name with a prototype or forward declaration reads as its definition.

Use this when: reading one symbol; pick the narrowest depth. Don't use this when: you need the file's outline (list_symbols) or its imports (read_imports).

Example: target="LRUCache", depth="interface"

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "file_path": "<file_path>",
      "target": "<target>"
    },
    "name": "read_symbol"
  }
}

Input Schema

NameRequiredDescriptionDefault
depthNo'full' (default) the whole symbol; 'interface' a class skeleton or function signature; 'signature' the signature or class header. Config files take only 'full'. Other values are refused.full
targetYesSymbol name as list_symbols lists it, dotted for nesting ('LRUCache.get', 'A.m(int)'), or a config key path from the top level ('project.version'; quote a key with dots, '"editor.fontSize"').
file_pathYesAbsolute path to the source or config file.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv3.2.0
    • addedInput schema / properties / depth / description
      Added value: +"'full' (default) the whole symbol; 'interface' a class skeleton or function signature; 'signature' the signature or class header. Config files take only 'full'. Other values are refused."
    • addedInput schema / properties / file_path / description
      Added value: +"Absolute path to the source or config file."
    • addedInput schema / properties / target / description
      Added value: +"Symbol name as list_symbols lists it, dotted for nesting ('LRUCache.get', 'A.m(int)'), or a config key path from the top level ('project.version'; quote a key with dots, '\"editor.fontSize\"')."
  2. Changed1 schema field changedv2.10.0
    • addedInput schema / properties / depth
      Added value: +{
      +  "default": "full",
      +  "title": "Depth",
      +  "type": "string"
      +}
  3. First observedv1.2.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare read-only/non-destructive, so the description's real value is the disclosure of output semantics that no structured field carries: exactly what 'full' text includes (decorators, JS/TS export, C++ template header, Go type wrappers, C typedefs, class trailing ';'), where the text starts and how later lines are indented, and that 'interface'/'signature' refuse variables, constants, fields, type aliases and macros with an explanatory error. Prototype/forward-declaration resolution to the definition is also a behavioral trait worth knowing.

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?

Front-loaded with the purpose, then the depth semantics, then a clearly labeled use/don't-use block and an example — good structure. The middle paragraph is unusually dense (a single sentence enumerating Go types, typedefs, template headers, closure keys), which costs some readability but every clause carries real information.

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 an output schema present and full parameter coverage, the description need only cover call semantics — and it does: depth choice, target naming, config-file restriction to 'full', and how symbols with prototypes resolve. Nothing an agent needs to invoke 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 coverage is 100%, so the baseline is 3; the description nonetheless adds meaning the schema does not, notably the concrete shape of each depth's text and the refusal behavior of the narrower depths. The target-format detail (dotted nesting, quoted dotted config keys) duplicates the schema rather than extending it, which keeps it from a 5.

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 and resource ('Return the source of one symbol ... or the value of a config key') plus the key benefit ('without reading the whole file'), which immediately separates it from file-level readers. The 'Use this when / Don't use this when' block names list_symbols and read_imports as the alternatives, so the agent can route without opening a schema.

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 two-sided guidance: 'Use this when: reading one symbol; pick the narrowest depth' and 'Don't use this when: you need the file's outline (list_symbols) or its imports (read_imports)'. The alternatives are named with the exact condition that selects them, and the depth-selection heuristic is stated.

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