kObsidian MCP

Rebuild Wiki Index

wiki.indexRebuild

DestructiveIdempotent

Rebuild wiki/index.md from a fresh scan of Sources, Concepts, and Entities, grouping pages by category and alphabetically. Replaces the index body; use after bulk page creation or when lint reports indexMismatch.

Instructions

Regenerate wiki/index.md from a fresh scan of Sources/, Concepts/, and Entities/. Pages are grouped by category and sorted alphabetically; pass includeCounts:true to render counts on the section headings (e.g. ## Sources (12)). Idempotent and destructive — the existing index.md body is replaced wholesale, so any hand-edits there are lost. Use after bulk-creating pages outside the wiki tools, or as the cleanup step after wiki.lint reports indexMismatch. For incremental upkeep on a single source, prefer the proposedEdits returned by wiki.ingest instead.

Operates on the session-active vault (see vault.current — selectable via vault.select) unless an explicit vaultPath argument is passed, which always wins.

Examples:

Example 1 — Plain rebuild.:

{}

Example 2 — Rebuild with counts on each section heading.:

{
  "includeCounts": true
}

Input Schema

TableJSON Schema

Name	Required	Description
`wikiRoot`	No	Per-call wiki directory override.
`vaultPath`	No	Per-call vault override.
`includeCounts`	No	When true, append per-category counts (e.g. `Sources (12)`) to each section heading. Defaults to false.

Output Schema

TableJSON Schema

Name	Required	Description
`target`	Yes	The path or identifier the tool acted on.
`changed`	Yes	True if the tool altered vault state on this call; false if it was a no-op.
`summary`	Yes	Short human-readable summary of what happened.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.3.5Aug 26, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

Changed3 schema fields changedv0.3.2May 9, 2026

addedInput schema / properties / includeCounts / description

Added value: +"When true, append per-category counts (e.g. `Sources (12)`) to each section heading. Defaults to false."

addedInput schema / properties / vaultPath / description
```
Added value: +"Per-call vault override."
```
addedInput schema / properties / wikiRoot / description
```
Added value: +"Per-call wiki directory override."
```

Changed4 schema fields changedv0.1.2Apr 25, 2026

addedOutput schema / description

Added value: +"Standard mutation envelope. Individual tools may attach additional fields (e.g. `created`, `appended`, `before`/`after` counts) — those are documented in the tool description."

addedOutput schema / properties / changed / description

Added value: +"True if the tool altered vault state on this call; false if it was a no-op."

addedOutput schema / properties / summary / description

Added value: +"Short human-readable summary of what happened."

addedOutput schema / properties / target / description

Added value: +"The path or identifier the tool acted on."

First observedv0.1.0Apr 24, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Description discloses that the operation is destructive, replacing the existing `index.md` body wholesale and losing hand-edits, which complements the destructiveHint and idempotentHint annotations. It also adds useful behavioral context about grouping, sorting, and vault resolution beyond the 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?

Well-structured with purpose first, then side effects, usage guidance, vault behavior, and minimal examples. Every section earns its place without unnecessary filler.

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 destructive rebuild tool, this covers all essential operational context: target file, scan sources, side effects, when to use, alternatives, and vault selection. The output schema is present, so return-value details are not needed in the description.

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

Parameters4/5

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

Input schema already covers all three parameters with descriptions, so the baseline is 3. The description adds value by explaining that `vaultPath` always wins over the active vault and by demonstrating `includeCounts` behavior with concrete examples.

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: Regenerate `wiki/index.md` from a fresh scan of `Sources/`, `Concepts/`, and `Entities/`. It clearly distinguishes this full rebuild from incremental tools like `wiki.ingest` and from linting with `wiki.lint`. No ambiguity about what the tool does.

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?

Explicitly says when to use: after bulk-creating pages outside the wiki tools, or as the cleanup step after `wiki.lint` reports `indexMismatch`. It also names the preferred alternative for incremental upkeep (`wiki.ingest`) and clarifies the vault selection behavior with `vaultPath` precedence.

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

Deploy Server