Skip to main content
Glama
tenatarika

vex

by tenatarika
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

show

Extract full source bodies for one or more named symbols to get exact definitions without reading entire files; pass multiple names in one call to save tokens.

Instructions

Extract the full source body of one or more symbols by name (function, class, struct, etc.) using cached symbol byte-offsets (~4ms per symbol). Prefer over Read when you need a specific definition — show returns just that body, while Read pulls the entire file (often 10-100x more tokens). Accepts an array, so a single call replaces several Read calls. Phase 13.3 truncation: signature_only (signature line only), head (first N body lines), no_body (signature + leading doc only), collapsed (collapse nested methods — v1.9 NO-OP). Also supports filter (substring path filter), kind (kind-restrict), context_path (proximity hint), and no_stale_check.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
headNoPhase 13.3: print only the first N body lines and append `... (M more lines)`. Mutually exclusive with `signature_only`, `no_body`, `collapsed`.
kindNoBoost results matching one or more kinds (repeatable). Same vocabulary as `search.kind`.
limitNoMax bodies returned per symbol name (handles overloads / duplicates)
symbolNoDEPRECATED — use `symbols: [name]`. Pre-v1.7 singular alias, still accepted; emits a deprecated_args notice in _meta.
excludeNoBlacklist results by path glob; wins over include (repeatable)
includeNoWhitelist results by path glob, gitignore syntax (repeatable)
no_bodyNoPhase 13.3: print signature + leading docstring only; drop the body. Mutually exclusive with `signature_only`, `head`, `collapsed`.
symbolsYesExact symbol names to extract — canonical key (v1.7+). Pass the array form even for a single symbol.
collapsedNoPhase 13.3: collapse nested methods inside a class/impl/module. v1.9 NO-OP (flag-shape stable; emits a stderr warning). Mutually exclusive with `signature_only`, `head`, `no_body`.
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`.
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)
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.
signature_onlyNoPhase 13.3: print only the signature line(s). Mutually exclusive with `head`, `no_body`, `collapsed`.

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 are provided, so the description carries the full burden, and it does substantial work: it discloses the ~4ms-per-symbol cost model, the 10-100x token advantage, the truncation modes with their mutual-exclusivity rules, and the deprecated-flag behavior surfaced in the schema. It never explicitly states the operation is read-only and non-mutating, which an agent would still want confirmed.

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 value proposition (extract symbol body, fast, cheaper than Read) before listing the optional knobs. It is dense and mostly waste-free, though the long final sentence stacking several flags reads as a run-on and could be broken up.

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 17-parameter tool with no output schema and no annotations, the description covers usage, cost model, staleness handling, and mode semantics well. It stops short of describing the return shape or what happens when a requested symbol name is not found, which are the remaining gaps an agent would care about.

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%, so a baseline of 3 is warranted, but the description adds real meaning on top: it groups and explains the Phase 13.3 truncation modes (signature_only, head, no_body, collapsed), notes that collapsed is a v1.9 NO-OP, and characterizes filter, kind, context_path, and no_stale_check in prose the schema only states tersely.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and resource — 'Extract the full source body of one or more symbols by name (function, class, struct, etc.)' — with a mechanism (cached symbol byte-offsets) that makes the operation unambiguous. It sharply separates itself from Read, but does not differentiate against the other listed siblings such as find_symbol, outline, or search, so it falls short of the top mark.

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?

Gives an explicit when-to-use rule: 'Prefer over Read when you need a specific definition.' It also explains the batching rationale (a single array call replaces several Read calls). It offers no when-not-to-use conditions or routing toward find_symbol/outline siblings, so it is clear context without exclusions.

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