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:
- check whether a repo is indexed
- refresh the existing index if it may be stale
- 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
Summary
@zilliz/claude-context-mcp@0.1.14has an internal incremental refresh path, but MCP clients cannot call it directly.Current state from the MCP implementation:
SyncManager.handleSyncIndex()callsContext.reindexByChange(...)for indexed codebases.CLAUDE_CONTEXT_TRIGGER_WATCHER=truewatches~/.context/.sync-trigger, not the codebase directories themselves.CLAUDE_CONTEXT_BACKGROUND_SYNC=falsedisables startup + periodic polling, so a multi-instance stdio setup needs an external hook to touch the trigger file.index_codebase,search_code,clear_index, andget_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:
Right now, the client has to choose between:
~/.context/.sync-triggerout of band, which is filesystem/client-specific and refreshes all tracked codebasesindex_codebasewithforce=true, which is a full/destructive reindex and not equivalent to incremental refreshProposal
Expose a normal MCP tool backed by the existing incremental sync code, for example:
Expected behavior:
Context.reindexByChange(...)for the requested codebase path, or all indexed codebases if no path is providedsplitter,customExtensions,ignorePatterns){ added, modified, removed }clear_index/force=trueunless explicitly requested by the userDocs 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=truewatches only~/.context/.sync-triggerRelated: #238