Skip to content

Expose an MCP tool for incremental index refresh #394

Description

@dpearson2699

Summary

@zilliz/claude-context-mcp@0.1.14 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:

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions