Skip to main content
Glama

List Tasks

vault_list_tasks
Read-onlyIdempotent

Filter and retrieve checkbox tasks across an Obsidian vault using date, status, priority, folder, path, heading, or tag. Returns each task with its full location and metadata, enabling vault-wide triage in one query.

Instructions

List checkbox tasks across the whole vault with structured filters β€” the Tasks-plugin data model over MCP. Both task metadata formats are indexed: emoji signifiers (πŸ“… due, ⏳ scheduled, πŸ›« start, βž• created, βœ… done, ❌ cancelled, πŸ”Ίβ«πŸ”ΌπŸ”½β¬ priority, πŸ” recurrence, πŸ†”/β›” dependencies) and Dataview inline fields ([due:: 2026-07-04], [priority:: high], ...). Every result carries its full attribution β€” note path, folder, nearest heading (the lane on a Kanban board), and line number β€” so no follow-up reads are needed to locate a task. Task lines inside fenced code blocks and %% %% comment blocks are not indexed.

Example: vault_list_tasks({ due: { before: "2026-07-04" } }) β€” overdue triage; the default status (not_done) and sort (due ascending) make this the "what's overdue?" call Example: vault_list_tasks({ path: "Code Projects/vault-cortex/TASKS.md", heading: ["Active", "Up Next", "Waiting On"], sort_by: "position" }) β€” actionable Kanban lanes in board order; position is the natural sort for boards (file path then line number, preserving card arrangement) Example: vault_list_tasks({ folder: "Code Projects/vault-cortex" }) β€” all open tasks across a project tree (TASKS.md + task-notes/ subdirectories); folder is a recursive prefix match Example: vault_list_tasks({ status: "done", done: { after: "2026-06-26" } }) β€” what got completed this week Example: vault_list_tasks({ status: ["todo", "in_progress"] }) β€” explicit equivalent of "not_done" Example: vault_list_tasks({ priority: ["highest", "high"], sort_by: "priority" }) β€” most urgent open work first

When to use: Any vault-wide task triage question β€” "what's overdue?", "what's open per project?", "what did I finish this week?" β€” in one call instead of per-board reads. Prefer vault_read_note (heading mode) to read one specific board lane verbatim. Prefer vault_search for full-text queries over note content.

