Skip to main content
Glama
aliasunder

Vault Cortex Obsidian MCP Server

by aliasunder
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

List Property Values

vault_list_property_values
Read-onlyIdempotent

List distinct values for a property key with note counts to see what values exist before running a property search. Handles scalar and array properties, sorted by frequency.

Instructions

List distinct values for a specific property key with note counts. Useful for discovering the range of values a property takes before searching.

Example: vault_list_property_values({ key: "status" }) returns [{ value: "active", count: 47 }, { value: "done", count: 211 }, ...]

When to use: Enumerating possible values for a property key before calling vault_search_by_property. Handles both scalar properties (status: "active") and array properties (tags: ["a", "b"]) — array elements are unpacked and counted individually, so the sum of counts may exceed the note count. An unknown key or empty folder returns an empty array, not an error. Call vault_list_property_keys first to discover valid key names.

Parameters:

  • key is case-sensitive and must match exactly as returned by vault_list_property_keys. Values are always strings — numeric and boolean properties are stringified for counting.

  • folder + key interact: folder restricts counting to a subtree, so the same key can return different value distributions depending on folder scope.

  • limit (default 50) applies after sorting by count descending, so you always get the most-used values first. Increase for high-cardinality keys like "title" or "created".

Returns: JSON array of { value, count } sorted by count descending.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyYesProperty key name — use vault_list_property_keys to discover valid keys (e.g. "status", "type", "tags").
limitNoMax values to return (default 50). Increase for high-cardinality properties.
folderNoRestrict to a folder prefix (e.g. "Projects")

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
  2. Addedv0.32.1
  3. Removedv0.32.0
  4. 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."
  5. Changed2 schema fields changedv0.22.1
    • addedInput schema / properties / folder / minLength
      Added value: +1
    • addedInput schema / properties / key / minLength
      Added value: +1
  6. Added

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description need not repeat those. It adds valuable behavioral details such as array elements being unpacked and counted individually, sum of counts possibly exceeding note count, and unknown keys returning an empty array rather than an error. It also mentions sorting behavior. This is rich behavioral context 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?

The description is well-structured with sections for use cases, parameters, and returns. It is concise but packed with essential information, using examples and bullet points to enhance readability. No wasted words; every sentence adds value.

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?

The description is complete for a read-only, list-style tool. It covers what it does, when to use it, edge cases (unknown key, empty folder), parameter semantics, and return format. With high schema coverage and read-only annotations, nothing important is missing. It even provides a concrete example. For its complexity level, this definition is thorough.

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?

Schema description coverage is 100%, so the schema already documents all parameters. The description adds critical semantics: case-sensitivity of the key, stringification of values, the interaction between folder and key affecting value distributions, and how limit interacts with sorting (applies after sorting by count descending). This exceeds the baseline without being redundant.

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 states a specific verb ('List') and resource ('distinct values for a specific property key'), clarifying its purpose with an example. It is clearly distinguished from siblings like vault_search_by_property, which searches notes, and vault_list_property_keys, which lists keys, by focusing on values and counts.

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?

Explicit 'When to use' section provides clear guidance: use before vault_search_by_property to enumerate possible values, and call vault_list_property_keys first to discover valid keys. Also specifies that it handles both scalar and array propertiestools, and notes when results may exceed note count. This is exemplary guidance for selecting the tool.

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

Deploy Server

Other Tools