markdown-vault-mcp

List Folders

list_folders

Read-onlyIdempotent

List every folder that holds notes in your Markdown vault, with "" for the top level. Use the returned folder paths as arguments for search, list_documents, and other folder-scoped tools.

Instructions

List every folder that holds notes; "" stands for the top level.

Pass one as the folder argument of search, list_documents and the other folder-scoped tools.

Input Schema

Name	Required	Description	Default
`wait_for_pending_writes`	No	Wait for recent index writes. On timeout, answer from the current index with _meta.index_stale=true. Default false.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv5.0.0Sep 15, 2026

changedInput schema / properties / wait_for_pending_writes / description

Previous value: -"When True, wait until your recent\ndocument mutations have been applied to the\nindex before answering, so the results reflect those changes.\nUse it right after modifying notes when this read must see\nthem (e.g. right after a document mutation whose\neffect this read should reflect). Default\nFalse answers immediately from the current index — almost\nalways already up to date; inspect the response's\n``_meta.index_stale`` field to tell whether a write was still\nin flight. Bounded by a server timeout (default 60s); on\ntimeout it answers from the current index rather than waiting\nlonger."New value: +"Wait for recent index writes. On timeout, answer from the current index with _meta.index_stale=true. Default false."

Changed1 schema field changedv4.0.0Aug 26, 2026

changedInput schema / properties / wait_for_pending_writes / description

Previous value: -"When True, wait until your recent\nwrite/edit/delete/rename operations have been applied to the\nindex before answering, so the results reflect those changes.\nUse it right after modifying notes when this read must see\nthem (e.g. right after a write/edit/delete/rename whose\neffect this read should reflect). Default\nFalse answers immediately from the current index — almost\nalways already up to date; inspect the response's\n``_meta.index_stale`` field to tell whether a write was still\nin flight. Bounded by a server timeout (default 60s); on\ntimeout it answers from the current index rather than waiting\nlonger."New value: +"When True, wait until your recent\ndocument mutations have been applied to the\nindex before answering, so the results reflect those changes.\nUse it right after modifying notes when this read must see\nthem (e.g. right after a document mutation whose\neffect this read should reflect). Default\nFalse answers immediately from the current index — almost\nalways already up to date; inspect the response's\n``_meta.index_stale`` field to tell whether a write was still\nin flight. Bounded by a server timeout (default 60s); on\ntimeout it answers from the current index rather than waiting\nlonger."

First observedv3.1.0Jul 8, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: only folders containing notes are returned, and `""` denotes the top level — non-obvious semantics an agent would otherwise guess wrong.

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?

Two short sentences, the core definition front-loaded and the usage hint second. No filler, no restatement of the title, and the awkward line wrap does not obscure meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists and annotations are rich, so the description only needs to frame the concept, the sentinel value, and downstream use — all present. Minor gap: it does not say whether folder identifiers are paths, names, or namespaced, which matters for chaining into search/list_documents.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter wait_for_pending_writes is fully documented in the schema (100% coverage) including its timeout/staleness fallback behavior. The description says nothing about that parameter; its discussion of `""` concerns return values, not inputs. Baseline 3 applies since the schema does the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (list folders) plus a scope qualifier ('that holds notes') and defines the top-level sentinel `""`. It is clearly distinct from data-listing siblings like list_documents or list_tags, though it never explicitly contrasts itself with them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Second sentence gives concrete downstream guidance: pass a returned value as the folder argument of search, list_documents and other folder-scoped tools, which implies the tool should be called before folder-scoped operations. No explicit when-not or alternative-to-use-instead guidance is given.

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