markdown-vault-mcp

Reindex Vault

reindex

Idempotent

Update the search index for notes changed outside this server, such as by editors or sync tools, and return counts of added, modified, deleted, and unchanged notes.

Instructions

Bring the search index up to date with files changed outside this server, such as by an editor or a sync tool; returns counts of added, modified, deleted and unchanged notes.

Writes through this server's tools update the index themselves, so do not call it after them.

Input Schema

Name	Required	Description	Default
`force`	No	Drop the index and re-parse every note instead of only changed ones: slower, and search waits until it finishes. Use it when results no longer match the notes, then run build_embeddings if the vault has semantic search. Default false.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv6.1.0Nov 2, 2026

changedInput schema / properties / force / description

Previous value: -"When True, drop every indexed document and re-parse the\nwhole vault instead of applying the hash-detected delta.\nThe index is not queryable while the rebuild runs, and the\ncost scales with the vault rather than the drift, so prefer\nthe default."New value: +"Drop the index and re-parse every note instead of only changed ones:\nslower, and search waits until it finishes. Use it when results no\nlonger match the notes, then run build_embeddings if the vault has\nsemantic search. Default false."

Changed1 schema field changedv4.0.0Aug 26, 2026

addedInput schema / properties / force

Added value: +{
+  "default": false,
+  "description": "When True, drop every indexed document and re-parse the\nwhole vault instead of applying the hash-detected delta.\nThe index is not queryable while the rebuild runs, and the\ncost scales with the vault rather than the drift, so prefer\nthe default.",
+  "type": "boolean"
+}

First observedv3.1.0Jul 8, 2026

TDQS

A4.5/5.0

Behavior4/5

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

The annotations already declare that this is a non-read-only, idempotent, non-destructive operation. The description adds meaningful behavior: it exists for out-of-band changes, internal writes already update the index, and it returns added/modified/deleted/unchanged counts. It does not discuss force-reindex cost or search blocking, but those are covered in the parameter schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short paragraphs and front-loads the trigger condition. The second paragraph earns its place by preventing redundant calls after server-side writes.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single optional parameter, an output schema, and clear annotations, the description supplies the key missing context: external-change use case and the exclusion for internal writes. The remaining force-reindex details are fully handled by the schema.

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 coverage is 100%, and the single force parameter is thoroughly documented in the schema, including its default, cost, blocking effect, and follow-up embedding step. The description itself does not mention force, so it adds no parameter meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: bringing the search index up to date. It also scopes the operation to files changed outside this server, which distinguishes it from index updates performed by write tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says when to use the tool (after external edits or sync changes) and when not to use it (after writes through this server, because those update the index themselves). This is clear routing guidance with no ambiguity.

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