Skip to main content
Glama
aliasunder

Vault Cortex Obsidian MCP Server

by aliasunder
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

List Notes

vault_list_notes
Read-onlyIdempotent

List Markdown note paths in an Obsidian vault, optionally filtered by folder or glob pattern. Returns only vault-relative paths, not content or metadata.

Instructions

List .md file paths in the vault, optionally filtered by folder and/or glob pattern. Returns paths only — not content or metadata.

Example: vault_list_notes({ folder: "Projects" }) Example: vault_list_notes({ glob: "**/session-log.md" })

When to use: Browsing what exists in a folder by filename, or finding notes matching a path pattern. Prefer vault_search_by_folder when you need metadata (tags, type, related) along with paths. Prefer vault_search for content-based discovery. Use vault_read_note to read a note from the results.

Parameters:

  • folder scopes the listing to a path prefix ("Projects" includes "Projects/Archive"). When combined with glob, the glob pattern is applied within the folder's scope.

  • glob supports * (any filename chars) and ** (any path depth). Applied to vault-relative paths.

Errors:

  • A nonexistent folder or no glob matches returns an empty array, not an error.

  • "absolute path blocked" — the folder starts at the filesystem root; use a vault-relative folder path.

  • "hidden path blocked" — the folder is hidden (dot-prefixed, like ".obsidian"); hidden folders are not listable, matching Obsidian.

Returns: JSON array of vault-relative path strings (e.g. ["Projects/plan.md", "Notes/idea.md"]).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
globNoGlob pattern for path filtering (e.g. "**/*session-log*.md"). Supports * and ** wildcards. Combined with folder when both are set.
folderNoFolder path prefix (e.g. "About Me", "Projects"). Includes all subfolders.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.32.1
  2. Removedv0.32.0
  3. Changed2 schema fields changedv0.23.5
    • changedInput schema / properties / folder / description
      Previous value: -"Folder to list (e.g. \"About Me\", \"Projects\")"New value: +"Folder path prefix (e.g. \"About Me\", \"Projects\"). Includes all subfolders."
    • changedInput schema / properties / glob / description
      Previous value: -"Glob pattern to filter paths (e.g. \"Projects/**/*.md\", \"*.md\"). Supports * and ** wildcards."New value: +"Glob pattern for path filtering (e.g. \"**/*session-log*.md\"). Supports * and ** wildcards. Combined with folder when both are set."
  4. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description goes further by disclosing genuinely non-obvious behavior: a nonexistent folder or zero matches returns an empty array rather than an error, and absolute or hidden paths are blocked. That is real added value beyond the structured fields.

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 with the one-line purpose, then examples, usage, parameters, errors, and returns in labelled sections so an agent can skim. Slightly verbose with two examples and an enumerated error list, but each block carries distinct information.

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?

Even without an output schema, the description states the return type precisely (JSON array of vault-relative path strings, with examples) and documents the failure modes that matter for calling it correctly. Nothing an agent needs is missing.

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 coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: folder is a prefix that pulls in subfolders ("Projects" includes "Projects/Archive"), and when combined with glob the pattern is applied within the folder's scope, using vault-relative paths.

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 .md file paths in the vault") plus the scope constraint ("optionally filtered by folder and/or glob pattern") and explicitly delimits what is returned ("paths only — not content or metadata"). This lets an agent distinguish it from vault_search_by_folder and vault_search 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?

Gives an explicit "When to use" statement and names three alternatives with the conditions that select them: vault_search_by_folder for metadata, vault_search for content, vault_read_note to read a result. Nothing is left to inference.

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