Skip to main content
Glama
lin2000wl

Serena MCP Server

by lin2000wl

find_symbol

Locate code symbols like classes and methods within your codebase using name path patterns, enabling precise navigation for editing or further analysis.

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 JSON string: a list of symbols (with locations) matching the name.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
name_pathYesThe name path pattern to search for, see above for details.
depthNoDepth to retrieve descendants (e.g., 1 for class methods/attributes).
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.
exclude_kindsNoOptional. List of LSP symbol kind integers to exclude. Takes precedence over `include_kinds`.
substring_matchingNoIf True, use substring matching for the last segment of `name`.
max_answer_charsNoMax characters for the JSON result. If exceeded, no content is returned.
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively explains key behaviors: the matching logic for `name_path`, the role of `depth` for retrieving children, and the return format (JSON list of symbols with locations). It also hints at performance considerations with `relative_path` but lacks details on rate limits or error handling.

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 front-loaded with the core purpose but becomes verbose with detailed explanations of `name_path` matching behavior. While informative, some sentences could be more streamlined, and the structure includes repetitive examples that might be condensed for better clarity without losing essential information.

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?

Given the complexity of 8 parameters, no annotations, and no output schema, the description does a good job of covering key aspects like purpose, usage, and parameter semantics. It explains the return format and provides examples, but could improve by summarizing all parameters briefly or mentioning error cases to be more complete for such a multifaceted tool.

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 description coverage is 100%, so the baseline is 3. The description adds significant value by elaborating on `name_path` semantics, including examples and matching rules, and clarifies `depth` usage. It also mentions `relative_path` for restricting searches, enhancing understanding beyond the schema. However, it does not cover all parameters like `include_kinds` or `max_answer_chars` in detail.

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`.' It specifies the resource (symbols/code entities), the verb (retrieves information), and distinguishes it from siblings like 'find_file' or 'find_referencing_symbols' by focusing on symbol tree navigation within files.

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 on when to use this tool, such as for retrieving symbol locations for edits or queries, and mentions using the `relative_path` parameter to restrict searches. However, it does not explicitly state when not to use it or name specific alternatives among siblings, though it implies differentiation from file-based searches.

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/lin2000wl/Serena-cursor-mcp'

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