codesteer-atlas

Overview Schema Source Related Servers Discussions Admin

atlas_status

Inspect local vector index health, staleness, and indexed repos/languages to diagnose search problems and decide if a reindex is needed.

Instructions

Get diagnostic metadata and health status of the local vector index.

Use this only for explicit diagnostics (e.g. the user asks about index health, staleness, or which repos/languages are indexed) or to decide whether atlas_index should be run. It is NOT a precondition for atlas_search/atlas_brief — call those directly; they raise an actionable error themselves if the index is missing. Never indexes anything itself.

Returns: JSON string with index_exists, total_chunks, repos_indexed, languages_indexed, embedding_model, embedding_backend, storage_backend, index_path, index_resolution (how the index directory was resolved: "cli-arg" | "env" | "discovery" | "editor-project-dir" | "roots" | "roots-fallback" | "editor-project-dir-fallback" | "cwd-fallback" — useful to diagnose client misconfiguration when index_exists is unexpectedly false), last_indexed_at, git_head_sha, is_stale (true when the indexed git HEAD differs from the workspace's current HEAD), and reindexing (true when another process currently holds the reindex lock for this index).

Also `resolution_coverage`: which languages had their imports resolved and
how. Either `{scip: [...], treesitter: [...], none: [...], files_unresolved: N}`
— each language in exactly one tier, `none` meaning "indexed and searchable,
but mute about how it connects" — or `{status: "unknown", reason:
"index_version_below_2_2_0"}` for an index built before 2.2.0. Never trust an
absent tier as "nothing to resolve".

And `watch`: whether this server is watching the workspace for changes —
"active" (watching; edits trigger an incremental reindex after a debounce),
"disabled" (ATLAS_WATCH not set — the default), "unavailable" (ATLAS_WATCH
set but the optional `watchdog` dependency is not installed) or "failed"
(the observer could not start; see stderr). Only "active" means the index
keeps itself current while the server runs.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.4.3Aug 5, 2026
Removedv1.4.2Jul 22, 2026
First observedv1.0.0Jun 10, 2026

TDQS

A4.7/5.0

Behavior5/5

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

No annotations exist, and the description carries the full burden well: it discloses non-mutation ('Never indexes anything itself'), lock contention ('reindexing'), staleness semantics, watch states with their triggering env vars and failure modes, and index-resolution provenance. These are behavioral traits an agent cannot derive from structured fields.

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

Conciseness3/5

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

The usage guidance is front-loaded and every clause there earns its place, but the Returns section is long and largely restates the output schema — the rubric notes this is unnecessary when an output schema exists. The interpretive notes on 'index_resolution', 'resolution_coverage', and 'watch' add real value, so it is not pure bloat, but the block is disproportionately verbose.

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?

An output schema exists, so return values need not be enumerated, yet the description is complete: an agent knows exactly when to call it, that it is read-only and side-effect free, and how to interpret the ambiguous fields. Nothing needed to call it correctly is missing.

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?

There are zero input parameters, so per the rubric this is a baseline 4; there is nothing for the description to add or omit.

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 and resource ('Get diagnostic metadata and health status of the local vector index') and immediately distinguishes itself from siblings by declaring it is NOT a precondition for atlas_search/atlas_brief and does NOT index, unlike atlas_index.

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?

Gives explicit when-to-use (user asks about health/staleness/indexed repos, or deciding whether to run atlas_index) and explicit when-not (not a precondition for search/brief; call those directly). Alternatives are named with the reason they should be preferred.

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

Deploy Server