Skip to main content
Glama

find

Search the local code index for symbols by case-insensitive substring, returning name, file, and line to pin down the exact symbol for call graph queries.

Instructions

Search the local corbel index for symbols whose name matches a query, for when you don't know the exact symbol name to pass to get_symbol. Matching is substring-based and case-insensitive, ranked so exact name matches come first, then names starting with the query, then names merely containing it; within each of those tiers results are ordered by name, then file, then line for a stable, repeatable order. Case-insensitivity only folds ASCII letters (SQLite's default LIKE behavior) — it will not match differently-cased Unicode identifiers (e.g. a Python or JavaScript identifier using non-ASCII letters), so queries against such names must match the identifier's actual case. Each match reports name, file, and line, which together are the exact triple get_symbol needs to pin down that one symbol even when several symbols elsewhere share its name. This tool does not resolve or return call relationships — use get_symbol or impact on a specific match for that. The response can be truncated to fit within limit and a token budget; when it is, truncated is set to true and truncated_count reports how many further matches were left out. Results come from the local corbel index built by corbel index and only reflect the repository as of the last index run.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoOptional cap on the number of matches returned, from 0 up to corbel's hard maximum of 200 (requests above 200 are rejected, not silently reduced). Defaults to corbel's built-in limit if omitted.
queryYesSubstring to search for in symbol names (case-insensitive for ASCII).
token_budgetNoOptional cap on the size of the response, in estimated tokens. Defaults to corbel's built-in budget if omitted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden, and it delivers: it discloses substring matching, ASCII-only case folding, the ranking scheme, stable ordering, truncation behavior with truncated/truncated_count, and the fact that results depend on the last corbel index run. This is unusually transparent behavioral detail.

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 long but every sentence carries useful information that is not derivable from the schema or annotations. It is front-loaded with the core purpose and differentiator before diving into ranking and truncation details. It could be tightened slightly, but the density justifies the length.

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 that there is no output schema and no annotations, the description is remarkably complete: it specifies the match fields (name, file, line) and how they map to get_symbol's needs, explains truncation flags, covers index freshness, and clarifies what the tool does not return. An agent has enough context to invoke it correctly and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the input schema already covers all three parameters (100% coverage), the description adds substantial meaning beyond it: the hard maximum of 200 for limit, rejection behavior above it, the built-in defaults, how token_budget constrains the response, and how query matching and ranking actually behave. This exceeds the baseline 3 for full schema coverage.

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 states a specific verb ('Search'), a specific resource ('the local corbel index'), and a precise condition ('for when you don't know the exact symbol name to pass to get_symbol'). It clearly distinguishes itself from siblings by naming get_symbol and impact and explaining what this tool does not do.

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

Usage Guidelines5/5

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

The description explicitly says when to use the tool ('when you don't know the exact symbol name'), and explicitly defines when not to use it: 'This tool does not resolve or return call relationships — use get_symbol or impact on a specific match for that.' This gives an agent direct routing guidance against sibling tools.

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

Deploy Server

Other Tools