Skip to main content
Glama

get_symbol

Read-onlyIdempotent

Retrieve a specific function, class, or method by symbol ID or fully qualified name and return only its source code and signature, instead of reading the whole file.

Instructions

Look up a symbol by symbol_id or FQN and return its source code. Use instead of Read when you need one specific function/class/method — returns only the symbol, not the whole file. For multiple symbols at once, prefer get_context_bundle. Read-only. Returns JSON: { symbol_id, name, kind, fqn, signature, file, line_start, line_end, source }.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fqnNoThe fully qualified name to look up
max_linesNoTruncate source to this many lines (omit for full source)
symbol_idNoThe symbol_id to look up
verify_against_gitNoCompare the indexed source against the current git HEAD slice; mismatches set `git_mismatch: true` in the response (index may be stale). Read-only. Silently skipped when git is unavailable or the file is untracked.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.22.0
    • removedInput schema / required
      Removed value: -[
      -  "symbol_id",
      -  "fqn"
      -]
  2. Changed2 schema fields changedv3.3.0
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • changedInput schema / properties / verify_against_git / description
      Previous value: -"When true, compare the indexed source against the current git HEAD slice for that file and line range. If they differ, the response includes `git_mismatch: true` indicating the index may be stale. Read-only — never writes. Silently skipped when git is unavailable or the file is not tracked."New value: +"Compare the indexed source against the current git HEAD slice; mismatches set `git_mismatch: true` in the response (index may be stale). Read-only. Silently skipped when git is unavailable or the file is untracked."
  3. Changed1 schema field changedv1.43.2
    • addedInput schema / properties / verify_against_git
      Added value: +{
      +  "description": "When true, compare the indexed source against the current git HEAD slice for that file and line range. If they differ, the response includes `git_mismatch: true` indicating the index may be stale. Read-only — never writes. Silently skipped when git is unavailable or the file is not tracked.",
      +  "type": "boolean"
      +}
  4. Added
  5. Removedv1.38.0
  6. Changed2 schema fields changedv1.35.1
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / required
      Added value: +[
      +  "symbol_id",
      +  "fqn"
      +]
  7. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already establish readOnly, idempotent, and non-destructive behavior. The description adds useful context beyond annotations: it returns only the symbol rather than the whole file and provides the response shape. It does not mention the verify_against_git comparison behavior or git_mismatch in the return payload, though that is documented in the parameter schema, so this is a minor omission rather than a contradiction.

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

Conciseness5/5

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

The description is compact and front-loaded with the core purpose. It packs usage guidance, behavioral scope, read-only information, and return shape into three sentences with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description provides a return shape despite the lack of an output schema and clearly routes between siblings. However, it does not explicitly state that exactly one of symbol_id or fqn is required, and the verify_against_git behavior only lives in the schema. These are real but minor gaps given the otherwise rich annotation and schema context.

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%, so the schema already explains each parameter. The description reinforces that either symbol_id or fqn can be used, but it does not add significant meaning beyond the schema for max_lines or verify_against_git. This matches the baseline for fully covered schema parameters.

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: 'Look up a symbol by symbol_id or FQN and return its source code.' It clearly distinguishes the tool from Read and get_context_bundle, so an agent can immediately understand what it does and which sibling it is not.

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?

The description gives explicit usage direction: 'Use instead of Read when you need one specific function/class/method' and 'For multiple symbols at once, prefer get_context_bundle.' This tells the agent when to select this tool and when to select a sibling.

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