obsidian-mcp-pro

Overview Schema Source Related Servers Discussions Admin

Index Vault for Semantic Search

index_vault

Idempotent

Builds or refreshes the embedding index used by semantic search and similar-note lookup, processing notes in heading-aware chunks and skipping unchanged content.

Instructions

Build or refresh the embedding index used by search_semantic and find_similar_notes. Splits readable notes into heading-aware chunks, sends those chunks to the configured embedding provider (Ollama by default, OpenAI optional), and persists the index to <vault>/.obsidian/cache/mcp-pro-embeddings.json. Requires confirm: "send-vault-text-to-embedding-provider" so callers explicitly acknowledge that vault text will leave this tool boundary. Incremental: notes whose content hash matches the prior pass are skipped. Use force: true to re-embed everything (e.g., after switching models). Emits progress notifications when the client subscribes.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "index_vault"
  }
}

Input Schema

Name	Required	Description
`force`	No	If true, re-embed every note even if its content hash matches the cached one.
`folder`	No	Restrict the indexing pass to this folder. Notes outside the folder are left untouched.
`confirm`	No	Required safety latch. Set exactly to "send-vault-text-to-embedding-provider" to acknowledge that readable note chunks will be sent to the configured embedding provider.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv4.1.1Oct 24, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / confirm

Added value: +{
+  "const": "send-vault-text-to-embedding-provider",
+  "description": "Required safety latch. Set exactly to \"send-vault-text-to-embedding-provider\" to acknowledge that readable note chunks will be sent to the configured embedding provider.",
+  "type": "string"
+}

Addedv2.0.0May 24, 2026
Removedv1.9.0May 11, 2026
Addedv1.8.0May 6, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Goes well beyond annotations: discloses the exact cache file written, that vault text is sent to an external embedding provider, the required `confirm` safety latch for data leaving the tool boundary, hash-based skipping behavior, and progress notifications. These details let an agent reason about privacy, cost, and idempotency.

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

Conciseness4/5

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

Front-loads the core purpose, then layers in privacy, persistence, incrementality, and progress behavior. Sentences are dense with useful facts rather than filler, though the description is longer than strictly necessary for an expert agent.

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

Completeness4/5

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

Covers the important risks for a complex indexing tool: external data transmission, required confirmation, cache location, incremental behavior, and force re-embedding. It does not cover failure modes or the role of the `folder` scoping parameter, but the annotations and schema fill in the remaining structure.

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%, so the schema already documents all three parameters thoroughly. The description reinforces the purpose of `confirm` and gives an example for `force`, but the `folder` parameter is not mentioned and no syntax or format details are added 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?

States a specific verb and resource ('Build or refresh the embedding index') and explicitly names the sibling tools that consume it (`search_semantic` and `find_similar_notes`). An agent can immediately distinguish this maintenance operation from the search tools themselves.

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

Usage Guidelines4/5

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

Provides clear context: it is the index-builder behind the semantic search siblings, is incremental by design, and `force: true` is for re-embedding after switching models. It does not state explicit when-not-to-use conditions or concurrency caveats, but the intended usage is clear.

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