Skip to main content
Glama
pvliesdonk

markdown-vault-mcp

by pvliesdonk
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Hybrid

Reindex Vault

reindex
Idempotent

Refresh the index after external file changes; hash-based detection re-parses only modified files. Use force=True only to rebuild the entire vault when index content is out of sync.

Instructions

Run an incremental reindex on the writer thread.

Only needed when files are modified outside this server — for example, by a text editor, a sync tool, or another process writing directly to the vault directory. Do NOT call this after using 'write', 'edit', 'delete', or 'rename' — those tools update the index immediately as part of the operation.

Change detection is hash-based, so an unchanged file is never re-parsed. Use force=True to drop the index and re-parse every file regardless of hashes — the repair for index content that no longer matches what the current server would extract. A version upgrade that changes extraction does this by itself on the next start (#1124), so force=True is a manual escape hatch, not routine maintenance. When semantic search is configured, follow a force=True run with 'build_embeddings' (without force) so the vector index converges to the rebuilt chunk set; an ordinary reindex re-embeds as it goes.

To rebuild all embeddings from scratch (e.g. after changing the embedding model), use 'build_embeddings' with force=True.

A fast reindex (the common case — work scales with the drift, not the vault) returns its result inline. A reindex still running at the server's soft deadline continues in the background and returns {"status": "working", "job_id": ...} immediately — fetch the outcome with get_job_result. get_index_status remains the observability view of the index (it also covers boot-time builds and file-watcher reindexes no client call initiated).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
forceNoWhen True, drop every indexed document and re-parse the whole vault instead of applying the hash-detected delta. The index is not queryable while the rebuild runs, and the cost scales with the vault rather than the drift, so prefer the default.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changedv4.0.0
    • 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"
+}
  2. First observedv3.1.0

TDQS

A5/5.0
Behavior5/5

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

The description adds substantial behavioral detail beyond the annotations: hash-based change detection, background execution with job_id, index unavailability during force rebuilds, and the relationship with embedding convergence. It also clarifies that force=True is a 'manual escape hatch, not routine maintenance,' which is exactly the kind of judgment context an agent needs. No contradiction with the idempotentHint or destructiveHint annotations.

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 long but every sentence carries operational weight. It front-loads the core purpose immediately and organizes the rest by when-to-use, when-not-to-use, force semantics, follow-up actions, and response behavior. Nothing feels redundant or promotional.

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 tool with one optional parameter, the description fully covers the common path, the force edge case, background job behavior, and how to retrieve results. It also explains the relationship to get_index_status and build_embeddings, so an agent can handle the complete workflow without guessing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the schema already documents the force parameter at 100% coverage, the description goes further by explaining the trade-offs of force=True: it drops every indexed document, re-parses the whole vault, makes the index unqueryable during the rebuild, and scales cost with vault size. It also tells the agent to follow force=True with build_embeddings in semantic-search setups. This adds real decision-making value 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 opens with a specific verb and resource: 'Run an incremental reindex on the writer thread.' It clearly distinguishes reindex from sibling tools like build_embeddings and get_index_status by explaining what reindex does versus what those tools handle. Even without knowing the siblings, an agent understands this is an index-refresh operation.

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?

The description explicitly states when reindex is needed ('files modified outside this server') and when it is not ('Do NOT call this after using write, edit, delete, or rename'). It also routes the agent to alternatives: build_embeddings for embedding rebuilds, get_job_result for background outcomes, and get_index_status for observability. This is exceptional usage guidance.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/pvliesdonk/markdown-vault-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server