Skip to main content
Glama

code_find_symbol

Read-onlyIdempotent

Find where functions, methods, classes, or other symbols are defined in indexed C#, Python, and TypeScript code using exact names, words, or meaning, and optionally rank related files.

Instructions

Find where a function, method, class or other symbol is defined in indexed code (C#, Python, TypeScript). match="exact" (default) takes a name as far as you know it: "Post", "Ledger.Post" or "Acme.Billing.Ledger.Post". match="words" takes words that all appear in the qualified name ("ledger post"). match="meaning" takes a description ("where invoices are written to the ledger"). With follow=true, also returns what the first definition calls, constructs or inherits and the files defining those: the files to read to see how it works. Returns definitions with path, start and end line and signature, and ranked files.

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": {
      "containerId": "<containerId>",
      "query": "<query>"
    },
    "name": "code_find_symbol"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoAt most this many definitions (1-100). Default 10
matchNo"exact" (default), "words" or "meaning"
queryYesThe symbol name, words, or a description, per `match`
followNoAlso follow what the definition calls into, and rank those files
containerIdYesContainer or source ID or name

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.0

TDQS

A4.1/5.0
Behavior4/5

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

The annotations already declare the key behavior, since readOnlyHint and idempotentHint tell the agent this is a safe, repeatable read, so the bar here is lower. The description adds context the annotations cannot: the field-level shape of the results (path, start and end line, signature) and the ranked files that follow=true produces.

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

Conciseness5/5

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

The description is dense but front-loaded: it opens with the core purpose, then walks through each match mode in a quick parallel clause, then explains follow and the return shape. Every sentence earns its place; the parenthetical lists of match values and supported languages are necessary, not padding.

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?

There is no output schema, so the description carries the burden of explaining return values, and it does that well with path, line range, signature and ranked files. It does not say what happens when no symbol is found or how limit interacts with ranked results, but those are minor gaps for a read-only lookup 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 coverage is 100%, so the baseline is 3, but the description earns more by explaining what each match value actually does to the query string and by describing follow as 'also returns what the first definition calls, constructs or inherits and the files defining those'. The one parameter left untouched is containerId and limit, both adequately described in the schema.

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 names a specific verb and resource: it locates where a function, method, class or symbol is defined in indexed code, and it limits that scope to C#, Python and TypeScript. The agent can tell this is a definition lookup rather than a reference search, but the description never names code_references or code_impact, so the tool isn't explicitly separated from those siblings.

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 three match modes are spelled out with concrete example queries ("Post", "ledger post", "where invoices are written to the ledger"), giving the agent clear direction on how to phrase a query for each mode. It also explains when follow=true is useful (to see how the code works), but there is no guidance on when to prefer this tool over code_references or code_impact.

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