Skip to main content
Glama

history

Trace every historical version of a code symbol to inspect signature or body changes over time, find when a bug was introduced, or recover a deleted symbol.

Instructions

Every historical version of a symbol reachable from a chosen tip. With vex index --history previously run, queries hit a persistent FST sidecar (~ms); without it, shells out to git log (~seconds). Indexed mode also finds symbols whose name has been DELETED from HEAD — the walker can't. Use this to inspect how a function's body / signature changed over time, find when a bug was introduced, or recover a deleted symbol's last definition. NOTE: omitting limit returns the full history (walker mode is unbounded by default — set limit to cap latency on long-lived repos). exact_presence: true adds seconds-scale latency per file — only pass when you specifically need the exact commit set, not the convex-hull span. v1.20.0 (D5) surface — the CLI subcommand has existed since v1.15.0 but was MCP-invisible.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
diffNoRender unified diffs between consecutive historical versions of the same `(symbol, kind)` pair instead of repeating the full body for each entry. Cuts output noise on deep histories. Mutually exclusive with `exact_presence`.
kindNoKeep only entries whose symbol kind matches exactly (lowercase: `function` / `struct` / `impl` / …).
nameNoDEPRECATED alias for `symbol`; still accepted, emits a deprecated_args notice in _meta.
depthNoMax commits to walk per file (walker mode). Unbounded by default; bump down on long-lived repos to keep latency in check.
limitNoCap the total result set. Omit for unbounded (walker mode) — set explicitly on long-lived repos to keep latency in check. The walker stops as soon as the limit is reached.
sinceNoKeep only entries whose commit date is `>= YYYY-MM-DD` (inclusive).
untilNoKeep only entries whose commit date is `<= YYYY-MM-DD` (inclusive).
authorNoKeep only entries whose commit author contains this substring (case-insensitive). Walker-only — the indexed path rejects this with an error pointing at `no_index: true`.
branchNoRestrict the walk to this revision (`refs/heads/foo`, `origin/main`, a SHA). Defaults to `HEAD`.
symbolYesSymbol name to walk through history. Matched whole-word via `git grep --word-regexp`, then filtered post-parse to exact `name == query`.
no_indexNoForce the v1.16 query-time walker even when a `git_history` section is present. Default (`HistoryMode::Auto`) picks the indexed path when available and falls back to the walker otherwise. Use for regression-checking the walker against the indexed path.
project_rootNoAbsolute path to the project root (defaults to the MCP working directory)
exact_presenceNoFor each entry, list the exact set of commits where its blob lived in the file. Defeats the convex-hull span representation (LIMITATIONS §4c #4). Adds latency.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.27.3

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it distinguishes indexed FST (~ms) vs walker (`git log`, ~seconds) modes, discloses that indexed mode finds deleted symbols while the walker cannot, warns that omitting `limit` is unbounded, notes `exact_presence` latency, and explains `no_index` for regression checking. Missing only auth/permission context, which is minor here.

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-loaded with scope and then performance/mode tradeoffs; most sentences earn their place. Slight redundancy – the unbounded-latency warning appears both in the description prose and in the `limit`/`depth` schema descriptions – keeps it from a 5.

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?

No output schema and no annotations, with 13 parameters, so the description must carry a lot, and it does: modes, latency, correctness differences, and history/version provenance. It stops short of describing the returned entry shape (versions, spans, convex-hull representation), which would help given the absent output schema.

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 value beyond the schema: the default-unbounded behavior of `limit`, the per-file latency of `exact_presence`, and the cross-parameter note that `diff` and `exact_presence` are mutually exclusive. It reinforces rather than repeats structured data.

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 scope: 'Every historical version of a symbol reachable from a chosen tip.' It is clearly distinguishable from siblings like `find_symbol`, `diff`, or `callers`, and the extra sentence about deleted symbols sharpens exactly what makes this tool unique. An agent can route to it without opening the schema.

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 three concrete use cases (inspect body/signature change over time, find when a bug was introduced, recover a deleted symbol's last definition) and conditions for latency-sensitive flags. It does not name a sibling alternative to prefer, e.g. when `diff` or `find_symbol` would be the better call, so it stops short of a 5.

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