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 specific property key with occurrence counts, so you can inspect options before searching by 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 }, ...]

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.

Parameters:

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

  • folder names a whole folder and includes its subfolders: "Projects" covers "Projects/Archive" but not "ProjectsOld/". Matching ignores ASCII letter case.

  • limit applies after sorting by count descending, so you always get the most-used values first. Nothing in the response signals truncation: exactly limit values may mean more exist, which is common for keys with many distinct values like "title" or "created"; raise limit to check.

Behavior:

  • 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.

  • Values with the same displayed string share one row with combined occurrence counts: number 1 and text "1" count together, while text "1.0" stays separate. Grouping happens before limit.

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

  • vault_search_by_property matches stored numbers numerically and text exactly; value "1" matches the number 1, the text "1", and a checked checkbox.

  • null values are skipped.

Errors:

  • An unknown key or empty folder returns an empty array, not an error.

Returns: JSON array of { value, count } sorted by count descending, then by value in binary text order ("10" before "2").

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).
folderNoRestrict to a folder (e.g. "Projects")

Schema Changelog

Changes observed during successful MCP inspections.

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

TDQS

A5/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), but the description adds substantial non-obvious behavior: array elements unpacked and counted individually, scalar/array handling, numeric-vs-text grouping quirks ('1' vs '1.0'), checkbox stored as 1/0, null skipping, and the silent-truncation caveat at limit. These are things an agent genuinely could not infer from annotations alone.

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?

Front-loaded with a concrete example, then organized under clear headers (When to use, Parameters, Behavior, Errors, Returns). Every paragraph is dense functional content; nothing is filler or repeated from the schema or annotations.

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 read-only listing tool with no output schema, the description fully specifies the return shape, sort order (count descending then binary text order), and error behavior (unknown key or empty folder yields an empty array, not an error). An agent has everything needed to call and interpret it.

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%, yet the description adds real meaning beyond it: 'key' is case-sensitive and must match exactly, 'folder' includes subfolders with case-insensitive matching ('Projects' covers 'Projects/Archive' but not 'ProjectsOld/'), and 'limit' applies after count-descending sort with no truncation signal. This goes well past restating the schema.

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 ('List distinct values for a specific property key with how often each occurs'), which unambiguously separates it from vault_list_property_keys (keys) and vault_search_by_property (notes). The inline example with the exact response shape removes any ambiguity about output.

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 states when to use it ('Enumerating possible values ... before calling vault_search_by_property') and the prerequisite sequencing ('Call vault_list_property_keys first to discover valid key names'). The routing to siblings is stated, not inferred.

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