Skip to main content
Glama
Raheem-19

Serena MCP Server

by Raheem-19

find_symbol

Find and retrieve code symbols (classes, methods, etc.) using name paths. Use filters for depth, symbol kind, and file locations to get precise results with source code.

Instructions

Retrieves information on all symbols/code entities (classes, methods, etc.) based on the given name_path, which represents a pattern for the symbol's path within the symbol tree of a single file. The returned symbol location can be used for edits or further queries. Specify depth > 0 to retrieve children (e.g., methods of a class).

The matching behavior is determined by the structure of name_path, which can either be a simple name (e.g. "method") or a name path like "class/method" (relative name path) or "/class/method" (absolute name path). Note that the name path is not a path in the file system but rather a path in the symbol tree within a single file. Thus, file or directory names should never be included in the name_path. For restricting the search to a single file or directory, the within_relative_path parameter should be used instead. The retrieved symbols' name_path attribute will always be composed of symbol names, never file or directory names.

Key aspects of the name path matching behavior:

  • Trailing slashes in name_path play no role and are ignored.

  • The name of the retrieved symbols will match (either exactly or as a substring) the last segment of name_path, while other segments will restrict the search to symbols that have a desired sequence of ancestors.

  • If there is no starting or intermediate slash in name_path, there is no restriction on the ancestor symbols. For example, passing method will match against symbols with name paths like method, class/method, class/nested_class/method, etc.

  • If name_path contains a / but doesn't start with a /, the matching is restricted to symbols with the same ancestors as the last segment of name_path. For example, passing class/method will match against class/method as well as nested_class/class/method but not method.

  • If name_path starts with a /, it will be treated as an absolute name path pattern, meaning that the first segment of it must match the first segment of the symbol's name path. For example, passing /class will match only against top-level symbols like class but not against nested_class/class. Passing /class/method will match against class/method but not nested_class/class/method or method. Returns a list of symbols (with locations) matching the name.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
depthNoDepth to retrieve descendants (e.g., 1 for class methods/attributes).
name_pathYesThe name path pattern to search for, see above for details.
include_bodyNoIf True, include the symbol's source code. Use judiciously.
exclude_kindsNoOptional. List of LSP symbol kind integers to exclude. Takes precedence over `include_kinds`. If not provided, no kinds are excluded.
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.
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.
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.
substring_matchingNoIf True, use substring matching for the last segment of `name`.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior3/5

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

The description offers detailed matching semantics (absolute vs relative paths, trailing slashes, ancestor constraints) but has no annotations to lean on. It contains an ambiguous statement about exact vs substring matching, and does not explain how the substring_matching parameter modifies behavior. The read-only nature is implied but not explicit.

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

Conciseness3/5

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

The description is structured with a main paragraph and bullet list, but it is quite long and includes some redundant details and an erroneous parameter name. While the complexity of name_path justifies length, the inaccurate reference makes it less concise and clear than it could be.

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

Completeness3/5

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

Although an output schema exists, the description focuses almost exclusively on name_path and relative_path, leaving out integrated guidance on include_kinds, exclude_kinds, include_body, and substring_matching. For a tool with eight parameters, this is a notable gap, but the schema partially compensates.

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?

The schema already provides 100% parameter coverage. The description adds significant value for name_path, but incorrectly references a non-existent parameter (`within_relative_path`) and does not clarify how substring_matching interacts with the described rules. This reduces reliability of the added guidance.

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 that the tool retrieves information on code entities using a name_path pattern, with specific examples and distinctions from file paths. It clearly identifies the resource (symbols) and the operation (retrieve), differentiating it from sibling tools like find_file and find_referencing_symbols.

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

Usage Guidelines3/5

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

Provides useful guidance on when to use depth and relative_path, but misnames the parameter as `within_relative_path` instead of `relative_path`, which could mislead an agent. It does not explicitly compare this tool to alternatives like find_referencing_symbols or get_symbols_overview, leaving the when-not-to-use unclear.

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/Raheem-19/serena-optimized'

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