semantic-code-mcp

Overview Schema Source Related Servers Discussions Admin

index_status

Check a project's code index status to verify indexing state, last update time, file and chunk counts, vector coverage, and any active indexing run.

Instructions

Get the index status for a project.

Returns whether the project is indexed, when it was last updated, how many of its Python, Rust and Markdown files and their chunks are indexed, how many chunks have the model's vectors, how many files changed since, what built the index (each chunker version keeps an index of its own, and each model's vectors are kept apart in it), and whether a run, this session's or another's, holds it now, so its counts may be what the run has written so far.

Note: search_code automatically re-indexes stale files before searching, so there is no need to check or act on staleness manually.

Args: project_path: Absolute path to the project; a directory inside a git repository reports the whole repository's index, unless the repository ignores it or holds the user's home directory. Left out, the client's workspace root, which must lie in a git repository.

Returns: The root of the project whose index this is, and its status, including the counts of files and chunks.

Input Schema

Name	Required	Description	Default
`project_path`	No	Absolute path to the project, or to a directory inside its git repository. Left out, the client's workspace root: the directory Claude Code was started in, which must lie in a git repository.

Output Schema

Name	Required	Description
`model`	Yes
`manifest`	Yes
`is_indexed`	Yes
`being_built`	Yes	A run holds the index now, this session's or another's, and may be writing it: until it ends, the counts may be what it has written so far; a search waits for it.
`files_count`	Yes
`chunks_count`	Yes
`last_updated`	Yes
`project_root`	Yes	The root of the project whose index this is: a directory inside a git repository is indexed, and reported, with its whole repository.
`stale_files_count`	Yes
`embedded_chunks_count`	Yes	How many of the chunks have the server's model's vectors; a server set to search by meaning too embeds the rest before it answers.

Schema Changelog

Changes observed during successful MCP inspections.

Changed23 schema fields changedv0.5.0Nov 4, 2026

addedInput schema / properties / project_path / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / project_path / default
```
Added value: +null
```

addedInput schema / properties / project_path / description

Added value: +"Absolute path to the project, or to a directory inside its git repository. Left out, the client's workspace root: the directory Claude Code was started in, which must lie in a git repository."

removedInput schema / properties / project_path / type
```
Removed value: -"string"
```
removedInput schema / required
```
Removed value: -[
-  "project_path"
-]
```

removedOutput schema / $defs / ErrorResponse

Removed value: -{
-  "description": "Error response for tool failures.",
-  "properties": {
-    "error": {
-      "title": "Error",
-      "type": "string"
-    }
-  },
-  "required": [
-    "error"
-  ],
-  "title": "ErrorResponse",
-  "type": "object"
-}

addedOutput schema / $defs / IndexManifestView

Added value: +{
+  "description": "What built an index: its chunker and the store's schema, each of whose versions keeps\nan index of its own.",
+  "properties": {
+    "chunker_version": {
+      "title": "Chunker Version",
+      "type": "integer"
+    },
+    "schema_version": {
+      "title": "Schema Version",
+      "type": "integer"
+    }
+  },
+  "required": [
+    "chunker_version",
+    "schema_version"
+  ],
+  "title": "IndexManifestView",
+  "type": "object"
+}

removedOutput schema / $defs / IndexStatusResponse

Removed value: -{
-  "description": "Response from index_status tool.",
-  "properties": {
-    "chunks_count": {
-      "title": "Chunks Count",
-      "type": "integer"
-    },
-    "files_count": {
-      "title": "Files Count",
-      "type": "integer"
-    },
-    "is_indexed": {
-      "title": "Is Indexed",
-      "type": "boolean"
-    },
-    "last_updated": {
-      "anyOf": [
-        {
-          "type": "string"
-        },
-        {
-          "type": "null"
-        }
-      ],
-      "title": "Last Updated"
-    }
-  },
-  "required": [
-    "is_indexed",
-    "last_updated",
-    "files_count",
-    "chunks_count"
-  ],
-  "title": "IndexStatusResponse",
-  "type": "object"
-}

addedOutput schema / $defs / ModelView

Added value: +{
+  "description": "The model a search by meaning embeds with, whose vectors `embedded_chunks_count`\ncounts: the index keeps each model's vectors apart.",
+  "properties": {
+    "embedder_version": {
+      "title": "Embedder Version",
+      "type": "integer"
+    },
+    "model_name": {
+      "title": "Model Name",
+      "type": "string"
+    },
+    "model_revision": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "title": "Model Revision"
+    }
+  },
+  "required": [
+    "model_name",
+    "model_revision",
+    "embedder_version"
+  ],
+  "title": "ModelView",
+  "type": "object"
+}

