Vault Cortex Obsidian MCP Server

List Property Keys

vault_list_property_keys

Read-onlyIdempotent

Discover every property key in an Obsidian vault, with note counts and sample values, without opening notes. Use it to orient yourself before searching notes by property.

Instructions

Discover all property keys in the vault with note counts and sample values, without reading individual notes.

Example: vault_list_property_keys() returns [{ key: "tags", count: 342, sample_values: ["session-log", "project"] }, ...] Example: vault_list_property_keys({ folder: "Projects" }) — the keys used under Projects/ only

When to use: Discovering what properties exist before searching by property. Good first step for vault orientation alongside vault_list_tags. Prefer vault_list_property_values when you need the full list of values for a specific key. Prefer vault_search_by_property to find notes matching a specific key-value pair.

Parameters:

folder names a whole folder, subfolders included: "Projects" covers "Projects/Archive" but not "ProjectsOld/", ignoring ASCII letter case; omit it to scan the entire vault.

Behavior: Results can lag a file change by a few seconds.

Only properties count; inline Dataview fields (key:: value) are not listed.
count is the number of notes that have the key, including notes where its value is empty (null).
sample_values are the key's 3 most frequent values as text (a number as JavaScript prints it, so 1.0 lists as "1"; a checkbox as "1" or "0"), counting each array element separately; null values are skipped.

Errors:

An empty vault or folder returns an empty array, not an error.
"[SqliteError]: …" — the index failed, not the call; the message says what to do

Returns: JSON array of { key, count, sample_values } sorted by count descending, then by key.

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": "vault_list_property_keys"
  }
}

Input Schema

Name	Required	Description	Default
`folder`	No	Restrict to a folder (e.g. "Projects")

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.54.16Oct 22, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
Addedv0.32.1Jul 28, 2026
Removedv0.32.0Jul 22, 2026
Changed1 schema field changedv0.22.1Jun 23, 2026
- addedInput schema / properties / folder / minLength
```
Added value: +1
```
AddedMay 26, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely new behavior: index lag of a few seconds after file changes, exclusion of inline Dataview fields, what 'count' includes (notes with null values), how sample_values are rendered for numbers and checkboxes, and how empty vaults and SqliteError failures are distinguished from call errors.

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-loaded summary, then examples, when-to-use, parameter, behavior, errors, and returns in labeled blocks, so it is easy to scan. It runs long, with two examples and a render-detail parenthetical that could be tightened, but nearly every line carries information the schema and annotations do not.

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?

With no output schema, the description supplies the return contract (JSON array of key/count/sample_values, sorted by count descending then key) and the example payload. For a one-optional-parameter read tool it also covers edge cases (empty vault, index errors), leaving nothing an agent needs unresolved.

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?

Schema coverage is 100%, so the baseline is 3, but the description goes beyond the schema's terse 'Restrict to a folder' by explaining subfolder inclusion ('Projects' covers 'Projects/Archive' but not 'ProjectsOld/'), ASCII case-insensitivity, and the omit-to-scan-everything default.

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?

Opens with a specific verb and resource ('Discover all property keys in the vault') plus the distinguishing scope ('without reading individual notes') and the returned fields (note counts, sample values). An agent can separate it from vault_list_tags, vault_list_property_values, and vault_search_by_property without opening any schema.

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?

States explicit when-to-use ('Discovering what properties exist before searching by property... good first step for vault orientation alongside vault_list_tags') and names two alternative destinations with the conditions that select them (vault_list_property_values for full value lists, vault_search_by_property for key-value matching).

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