Skip to main content
Glama

get_symbol

Read-only

Read the full indexed source of a named function, method, class, or type, with qualified name and line range. Use it when the symbol name is known instead of searching code or opening files.

Instructions

Read the full source of a named definition (function, method, class, type) when you know its name, for example from a search_code hit. Use this instead of search_code when the name is known, and instead of opening files: it returns the source exactly as it was indexed. A bare name returns every definition with that name, each labeled with its qualified name; pass a qualified name or a repo to narrow. Returns up to 5 matches, each with its qualified name, kind, repository, path, line range and source. A source longer than 400 lines is cut there and marked cut, and its full line range is still given. total is the number of matches and truncated is true when more than 5 matched. Unparsed files indexed as line windows have no names and are not found here; use search_code for them.

Input Schema

NameRequiredDescriptionDefault
nameYesA bare name (url_for), which matches url_for and every Class.url_for, or a qualified name (Flask.url_for), which matches only that definition. Case-sensitive.
repoNoLook only in this registered repository, for example flask. list_repositories gives the valid names. Default: all repositories.

Output Schema

NameRequiredDescriptionDefault
totalNo
reasonYes
statusYes
resultsYes
truncatedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.4.2

TDQS

A4.8/5.0
Behavior5/5

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

Beyond readOnlyHint=true, the description discloses concrete behavioral traits: return shape (qualified name, kind, repo, path, line range, source), the 5-match cap, the 400-line source cutoff marked 'cut', the 'total'/'truncated' pagination signals, and the caveat that unparsed files cannot be found. This is unusually complete for a read tool.

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?

Usage guidance is front-loaded ahead of return-format and edge-case details, and each sentence carries distinct information. It is denser and longer than ideal, but no sentence is padding.

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 two-parameter read tool with an output schema and readOnly annotation, nothing an agent needs is missing: selection criteria, match cap, truncation behavior, and the unparsed-file limitation are all covered.

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 parameters are already documented, but the description adds the useful cross-parameter behavior: a bare name fans out to every same-named definition each labeled with its qualified name, while a qualified name or repo narrows the result. That is genuine semantic value beyond the field descriptions, though it partially repeats the schema text.

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 first sentence gives a specific verb and resource ('Read the full source of a named definition') and enumerates the definition kinds in scope. It explicitly contrasts itself with search_code and with opening files, so an agent can distinguish it from siblings without inspecting schemas.

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?

It states exactly when to prefer this tool ('when the name is known, for example from a search_code hit') and names the two alternatives it replaces. It also gives the one exclusion case: unparsed line-window files, which should be handled with search_code instead.

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