Parameters:

  • status: a single value or an array of values, OR-combined (default "not_done"). Values: "not_done" (todo + in_progress, excludes done AND cancelled), "todo", "in_progress", "done", "cancelled", "all". Virtual values expand in arrays: ["not_done", "done"] matches todo + in_progress + done. Checkbox chars map to statuses the way the Tasks plugin maps them: " " todo, "/" in_progress, "x"/"X" done, "-" cancelled, any other char todo.

  • due / scheduled / start / done / created / cancelled: date filters, each { before, on, after } in YYYY-MM-DD β€” before/after are exclusive, on is exact. A date filter only matches tasks that HAVE that date.

  • priority: array of "highest" | "high" | "medium" | "low" | "lowest" | "none", OR-combined ("none" = tasks with no priority signifier).

  • folder: recursive note-path prefix β€” includes all notes under the folder and its subdirectories (e.g. "Code Projects/vault-cortex" matches TASKS.md and task-notes/*.md). Use path for a single board file. tag: bare inline-task-tag name; a parent tag matches children ("errand" matches "errand/groceries"). heading: exact heading text or array of headings, case-sensitive, OR-combined (e.g. ["Active", "Up Next"] returns tasks under either heading β€” useful for querying multiple Kanban lanes at once). path: one note, must end in ".md".

  • sort_by: "due" (default) | "scheduled" | "start" | "created" | "done" | "priority" | "note_mtime" | "position". Date sorts put dateless tasks last in both directions and cascade through related dates when the primary is absent β€” due falls through to scheduled β†’ start β†’ created; scheduled, start, and created cascade similarly through the remaining date fields. Each cascade step uses its own natural direction (due/scheduled ascending, start/created descending), so a task with no due date but a created date sorts newest-first rather than inheriting due's ascending order. An explicit sort_direction overrides all cascade steps uniformly. "done" does not cascade β€” it sorts by done date alone, with a modified-time tiebreaker for undated tasks. Fully dateless tasks tie-break by note modified time (most recent first), then file position. Priority sorts highestβ†’lowest with unprioritized between medium and low. "position" sorts by file path then line number β€” the natural order for Kanban boards where card position IS priority.

  • limit: max results (default 50). The total field always reports the full match count, so "50 of 338" is distinguishable from "all 50".

Errors:

  • A malformed or calendar-invalid date filter throws with remediation text ("Use YYYY-MM-DD")

  • path without the ".md" extension is rejected

  • No matches returns { total: 0, tasks: [] }, not an error β€” don't use as an existence check

Returns: JSON { total, tasks }. Each task carries: path, line (1-based file line number), status, status_char (raw checkbox character, for custom-status vaults), description (inline #tags kept in the text), folder (the note's full parent folder), heading (nearest heading above the task β€” on a Kanban board this is the lane name, null-omitted above the first heading), plus whichever metadata the task has: created/scheduled/start/due/done/cancelled dates, priority, recurrence (rule text β€” parsed, never executed), on_completion, task_id, depends_on, tags (bare inline tag names), block_id, is_kanban_task (true when the task's parent note has kanban-plugin frontmatter β€” present only when true, omitted for regular tasks; when true, heading carries the Kanban lane name and completing the task requires a lane move, not just a checkbox toggle). Null fields, false booleans, and empty arrays are omitted to keep responses lean.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dueNoDue date (πŸ“… / [due:: ]) bounds
tagNoInline task tag, bare name without "#"; parent tags match children
doneNoDone date (βœ… / [completion:: ]) bounds
pathNoRestrict to one note (vault-relative path ending ".md")
limitNoMax results (default 50)
startNoStart date (πŸ›« / [start:: ]) bounds
folderNoRestrict to a note-path prefix (e.g. "Code Projects/vault-cortex")
statusNoStatus filter, OR-combined (default "not_done" = todo + in_progress, excluding done and cancelled). Virtual values expand in arrays: "not_done" adds todo + in_progress, "all" includes every status.
createdNoCreated date (βž• / [created:: ]) bounds
headingNoExact heading text or array of headings, OR-combined, case-sensitive (e.g. "Active" or ["Active", "Up Next"])
sort_byNoSort key (default "due"). Date sorts cascade through related fields when the primary is absent; each fallback uses its own natural direction. "position" sorts by file path then line number β€” the natural order for Kanban boards.
priorityNoPriority levels, OR-combined; "none" selects tasks with no priority signifier
cancelledNoCancelled date (❌ / [cancelled:: ]) bounds
scheduledNoScheduled date (⏳ / [scheduled:: ]) bounds
sort_directionNoSort direction. Default per field: "asc" for due/scheduled/priority/position, "desc" for start/created/done/note_mtime. Within a date cascade, each fallback uses its own default; an explicit value overrides all fields uniformly.
Behavior5/5

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

The description comprehensively covers behavioral traits beyond annotations, including indexing behavior, exclusion of code/comment blocks, empty result handling, and detailed error messages. No contradiction with annotations.

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?

Well-structured with a clear opening, usage examples, when-to-use, parameter details, error notes, and return format. Each section efficiently adds value without redundancy, though lengthy due to tool complexity.

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?

Despite no output schema, the description fully compensates by detailing every output field and their behavior. Covers all parameter interactions, sorting nuances, and error handling, fully equipping the agent for correct invocation.

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?

Despite 100% schema description coverage, the description adds substantial semantics: explains default values, date filter exclusivity, sort cascading, and provides multiple concrete examples for complex parameter combinations.

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 clearly states the tool's function: 'List checkbox tasks across the whole vault with structured filters' and explicitly distinguishes it from sibling tools like vault_read_note and vault_search, making purpose unambiguous.

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?

A dedicated 'When to use' section provides explicit guidance on appropriate use cases (vault-wide task triage) and contrasts with alternatives, specifying when to prefer vault_read_note or vault_search.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/aliasunder/vault-cortex'

If you have feedback or need assistance with the MCP directory API, please join our Discord server