Skip to main content
Glama

callers

Find direct call sites of a function using a persistent call-graph, avoiding grep false positives. Supports decorator/annotation edges and diff scoping.

Instructions

Direct callers of a function via the persistent call-graph FST (~4ms when indexed; falls back to live-scan). Prefer over grep for who calls Foo? — grep on the function name hits doc comments and string literals; the call-graph edges are resolved at parse time. Phase 14.2 + 14.2.2 + 14.2.1: Python/Java function/method decorators, Kotlin annotations / C# method+constructor attributes, and TypeScript method decorators / Rust outer attributes on fns/methods emit forward edges, so callers GetMapping lists every Spring handler, callers get lists every FastAPI route, callers HttpGet every ASP.NET action, callers JvmStatic every Kotlin function annotated @JvmStatic, callers Get every Nest.js @Get(...), callers test every Rust #[tokio::test] (the rightmost identifier of the decorator/attribute path becomes the callee; arguments are ignored — #[serde(rename = "x")] → serde, not rename). Rust #[derive(...)] is filtered (compile-time codegen, not call edges). Note the rightmost-identifier convention means callers get mixes decorator handlers with any regular .get() call — narrow with include/exclude if needed. Pair with paths for multi-hop chains. Supports diff scoping: since / since_branched / changed_only (mutually exclusive) to restrict callers to recently-touched code.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoDEPRECATED — use `symbol`. Pre-v1.7 alias, still accepted; emits a deprecated_args notice in _meta.
limitNoMax results
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`.
symbolYesExact function name — canonical key (v1.7+).
excludeNoBlacklist results by path glob; wins over include (repeatable)
includeNoWhitelist results by path glob, gitignore syntax (repeatable)
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).
auto_updateNoAuto-update the index if stale, or bootstrap it if missing, before running — enables the call-graph fast path (default: true)
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`.
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.
since_branchedNoRestrict results to files changed since this branch diverged from `origin/main` (or `main`/`master`). Mutually exclusive with `since` and `changed_only`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.27.3

TDQS

A4.4/5.0
Behavior4/5

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

No annotations, so the description carries the burden and does well: it discloses the fast-path timing (~4ms indexed), live-scan fallback, parse-time edge resolution, and the decorator rightmost-identifier convention including the `serde` vs `rename` edge case and filtered `#[derive(...)]`. It omits any mention of index side effects (auto_update bootstrap writes an index) and auth/permission requirements.

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?

Purpose and the grep comparison are front-loaded, but the middle devolves into a long run-on sentence enumerating five near-identical framework examples that restate the same rightmost-identifier rule. Dense and useful, but the example list is repetitive rather than earning each clause.

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 14-param read tool with no annotations and no output schema, coverage is strong: diff-scoping exclusivity, decorator semantics, and workspace shape are all addressed. The remaining gap is return-format behavior beyond the workspace note, which the missing output schema leaves to inference.

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 adds real semantic value the schema lacks: the rightmost-identifier convention that determines what `symbol` matches, the decorator/attribute edge sources, and how that convention makes `callers get` mix decorator handlers with `.get()` calls.

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?

Opens with a specific verb+resource: 'Direct callers of a function via the persistent call-graph FST'. It explicitly distinguishes itself from grep and names siblings (paths, tests_for) so an agent can route correctly without opening schemas.

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?

Explicit 'Prefer over grep for `who calls Foo?`' with the reason (grep hits doc comments/string literals), plus guidance to narrow with include/exclude and to pair with paths for multi-hop chains. When-to-use and alternatives are both stated.

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