Skip to main content
Glama
bezata

kObsidian MCP

List Known Vaults

vault.list
Read-onlyIdempotent

List all known Obsidian vaults by scanning environment variables and the local Obsidian registry, merged and deduplicated. Optionally force a fresh scan with 'refresh: true'. Reports source, default, active, and existence status per vault.

Instructions

List every Obsidian vault kObsidian knows about, merged and deduplicated across three sources: the operator's OBSIDIAN_VAULT_PATH (the default — always included), any OBSIDIAN_VAULT_=path env vars (explicit named vaults), and — when KOBSIDIAN_VAULT_DISCOVERY is on (the default) — the user's local Obsidian application registry at obsidian.json. Each item reports its source, isDefault, isActive, and exists so the LLM can flag stale or missing vaults. Pass refresh: true to force a fresh scan instead of using the 30s cache. Read-only. NOTE: the obsidian-app source is EXPERIMENTAL — it parses Obsidian's undocumented obsidian.json registry (stable since 1.0 but internal to Obsidian) and may silently stop returning results if Obsidian changes the format; the env-var sources are the documented, stable path.

Examples:

Example 1 — List vaults using the 30-second cache:

{}

Example 2 — Force a rescan (obsidian.json changed, new env vars added):

{
  "refresh": true
}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
refreshNoWhen true, force a fresh scan of the filesystem and obsidian.json even if the cache is warm. Default false.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
totalYes
itemsYes
activeVaultIdYesId of the currently session-selected vault, or null when using the env default.
obsidianConfigPathYesPath to the obsidian.json file kObsidian successfully parsed, or null when no config file was found or discovery is disabled.
obsidianConfigErrorNoPresent only when obsidian.json was located but could not be parsed. The string names the failure reason for debuggability.
Behavior5/5

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

The description provides extensive behavioral details beyond annotations: it explains the three data sources, caching behavior (30s), the experimental nature of the obsidian-app source with a warning about potential silent breakage, and the fields reported for each item. This fully satisfies transparency without contradiction.

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 efficiently structured: a concise opening sentence, a detailed breakdown of sources and fields, followed by a note on caching and experimental risk, and two clear JSON examples. Every sentence contributes useful information without redundancy.

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?

Given the tool's complexity (multiple sources, caching, experimental component), the description is remarkably complete. It covers what each vault item contains, cache behavior, experimental warning, and provides usage examples. The presence of an output schema is complemented by the field descriptions in the text.

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?

The sole parameter 'refresh' is already described in the schema (100% coverage). The description adds value by explaining why one would use refresh (force fresh scan) and mentioning the cache fallback, which goes beyond the schema's default/type explanation.

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 clearly states it lists all Obsidian vaults known to kObsidian, merged and deduplicated from three specific sources. It distinguishes itself from sibling tools like vault.current and vault.select by focusing on enumeration rather than selection or status.

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?

The description explains when to use the tool (listing vaults) and provides examples for both cached and forced refresh usage. It lacks explicit exclusions or comparisons to alternatives, but the context of sibling tools and the clear purpose make usage guidelines clear.

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/bezata/kObsidian'

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