addedOutput schema / description

Added value: +"The answer of `index_status`."

addedOutput schema / properties / being_built

Added value: +{
+  "description": "A run holds the index now, this session's or another's, and may be writing it: until it ends, the counts may be what it has written so far; a search waits for it.",
+  "title": "Being Built",
+  "type": "boolean"
+}

addedOutput schema / properties / chunks_count

Added value: +{
+  "title": "Chunks Count",
+  "type": "integer"
+}

addedOutput schema / properties / embedded_chunks_count

Added value: +{
+  "description": "How many of the chunks have the server's model's vectors; a server set to search by meaning too embeds the rest before it answers.",
+  "title": "Embedded Chunks Count",
+  "type": "integer"
+}

addedOutput schema / properties / files_count

Added value: +{
+  "title": "Files Count",
+  "type": "integer"
+}

addedOutput schema / properties / is_indexed

Added value: +{
+  "title": "Is Indexed",
+  "type": "boolean"
+}

addedOutput schema / properties / last_updated

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "title": "Last Updated"
+}

addedOutput schema / properties / manifest

Added value: +{
+  "anyOf": [
+    {
+      "$ref": "#/$defs/IndexManifestView"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

addedOutput schema / properties / model

Added value: +{
+  "$ref": "#/$defs/ModelView"
+}

addedOutput schema / properties / project_root

Added value: +{
+  "description": "The root of the project whose index this is: a directory inside a git repository is indexed, and reported, with its whole repository.",
+  "title": "Project Root",
+  "type": "string"
+}

removedOutput schema / properties / result

Removed value: -{
-  "anyOf": [
-    {
-      "$ref": "#/$defs/IndexStatusResponse"
-    },
-    {
-      "$ref": "#/$defs/ErrorResponse"
-    }
-  ],
-  "title": "Result"
-}

addedOutput schema / properties / stale_files_count

Added value: +{
+  "title": "Stale Files Count",
+  "type": "integer"
+}

changedOutput schema / required

Previous value: -[
-  "result"
-]New value: +[
+  "project_root",
+  "is_indexed",
+  "last_updated",
+  "files_count",
+  "chunks_count",
+  "embedded_chunks_count",
+  "model",
+  "stale_files_count",
+  "manifest",
+  "being_built"
+]

changedOutput schema / title

Previous value: -"index_statusOutput"New value: +"IndexStatusResponse"

First observedv0.1.0Feb 21, 2026

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations, the description carries the full load and does substantial work: it explains that each chunker version keeps its own index slice, that each model's vectors are stored separately, and that an in-flight run (this session's or another's) can make reported counts a partial snapshot. That concurrency caveat is exactly the kind of behavior an agent cannot infer from a schema. It never states outright that the call is a side-effect-free read, which is why it stops short of a 5.

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 core purpose and the staleness note are front-loaded, which is good, but the prose is dense and long for a single optional parameter. The Args block largely restates the schema description and the Returns block restates information that the output schema already supplies, so a meaningful share of the text does not earn its place.

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 one-optional-parameter read tool with an output schema and no annotations, the description covers what the call does, the argument's path-resolution edge cases, and concurrent-run semantics. The only real gap is return-value framing, which the output schema already handles, making the verbose Returns paragraph redundant rather than missing.

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 the parameter is already documented and the baseline is 3. The description does add nuance beyond the schema text: the git-repository promotion rule, the exception for ignored directories and the user's home directory, and the workspace-root default. That is a modest addition over an already-complete schema, so it lands at the baseline rather than above it.

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?

"Get the index status for a project" pairs a specific verb with a specific resource, and the enumeration of what the status contains (indexed flag, last update, per-language file/chunk counts, vector coverage, changed files, chunker/model partitioning, active run) removes any ambiguity about what "status" means. It distinguishes itself from search_code via the staleness note, but never mentions the sibling index_codebase, so the read-vs-write split with that tool is left implicit.

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?

Contains an explicit when-not-to-use: staleness should not be checked or acted on manually because search_code re-indexes automatically. That is real routing guidance an agent could otherwise get wrong. What is missing is a positive statement of the scenario that does warrant this call (diagnostics, verifying an index_codebase run finished) rather than a pointer to the indexing sibling.

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

Deploy Server