Skip to main content
Glama

get_symbol

Look up a symbol by name to find its definition, callers, and callees with resolution-based matching, enabling reliable navigation and refactoring.

Instructions

Look up a single symbol by name in the local corbel index and return where it is defined (file, line, signature), everything that calls it (callers), and everything it calls (callees). Every caller and callee comes with a resolution field (e.g. same-file, scoped, global-unique) naming which index-wide lookup found the definition, rather than a guess from text matching — this is what makes the result trustworthy for navigation and refactoring, unlike a grep/text search which can't tell you if a match is actually the same symbol. scoped and global-unique both mean a single matching definition was found index-wide; the difference is only whether the caller's file imports that name (see docs/mcp-tools.md for details). Use this tool when you need to jump to a function's or type's definition, inspect its signature, or see who calls it and what it calls, before editing it. If name (optionally narrowed by file) still matches more than one symbol — e.g. overloaded declarations in the same file — pass line as well; the find tool's results already carry the exact name/file/line triple needed to pin down one match. The response can be truncated to fit within a token budget; when it is, truncated is set to true and truncated_count reports how many additional callers and callees together were left out. The budget is divided evenly across every matched symbol first (so if name is ambiguous and returns several results, no single match can consume the whole budget and starve the others), then each match's own share is split evenly between its callers and its callees (so a hot function's huge caller list can't crowd out its callees, or vice versa). The index is built ahead of time by corbel index and only reflects the state of the repository as of the last index run.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fileNoOptional file path to disambiguate when multiple symbols share this name.
lineNoOptional definition line to disambiguate further, for when `name` and `file` alone still match more than one symbol (e.g. overloaded declarations in the same file). Requires `file` to also be set.
nameYesThe symbol name to look up (function, method, type, etc.).
token_budgetNoOptional cap on the size of the response, in estimated tokens. Divided evenly across every matched symbol first, then each match's share is split evenly between its callers and callees. Defaults to corbel's built-in budget if omitted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden, and it does so thoroughly. It discloses that the index is built ahead of time by `corbel index` and may be stale, that `resolution` reflects index-wide lookup rather than text matching, explains the difference between `scoped` and `global-unique`, and details truncation behavior (`truncated`, `truncated_count`) and token-budget allocation. This is a very transparent description of behavior and limitations.

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 front-loaded with the core purpose and then scaffolds into disambiguation, truncation, budget, and staleness, which is logical. It is longer than average, but every sentence earns its place given there are no annotations and no output schema. A small deduction because the budget explanation is somewhat wordy and could be tightened without losing meaning.

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 tool with no output schema and no annotations, the description is highly complete: it names the return components (definition, callers, callees, `resolation`), explains how disambiguation works, covers truncation and budget behavior, and notes index staleness. An agent has enough context to invoke the tool correctly and interpret its results without further lookup.

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?

Schema description coverage is 100%, so the baseline is 3, but the description adds substantial meaning beyond the schema. It explains that `file` narrows the lookup, that `line` requires `file` and is for overloaded declarations, and it provides a detailed account of how `token_budgets` is divided across matches and then between callers and callees. This goes well beyond the parameter descriptions in the schema.

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 single symbol by name in the local corbel index and return where it is defined (file, line, signature), everything that calls it (callers), and everything it calls (callees).' It clearly distinguishes itself from grep/text search and implies a difference from sibling `find` by noting the exact name/file/line triple needed to pin down one match. This is more than adequate for an agent to understand what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description contains explicit usage guidance: 'Use this tool when you need to jump to a function's or type's definition, inspect its signature, or see who calls it and what it calls, before editing it.' It also advises passing `line` when a name is ambiguous and references the `find` tool's output as a source for the disambiguation triple. It stops short of explicitly stating when NOT to use this tool versus `find` or `impact`, so it earns a 4 rather than a 5.

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

Deploy Server

Other Tools