Skip to main content
Glama

find_symbol

Search a code graph to locate classes, interfaces, functions, or variables by name or partial name, with optional type and workspace filters.

Instructions

Search graph for code symbols (Class, Interface, Function, Variable).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>"
    },
    "name": "find_symbol"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesSymbol name or partial name.
limitNoMax results (default: 50).
symbolTypeNoOptional type: 'Class', 'Interface', 'Function', 'Variable'.
workspacePathNoOptional workspace root path.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.80.5

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden and mostly fails to: it does not say that this is a read-only query, whether matching is case-sensitive or substring-based, what the default search scope is when workspacePath is null, or how results are ordered. The enumeration of symbol types is the only behavioral detail it contributes.

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?

A single front-loaded sentence with no filler or hedging. The parenthetical slightly duplicates the symbolType schema description, but the sentence otherwise earns its place.

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

Completeness2/5

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

With four parameters, no annotations, and no output schema, an agent needs to know match semantics, default scope, result shape, and ordering rules. None of these are covered, so the definition is too thin for a search tool whose behavior is not self-evident from its name.

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?

Schema coverage is 100%, so the parameters are already fully documented, and the baseline of 3 applies. The parenthetical '(Class, Interface, Function, Variable)' restates the symbolType enum rather than adding new meaning, and it says nothing about how partial names are matched.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (Search) and resource (code symbols in the graph) and enumerates the symbol kinds covered. It stops short of distinguishing this from siblings such as search_identifiers or get_file_outline, which appear to overlap on surface form.

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

Usage Guidelines2/5

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

There is no guidance on when to use this versus alternatives, nor any stated preconditions (e.g., whether a workspace must be indexed first). The only clue is the word 'Search', leaving the agent to infer scope from the name alone.

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