Incrementally indexes Antigravity brain transcripts and Markdown artifacts into SQLite WAL with FTS5, avoiding full re-indexing and enabling cross-conversation BM25 search.
Incrementally index Antigravity brain transcripts and Markdown artifacts into SQLite WAL + FTS5.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | Force full re-index of all transcripts even if unchanged. |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose key traits: it mutates persistent state (SQLite WAL + FTS5), it is incremental by default, and unchanged transcripts are skipped unless forced. It does not cover permissions, concurrency/locking, whether the index is created if absent, or what a run returns or does on failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the incremental-vs-full distinction is stated first. It is efficient, though the storage-mechanism detail ('SQLite WAL + FTS5') is close to implementation trivia for an agent deciding whether to call it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No annotations and no output schema, so the description should say more about a mutating indexer: refresh cost, failure behavior, and the relationship to the search/session tools that consume this index. What it does say is accurate and sufficient to identify the tool, but not enough to call it confidently in edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter 'force' is fully documented there, so the schema does the work. The description only reinforces the default behavior (incremental) against which 'force' is contrasted, adding no new syntax or format detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (incrementally index) and its resources (Antigravity brain transcripts and Markdown artifacts) plus the destination (SQLite WAL + FTS5). It is clearly a write/index operation, distinguishable in kind from the read-oriented siblings (search, digest, health_report), though it never names them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Incrementally' implies this is the routine refresh path and that calling it repeatedly is cheap, which is useful implied guidance. But there is no explicit statement of when to run it (e.g. before agy_brain_search returns fresh results) or when to prefer force over the default, leaving the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.