Skip to main content
← MCP Tools

get_index_status

Answer whether the graph is worth trusting right now: how fresh it is, how complete it is, and which parts of it are degraded. Every other tool answers a question about your code; this one answers a question about the index those answers came from.

Read-only.

Input schema​

{
  "type": "object",
  "properties": {},
  "required": [],
  "additionalProperties": false
}

No arguments in single-repo stdio mode. In global mode the tool accepts an optional repo to select one registered repo.

Output​

A JSON object covering four things:

  • Freshness. indexed_commit, head_commit, and a staleness block with behind_by, is_stale, and working_tree_dirty.
  • Size. counts.nodes and counts.edges, plus the store's schema_version.
  • Phase A / Phase B. phase_a.state, and phase_b with an overall state plus a per-language breakdown. A language can be done, pending, running, failed, or unavailable, and a degraded one carries a detail naming the remedy.
  • Semantic. Whether embeddings are ready, building, disabled, or in error, whether they are calibrated, and whether the reranker is installed.

is_stale is a tri-state​

is_stale can be true, false, or null. null means unknown, not fresh: git was unavailable, nothing has been indexed yet, or the indexed commit no longer resolves. Treating null as "fine" is the mistake the tri-state exists to prevent.

Absence is not health​

A language reporting unavailable has not failed. It means no analyzer is installed for it in this repo, so it will never produce semantic edges until one is, and detail says which command fixes that. Distinguishing "broken" from "never ran" is the whole point of the per-language breakdown, because they call for opposite responses.

When to use​

  • Before trusting an empty result. get_callers returning nothing means something different when Phase B for that language is unavailable.
  • Deciding whether to reindex. behind_by and working_tree_dirty tell you whether the graph describes the code you are looking at.
  • Polling for readiness after travsr init --semantic on a large repo.

Notes​

  • Available over both stdio and SSE.
  • Reads state only. It takes no lock, so calling it can never interfere with a running travsr daemon start.
  • The CLI equivalent is travsr status, which reports the same underlying state in a form meant for people.