Skip to main content
Glama

search

Locate code symbols by name, signature, or natural-language meaning across an indexed repository, returning ranked records with kind, signature, and line ranges instead of raw grep matches.

Instructions

Hybrid structural + semantic code search across the indexed codebase. Fuses FST exact + BM25 + semantic channels in a single ranked list (~4ms FST hit, ~7-15ms with semantic). Prefer over grep for symbol or identifier lookup — grep does a full-scan (seconds on large repos) and returns line matches; this returns ranked symbol records with kind, signature, and line ranges. Use this when you need to find a definition by name, signature shape, or meaning rather than guessing a regex. Supports filter (substring path filter), kind (kind-boost / restrict), context_path (proximity hint), no_bm25 (disable BM25 channel), and no_stale_check (skip pre-call staleness probe).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
whyNoSurface a JSON trace under `_meta.why` in the response: normalized query, per-channel hits (FST/BM25/semantic/fuzzy), filter_applied snapshot
kindNoBoost results matching one or more kinds (repeatable). Canonical names (function, struct, class, …) plus aliases: def, comment, test, ref.
limitNoMax results
queryYesFree-text query: symbol name, partial name, signature snippet, or natural-language description. Not for regex (use grep) or exact-only resolution (use find_symbol).
sinceNoRestrict results to files changed between `<rev>..HEAD` (accepts anything `git diff` understands: `main`, `HEAD~3`, `origin/main`, SHA). Mutually exclusive with `since_branched` and `changed_only`.
excludeNoBlacklist results by path glob (wins over include); repeat for multiple globs
includeNoWhitelist results by path glob, gitignore syntax (e.g. 'tests/**'); repeat for multiple globs
no_bm25NoDisable the BM25 channel for this query (auto-on when the index has BM25 data otherwise).
no_asyncNoExclude async/suspend functions
semanticNoEnable the semantic vector channel (requires `vex index --semantic`); adds ~3-10ms but lets natural-language queries hit
code_onlyNo(v1.20.0 D4) Drop results in prose-format files (`*.md`/`*.markdown`/`*.txt`/`*.rst`/`*.adoc`). Default off so 'README' still finds the README; pass for code-intent queries where CHANGELOG/README headings would pollute the top of the result list.
workspaceNoMulti-repo: fan out across every repo declared in the nearest `.vex-workspace.toml` (set `project_root` at or above it — the manifest is found by walking up). Results become an object `{workspace, repos:[...]}` grouped by repo, NOT the flat per-tool array — branch on shape. `why` is ignored in workspace mode (single-repo only).
async_onlyNoKeep only async/suspend functions
visibilityNoKeep only symbols whose signature contains this explicit visibility keyword (no inferred defaults)
auto_updateNoAuto-update the index if stale, or bootstrap it if missing, before running (default: true)
filter_pathNoSubstring path filter applied to result paths (single substring; use include/exclude for glob patterns). Legacy alias: `filter`.
sealed_onlyNoKeep only sealed (or Java-`final`) types
static_onlyNoKeep only static class members
async_updateNoWith auto_update, refresh a stale index in the background instead of waiting for it: results come from the index already on disk and _meta.vex.dev/stale says so (default: false)
changed_onlyNoRestrict results to working-tree changes (staged + unstaged + untracked). Mutually exclusive with `since` and `since_branched`.
context_pathNoBoost results near this file path (e.g. the agent's current editor file).
project_rootNoAbsolute path to the project root (defaults to the MCP working directory)
exclude_testsNoDrop test files from the results (tests/ dirs, *_test.*, test_*.py, *.spec.ts, __tests__/, tests.rs, ...; same set as tests_for). Composes with include/exclude. Path-based only: Rust unit tests inside a `#[cfg(test)] mod tests` block of a non-test file are not excluded.
no_stale_checkNoSkip the staleness check that runs before each call; assumes the index is fresh. Redundant when `auto_update` is true (which already refreshes).
since_branchedNoRestrict results to files changed since this branch diverged from `origin/main` (or `main`/`master`). Mutually exclusive with `since` and `changed_only`.
exclude_generatedNoDrop machine-generated files (protobuf stubs, sqlc output, bindgen bindings, ORM schemas) from the results, recognised from the generator's header banner. Pass on repos that check in generated code, where the stubs outnumber and outrank hand-written symbols. Heuristic: a generator that writes no banner is not detected, so it under-reports rather than hiding hand-written code.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.27.3

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses return shape (ranked symbol records with kind, signature, line ranges) and performance (~4ms FST, ~7-15ms with semantic). It omits notable side-effect behavior such as the default auto_update bootstrapping/refreshing the index and the workspace-mode result-shape change, which live only in the schema.

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?

Front-loads the core capability, then routes to alternatives, then summarizes params. Dense and mostly waste-free, though the trailing 'Supports ...' list leans toward enumeration rather than insight.

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?

For a 26-parameter tool with no output schema, the description covers purpose, routing, latency, and return record shape well. Gaps remain around the workspace-mode shape change and auto_update side effects, but the structured schema 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?

Schema description coverage is 100% and the schema descriptions are unusually thorough, so the baseline is 3. The description restates filter/kind/context_path/no_bm25/no_stale_check in condensed form, giving a light mental model, but adds little beyond what the schema already documents.

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?

States a specific verb+resource ('Hybrid structural + semantic code search across the indexed codebase') and quantifies the mechanism (FST + BM25 + semantic fused into one ranked list). It also distinguishes itself from grep and find_symbol by name, so an agent can route without opening another schema.

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?

Explicitly says to prefer this over grep for symbol/identifier lookup and explains why (grep full-scans and returns line matches vs ranked symbol records). It names the alternatives (grep for regex, find_symbol for exact-only resolution) and the condition that selects each.

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