Expose an MCP tool for incremental index refresh

Author: dpearson2699Created Jun 13, 2026Updated Jun 13, 2026

Summary

@zilliz/[email protected] has an internal incremental refresh path, but MCP clients cannot call it directly.

Current state from the MCP implementation:

  • SyncManager.handleSyncIndex() calls Context.reindexByChange(...) for indexed codebases.
  • CLAUDE_CONTEXT_TRIGGER_WATCHER=true watches ~/.context/.sync-trigger, not the codebase directories themselves.
  • CLAUDE_CONTEXT_BACKGROUND_SYNC=false disables startup + periodic polling, so a multi-instance stdio setup needs an external hook to touch the trigger file.
  • The exposed MCP tools are currently index_codebase, search_code, clear_index, and get_indexing_status; none of those expresses “incrementally refresh this existing index now”.

Why this matters

For MCP clients such as Claude Code, Codex, Cursor, etc., freshness gates often need a deterministic, tool-callable path:

  1. check whether a repo is indexed
  2. refresh the existing index if it may be stale
  3. search with confidence that semantic results include recent changes

Right now, the client has to choose between:

  • enabling periodic background polling, which is noisy in multi-instance local stdio setups
  • touching ~/.context/.sync-trigger out of band, which is filesystem/client-specific and refreshes all tracked codebases
  • using index_codebase with force=true, which is a full/destructive reindex and not equivalent to incremental refresh

Proposal

Expose a normal MCP tool backed by the existing incremental sync code, for example:

typescript
sync_index({
  path: "/absolute/path/to/codebase", // optional? if omitted, sync all indexed codebases
  wait: true                           // optional; return after sync completes
})

Expected behavior:

  • call Context.reindexByChange(...) for the requested codebase path, or all indexed codebases if no path is provided
  • preserve existing request-level index options (splitter, customExtensions, ignorePatterns)
  • report stats such as { added, modified, removed }
  • use the same global sync lock that background/trigger sync already uses
  • avoid clear_index / force=true unless explicitly requested by the user

Docs clarification

The current trigger watcher docs are useful, but the setting name is easy to misread as “watch my project files”. It would help to state prominently that:

  • CLAUDE_CONTEXT_TRIGGER_WATCHER=true watches only ~/.context/.sync-trigger
  • it does not automatically watch or subscribe to file changes in every indexed codebase
  • clients/editors must touch the trigger file, or use periodic background sync, until a first-class MCP refresh tool exists

Related: #238

Source: zilliztech/claude-context