Skip to main content
Glama
aliasunder

Vault Cortex Obsidian MCP Server

List Files

vault_list_files
Read-onlyIdempotent

Discovers non-markdown files (images, PDFs, canvases, data files) across a vault or folder, returning byte sizes, extension counts, and total counts so you know what exists before reading it.

Instructions

List non-markdown files in the vault or a folder — images, canvases, PDFs, data files — with per-file byte sizes and per-extension counts.

Example: vault_list_files({}) — non-markdown files across the whole vault Example: vault_list_files({ folder: "attachments" }) Example: vault_list_files({ extensions: [".png", ".jpg"], limit: 20 })

When to use: discovering what files exist before reading them with vault_read_file. vault_list_notes and vault_search_by_folder cover only markdown notes, and beyond notes vault_search indexes only canvas, PDF, and text-format files, so this is the discovery surface for everything else. For the files one specific note links to, prefer vault_get_outgoing_links.

Behavior: Use the folder's exact letter case; on a case-sensitive filesystem a different case finds nothing. Hidden (dot-prefixed) files and folders, .obsidian/ among them, never appear.

Errors:

  • A visible folder containing no files — or one that doesn't exist — returns an empty listing, not an error.

  • "absolute path blocked" / "path traversal blocked" / "hidden path blocked" — the folder starts at the filesystem root, escapes the vault (e.g. "../elsewhere") or names the vault root itself (e.g. "."), or is hidden like ".obsidian" (hidden folders are not listable); use a vault-relative folder outside hidden folders, and omit folder to list the whole vault.

  • "ENAMETOOLONG: …", "EACCES: …" or another filesystem error code — the message names the folder it could not read, and what to do; until then, pass a folder outside it.

Returns: JSON with files (array of { path, extension, bytes }, sorted by path; extension is "(none)" for a file without one), extension_counts (counts keyed by extension, e.g. { ".png": 3 }, over the full filtered set), total (full filtered count), and truncated (true when total exceeds limit).

Reading listed files: vault_read_file reads images (.png/.jpg/.jpeg/.gif/.webp), .canvas, .pdf, and the text formats .svg/.json/.txt/.csv/.xml/.log/.yaml/.yml/.base; other listed types are not readable. The bytes value is the on-disk size, not the delivery cost. An image comes back shrunk to fit when needed, so a large listed image is still cheap to read. A text format returns verbatim, and one over 100 KiB must be read in windows with vault_read_file's start_line and limit.

Input Schema

NameRequiredDescriptionDefault
limitNoMax entries returned (default 50).
folderNoFolder path to search recursively (e.g. "attachments" or "Projects/media"). Omit to list the whole vault.
extensionsNoOnly include these extensions, case-insensitive, leading dot optional (e.g. [".png", "jpg"]).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.54.16
    • addedInput schema / additionalProperties
      Added value: +false
  2. Changed2 schema fields changedv0.54.9
    • addedInput schema / properties / extensions / minItems
      Added value: +1
    • changedInput schema / properties / folder / description
      Previous value: -"Folder path to search recursively (e.g. \"attachments\"). Omit to list the whole vault."New value: +"Folder path to search recursively (e.g. \"attachments\" or \"Projects/media\"). Omit to list the whole vault."
  3. Changed1 schema field changedv0.50.0
    • addedInput schema / properties / limit / default
      Added value: +50
  4. Addedv0.32.0

TDQS

A4.4/5.0
Behavior3/5

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

Annotations already declare readOnly/idempotent/non-destructive and closed-world, so safety is covered. The description adds genuinely useful behavior: exact-case folder matching, hidden dot-file exclusion, empty-listing-instead-of-error, and truncation via limit. That is meaningfully beyond the annotations, though the long 'Reading listed files' tail drifts into vault_read_file's behavior rather than this tool's.

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?

Purpose is front-loaded and the sections (examples, when-to-use, behavior, errors, returns) are scannable. The final paragraph on how to read the listed files is useful but the longest and least about this tool, slightly inflating length.

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?

With no output schema, the description fully documents the return shape (files with path/extension/bytes, extension_counts, total, truncated), plus error cases and edge behaviors. An agent has everything needed to call it and interpret the result.

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 working examples for each parameter combination and clarifies that omitting folder lists the whole vault and that extensions are matched case-insensitively by the tool. The case-sensitivity caveat on folder is a real semantic addition not present in 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 non-markdown files in the vault or a folder — images, canvases, PDFs, data files') plus what is returned (byte sizes, per-extension counts). It explicitly separates itself from vault_list_notes and vault_search, so an agent can distinguish it from siblings without opening any 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?

Provides an explicit 'When to use' section naming the downstream action (read with vault_read_file) and the alternatives that cover markdown notes (vault_list_notes, vault_search_by_folder, vault_search) and linked files (vault_get_outgoing_links). The routing logic is unambiguous.

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