Skip to main content
Glama
Vault Cortex Obsidian MCP Server

Vault Cortex Obsidian MCP Server

Search by Folder

vault_search_by_folder
Read-onlyIdempotent

Browse notes in a specified Obsidian vault folder with full metadata, including tags and links, to explore folder contents and orient yourself.

Instructions

Browse notes in a folder with full metadata.

Example: vault_search_by_folder({ folder: "Projects" }) Example: vault_search_by_folder({ folder: "About Me", recursive: false, limit: 10 }) — the folder's own notes, 10 most recent

When to use: Exploring a folder's contents with full context for vault orientation. Prefer vault_list_notes when you only need paths. Prefer vault_search when you have a text query. Use vault_get_backlinks or vault_get_outgoing_links to explore how notes in a folder connect to the rest of the vault.

Parameters:

  • folder names a whole folder, subfolders included: "Projects" covers "Projects/Archive" but not "ProjectsOld/", ignoring ASCII letter case; a trailing slash is ignored, and recursive: false keeps only the folder's own notes.

  • limit keeps the most recently modified notes. There is no offset, and nothing in the response signals truncation; raise limit for more.

Behavior: Results can lag a file change by a few seconds. Notes in hidden (dot-prefixed) folders never appear.

Errors:

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

  • "[SqliteError]: …" / "[IndexIntegrityError]: …" — the index failed, not the call; the message says what to do

Returns: JSON array of note metadata: path, title (the title property; file name without .md when missing or not text), tags (the tags property; vault_update_properties edits it), body_tags (#tags in the note's text, one per spelling; vault_replace_in_note edits them; absent when none), related ([] when missing), folder (top-level, "" at the root), type (null when missing or not text), created (null when missing or not an ISO date), modified (ISO 8601 file time), bytes (on-disk size), and when present leading_callout (the opening callout, { type, title, body }) and additional_properties (every property but title, type, created, related and tags). Sorted by most recently modified, then by path.

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": {
      "folder": "<folder>"
    },
    "name": "vault_search_by_folder"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMax results (default 20)
folderYesFolder path (e.g. "Projects", "About Me")
recursiveNoInclude subfolders (default: true)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.55.4
    • changedInput schema / properties / recursive / description
      Previous value: -"Include subfolders (default: true); false lists only the folder's top level"New value: +"Include subfolders (default: true)"
  2. Changed1 schema field changedv0.54.16
    • addedInput schema / additionalProperties
      Added value: +false
  3. Changed1 schema field changedv0.54.9
    • changedInput schema / properties / recursive / description
      Previous value: -"Include subfolders (default: true)"New value: +"Include subfolders (default: true); false lists only the folder's top level"
  4. Changed5 schema fields changedv0.50.0
    • addedInput schema / properties / limit / default
      Added value: +20
    • 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"
    • addedInput schema / properties / recursive / default
      Added value: +true
  5. Addedv0.32.1
  6. Removedv0.32.0
  7. Changed1 schema field changedv0.22.1
    • addedInput schema / properties / folder / minLength
      Added value: +1
  8. Added

TDQS

A4.9/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds behavior the annotations cannot: index lag of a few seconds, exclusion of dot-prefixed folders, no truncation signal in the response, and the exact meaning of the two error strings (index failure vs. call failure). It also states that empty or nonexistent folders return [] rather than erroring, which prevents a common agent retry loop.

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 with labeled sections (When to use, Parameters, Behavior, Errors, Returns) and two concrete call examples. The Returns paragraph is a dense run-on enumerating ten fields with parenthetical caveats, which is justified given no output schema but is the hardest part to scan.

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 three-parameter read tool with no output schema, the description covers selection, path semantics, ordering (modified desc, then path), every returned field, absent-value conventions, and failure modes. Nothing an agent needs in order to call it or interpret its result is missing.

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 already 100%, yet the description adds genuinely new meaning: prefix-boundary semantics ("Projects" matches "Projects/Archive" but not "ProjectsOld/"), ASCII case-insensitivity, trailing-slash handling, what recursive:false retains, and that limit selects the most recently modified with no offset or truncation marker. The schema only says "Include subfolders" and "Max results".

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 names a specific verb and resource ("Browse notes in a folder with full metadata") and immediately distinguishes it from vault_list_notes (paths only) and vault_search (text query). An agent can select it against all 31 siblings without opening a 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?

An explicit "When to use" line is followed by two named alternatives with the condition that selects each, plus a pointer to vault_get_backlinks/vault_get_outgoing_links for a related but different task. This is a complete routing table for the search family.

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