Skip to main content
Glama

Find Symbol

find_symbol
Read-only

Locates code symbols like classes and methods using name patterns to enable precise editing and navigation within codebases.

Instructions

Retrieves information on all symbols/code entities (classes, methods, etc.) based on the given name path pattern. The returned symbol information can be used for edits or further queries. Specify depth > 0 to also retrieve children/descendants (e.g., methods of a class).

A name path is a path in the symbol tree within a source file. For example, the method my_method defined in class MyClass would have the name path MyClass/my_method. If a symbol is overloaded (e.g., in Java), a 0-based index is appended (e.g. "MyClass/my_method[0]") to uniquely identify it.

To search for a symbol, you provide a name path pattern that is used to match against name paths. It can be

  • a simple name (e.g. "method"), which will match any symbol with that name

  • a relative path like "class/method", which will match any symbol with that name path suffix

  • an absolute name path "/class/method" (absolute name path), which requires an exact match of the full name path within the source file. Append an index [i] to match a specific overload only, e.g. "MyClass/my_method[1]". Returns a list of symbols (with locations) matching the name.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
name_path_patternYesThe name path matching pattern (see above).
depthNoDepth up to which descendants shall be retrieved (e.g. use 1 to also retrieve immediate children; for the case where the symbol is a class, this will return its methods). Default 0.
relative_pathNoOptional. Restrict search to this file or directory. If None, searches entire codebase. If a directory is passed, the search will be restricted to the files in that directory. If a file is passed, the search will be restricted to that file. If you have some knowledge about the codebase, you should use this parameter, as it will significantly speed up the search as well as reduce the number of results.
include_bodyNoIf True, include the symbol's source code. Use judiciously.
include_kindsNoOptional. List of LSP symbol kind integers to include. (e.g., 5 for Class, 12 for Function). Valid kinds: 1=file, 2=module, 3=namespace, 4=package, 5=class, 6=method, 7=property, 8=field, 9=constructor, 10=enum, 11=interface, 12=function, 13=variable, 14=constant, 15=string, 16=number, 17=boolean, 18=array, 19=object, 20=key, 21=null, 22=enum member, 23=struct, 24=event, 25=operator, 26=type parameter. If not provided, all kinds are included.
exclude_kindsNoOptional. List of LSP symbol kind integers to exclude. Takes precedence over `include_kinds`. If not provided, no kinds are excluded.
substring_matchingNoIf True, use substring matching for the last element of the pattern, such that "Foo/get" would match "Foo/getValue" and "Foo/getData".
max_answer_charsNoMax characters for the JSON result. If exceeded, no content is returned. -1 means the default value from the config will be used.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

Annotations declare readOnlyHint=true and destructiveHint=false, which the description doesn't contradict. The description adds valuable behavioral context beyond annotations: it explains that results are returned as a list of symbols with locations, mentions that the tool can be used for subsequent edits, warns about using 'include_body' judiciously, and describes performance implications of the 'relative_path' parameter. This provides practical guidance that annotations alone don't cover.

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 well-structured and appropriately sized. It starts with the core purpose, then explains key parameters (name path patterns, depth), provides concrete examples, and ends with what's returned. While comprehensive, some sentences could be more concise (e.g., the name path pattern explanation spans multiple paragraphs). Overall, it's informative without being excessively verbose.

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?

Given the tool's complexity (8 parameters, sophisticated matching logic), the description provides excellent context. It explains the core matching logic, provides practical examples, mentions performance considerations, and notes that results can be used for edits. With annotations covering safety, 100% schema coverage, and an output schema existing, the description focuses appropriately on the conceptual aspects that structured fields don't capture.

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?

With 100% schema description coverage, the schema already documents all 8 parameters thoroughly. The description adds some semantic context: it explains name path patterns with examples (simple name, relative path, absolute path), clarifies how overloaded symbols are handled with indexes, and mentions that 'depth > 0' retrieves children/descendants. However, most parameter details are already in the schema, so the description provides only moderate additional value.

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 clearly states the tool's purpose: 'Retrieves information on all symbols/code entities (classes, methods, etc.) based on the given name path pattern.' It specifies the verb ('retrieves'), resource ('symbols/code entities'), and scope ('based on name path pattern'). It also distinguishes from siblings like 'find_file' (which finds files) and 'find_referencing_symbols' (which finds references rather than symbols themselves).

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 provides clear context for when to use this tool: for retrieving symbol information that 'can be used for edits or further queries.' It mentions using 'depth > 0' for retrieving descendants and suggests using the 'relative_path' parameter to speed up searches. However, it doesn't explicitly state when NOT to use this tool or name specific alternatives among siblings (e.g., when to use 'find_file' instead).

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/chrisgreenx-ctrl/serena'

If you have feedback or need assistance with the MCP directory API, please join our Discord server