Skip to main content
Glama
Vault Cortex Obsidian MCP Server

Vault Cortex Obsidian MCP Server

List Property Values

vault_list_property_values
Read-onlyIdempotent

Lists distinct values for an Obsidian property key with occurrence counts, so you can see valid values before searching notes by that property.

Instructions

List distinct values for a specific property key with how often each occurs.

Example: vault_list_property_values({ key: "status" }) returns [{ value: "done", count: 211 }, { value: "active", count: 47 }, ...] Example: vault_list_property_values({ key: "tags", limit: 10 }) — the 10 most-used tags property values

When to use: Enumerating possible values for a property key before calling vault_search_by_property. Call vault_list_property_keys first to discover valid key names. A value listed here can be passed straight to vault_search_by_property, which matches text exactly and a complete number numerically too, so value "1" finds the number 1, the text "1", and a checked checkbox.

Parameters:

  • key is case-sensitive and must match exactly as returned by vault_list_property_keys.

  • folder names a whole folder, subfolders included: "Projects" covers "Projects/Archive" but not "ProjectsOld/", ignoring ASCII letter case.

  • limit keeps the most-used values; nothing in the response signals truncation; raise limit for more.

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

  • Array elements (tags: ["a", "b"]) are counted individually, so the sum of counts may exceed the note count.

  • Each value is listed as text, and values with the same text share one row with combined occurrence counts: number 1 and text "1" count together, while text "1.0" stays separate.

  • Checkbox true and false come back as "1" and "0", counted with the numbers 1 and 0.

  • null values are skipped.

Errors:

  • An unknown key or empty 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 { value, count } sorted by count descending, then by value in binary text order ("10" before "2").

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "key": "<key>"
    },
    "name": "vault_list_property_values"
  }
}

Input Schema

NameRequiredDescriptionDefault
keyYesProperty key name (e.g. "status", "type", "tags").
limitNoMax values to return (default 50).
folderNoRestrict to a folder (e.g. "Projects")

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.55.1
    • changedInput schema / properties / key / description
      Previous value: -"Property key name — use vault_list_property_keys to discover valid keys (e.g. \"status\", \"type\", \"tags\")."New value: +"Property key name (e.g. \"status\", \"type\", \"tags\")."
  2. Changed1 schema field changedv0.54.16
    • addedInput schema / additionalProperties
      Added value: +false
  3. Changed2 schema fields changedv0.54.7
    • changedInput schema / properties / folder / description
      Previous value: -"Restrict to a folder prefix (e.g. \"Projects\")"New value: +"Restrict to a folder (e.g. \"Projects\")"
    • changedInput schema / properties / limit / description
      Previous value: -"Max values to return (default 50). Increase for high-cardinality properties."New value: +"Max values to return (default 50)."
  4. Changed4 schema fields changedv0.50.0
    • addedInput schema / properties / limit / default
      Added value: +50
    • addedInput schema / properties / limit / maximum
      Added value: +9007199254740991
    • addedInput schema / properties / limit / minimum
      Added value: +1
    • changedInput schema / properties / limit / type
      Previous value: -"number"New value: +"integer"
  5. Addedv0.32.1
  6. Removedv0.32.0
  7. Changed3 schema fields changedv0.23.5
    • changedInput schema / properties / folder / description
      Previous value: -"Restrict to a folder"New value: +"Restrict to a folder prefix (e.g. \"Projects\")"
    • changedInput schema / properties / key / description
      Previous value: -"Property key name (e.g. \"status\", \"type\", \"tags\")"New value: +"Property key name — use vault_list_property_keys to discover valid keys (e.g. \"status\", \"type\", \"tags\")."
    • changedInput schema / properties / limit / description
      Previous value: -"Max values to return (default 50)"New value: +"Max values to return (default 50). Increase for high-cardinality properties."
  8. Changed2 schema fields changedv0.22.1
    • addedInput schema / properties / folder / minLength
      Added value: +1
    • addedInput schema / properties / key / minLength
      Added value: +1
  9. Added

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond that: results can lag a file change by seconds, limit truncation is silent, array elements are counted individually so the count sum can exceed note count, values are coerced to shared text rows, checkboxes map to "1"/"0", and nulls are skipped. Error behavior is also disclosed (unknown key/empty folder returns an empty array rather than erroring).

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?

Well front-loaded and sectioned (purpose, examples, when-to-use, params, behavior, errors, returns), with little filler. It is dense — the type-coercion and checkbox details are lengthy — but every line carries operational information an agent needs.

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?

There is no output schema, and the description fully compensates by specifying the { value, count } array, sort order (count descending, then binary text order with "10" before "2"), truncation behavior, and error cases. Nothing material is missing for correct invocation and interpretation.

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 adds genuine meaning: key is case-sensitive and must match vault_list_property_keys output exactly, folder includes subfolders ("Projects" covers "Projects/Archive" but not "ProjectsOld") with ASCII case-insensitivity, and limit silently keeps the most-used values with no truncation signal.

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 first line gives a specific verb and resource — list distinct values for a property key with occurrence counts — and the examples make the output shape concrete. It is clearly distinguished from vault_list_property_keys (key discovery) and vault_search_by_property (filtering), both named in the text.

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?

An explicit "When to use" section states the intent (enumerating values before a property search) and names the prerequisite tool vault_list_property_keys. It also states the downstream hand-off — values can be passed straight to vault_search_by_property — with the matching semantics spelled out.

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