Skip to main content
Glama
tenatarika

vex

by tenatarika
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

paths

Enumerate every caller chain from a starting function to a destination function in a persistent call graph, multi-hop up to six, in one response.

Instructions

Enumerate every caller chain from from to to in the persistent call graph (multi-hop, max 6 by default). Prefer over repeated callers calls when you need to know how a function gets reached from a known entry point — paths walks the edges itself in a single response. Requires a v4 index with call graph (built without --no-call-graph).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toYesExact name of the destination function (callee being investigated).
fromYesExact name of the starting function (caller / entry point).
excludeNoBlacklist intermediate steps by path glob; wins over include (repeatable)
includeNoWhitelist intermediate steps by path glob, gitignore syntax (repeatable)
max_hopsNoMaximum hops between from and to
max_pathsNoMaximum paths to enumerate (caps output, aborts traversal early)
auto_updateNoAuto-update the index if stale, or bootstrap it if missing, before running (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)
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.2/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does disclose a meaningful behavioral prerequisite: it requires a v4 index built with call graph, and it notes that paths walks the edges itself in a single response rather than requiring repeated calls. It does not explicitly state read-only safety or describe the return shape, but the prerequisites and execution model are covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Three sentences, front-loaded with the core action, then the sibling comparison, then the prerequisite. Every sentence earns its place with no filler.

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 read-only traversal tool with no output schema, the description covers purpose, the sibling alternative, and the index prerequisite well. It could briefly state what the response contains (the enumerated chains), but the essential call-time information is present.

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%, so every one of the 11 parameters is already documented in the schema (including the auto_update/staleness and exclude_tests nuances). The description only restates the max_hops default of 6, adding no semantics beyond the schema, so the baseline 3 applies.

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 (enumerate) and resource (every caller chain from `from` to `to`) with scope qualifiers (multi-hop, max 6 by default). An agent can immediately distinguish this from siblings like callers, callees, and reachable.

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?

Explicitly names the alternative ('Prefer over repeated `callers` calls') and the condition that selects it (when you need to know how a function gets reached from a known entry point), plus a prerequisite (v4 index with call graph). It stops short of stating when NOT to use it, e.g. relative to reachable or impact.

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