Skip to main content
Glama
tenatarika

vex

by tenatarika
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

callees

Retrieve the direct calls made by a function from a persistent call-graph index, avoiding manual body scanning.

Instructions

Direct callees of a function via the persistent call-graph FST (~4ms when indexed; falls back to live-scan). Prefer over Read+manual scanning when you want to know what a function calls without reading the whole body — callees gives the resolved outgoing edges as records. Phase 14.2 + 14.2.2 + 14.2.1: Python/Java decorators, Kotlin annotations, C# method/constructor attributes, TypeScript method decorators, and Rust outer attributes on fns/methods are surfaced as callees of the decorated function (decorator factories like @lru_cache(maxsize=128), @Inject, @Get("/x"), or #[tokio::test] appear as the path-rightmost identifier lru_cache / Inject / Get / test alongside regular body calls). Rust #[derive(...)] is intentionally filtered. Supports diff scoping: since / since_branched / changed_only (mutually exclusive) to restrict callees 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/5.0
Behavior4/5

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

No annotations provided, so the description carries the full burden. It discloses latency (~4ms indexed, fallback to live-scan), decorator/annotation surfacing behavior for 6 languages (with concrete examples), that Rust #[derive] is intentionally filtered, and diff scoping semantics. Solid behavioral disclosure, though it doesn't cover auth, rate limits, or error modes.

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?

Front-loads the core purpose well, but is quite long and includes a verbose Phase-number changelog block (14.2 + 14.2.2 + 14.2.1) that reads like release notes rather than tool-selection guidance. The decorator detail is useful but the enumeration could be tightened significantly.

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, no-output-schema tool, the description covers fallback behavior, result format hints ('resolved outgoing edges as records'), workspace shape-changing behavior is in schema, and diff scoping. Complete enough to call correctly; could say more about output record shape since there's no output schema.

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 schema already documents all 14 parameters thoroughly. The description reiterates 'since/since_branched/changed_only (mutually exclusive)' which is also in the schema. Baseline 3 is correct when the schema does the heavy lifting.

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: 'Direct callees of a function via the persistent call-graph FST'. This clearly distinguishes it from siblings like 'callers' (inverse direction) and 'Read+manual scanning'. The parenthetical about fallback behavior adds specificity.

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?

Provides clear context: 'Prefer over Read+manual scanning when you want to know what a function calls without reading the whole body'. This gives an explicit alternative and the condition selecting this tool. No explicit when-not-to-use, but strong positive guidance.

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