Skip to main content
Glama

bundle

Fetches a symbol's body, callers, callees, and similar matches—or full PR impact and project rankings—in one call, replacing four separate lookups.

Instructions

Multi-source bundle — replaces 4 round-trips (show → callers → callees → similar) with 1. Three modes: symbol (body + callers + callees + similar for a named symbol; ~10ms), pr-impact (changed symbols + transitive callers + tests for a git base ref; ~50ms), project (top-N symbols by reverse call-graph indegree; ~5ms). Prefer over chaining find_symbol/show/callers/callees when you need cross-section context on one symbol or a PR. Mode-specific args are validated server-side; only mode is universally required. Response shape is uniform — { protocol_version, capabilities, _meta, results: { mode, items[], mode_hints } }. Each items[i] carries 13.11 signals plus a role discriminator (body | caller | callee | similar | changed | transitive_caller | test | top). Scope filters (include / exclude / exclude_tests) apply only in pr-impact mode (changed files plus the caller and test rows); symbol and project modes ignore them.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
baseNo(mode: pr-impact) Git base revision to diff against (e.g. `origin/main`, `HEAD~3`, a SHA)
modeYesBundle assembly mode
depthNo(mode: pr-impact) Transitive callers walk depth
top_nNo(mode: project) Max number of top-ranked symbols
symbolNo(mode: symbol) Symbol name to resolve via the symbol FST
excludeNoBlacklist results by path glob; wins over include (repeatable)
includeNoWhitelist results by path glob (repeatable)
path_globNo(mode: project) Single path glob filter applied to ranked symbols (e.g. `src/**`); separate from the universal `include`/`exclude` arrays
tests_maxNo(mode: pr-impact) Max test-classified items
auto_updateNoAuto-update the index if stale, or bootstrap if missing, before running (default: true)
callees_maxNo(mode: symbol) Max direct callees
callers_maxNo(mode: symbol) Max direct callers
similar_maxNo(mode: symbol) Max semantic-similar matches; gated on `vex index --semantic`
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)
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.27.3

TDQS

A4.6/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 it delivers unusually rich context: per-mode latency, server-side arg validation, the uniform `{ protocol_version, capabilities, _meta, results }` envelope, the `role` discriminator values, and that scope filters only apply in pr-impact mode. The main gap is that it doesn't flag the state-changing side of auto_update/async_update (index refresh) or any 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.

Conciseness4/5

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

Dense and front-loaded: value proposition first, then modes, then response contract, then the filter-scope caveat. It is long, but every sentence carries information an agent needs; only the timing figures are marginally expendable.

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?

For a 17-parameter, three-mode tool with no output schema, the description compensates by documenting the response envelope, item structure, and role vocabulary. Combined with 100% schema coverage, an agent has what it needs to select a mode and call it correctly.

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 description coverage is 100% (baseline 3), and the description adds cross-parameter semantics the schema can't express well: which mode each argument belongs to and the fact that include/exclude/exclude_tests are ignored outside pr-impact. It doesn't add format examples beyond what the schema already supplies inline.

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 opening states a concrete verb+resource ('Multi-source bundle') and immediately frames it against the exact sibling tools it replaces (show → callers → callees → similar). The three modes are named and each is scoped to a distinct use case, so an agent can distinguish it from find_symbol, callers, callees, and similar without opening a 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?

It explicitly says 'Prefer over chaining find_symbol/show/callers/callees when you need cross-section context on one symbol or a PR,' giving both the alternative and the selecting condition. Mode-specific guidance (symbol = one symbol, pr-impact = a git base ref, project = ranked symbols) further routes the agent to the correct mode.

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