Skip to main content
Glama
aliasunder

Vault Cortex Obsidian MCP Server

List Tasks

vault_list_tasks
Read-onlyIdempotent

Query vault-wide checkbox tasks with structured filters for status, dates, priority, tags, folder, and heading, returning each task's file path, line, and heading so results are actionable.

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, 🏁 onCompletion, πŸ†”/β›” dependencies) and Dataview inline fields ([due:: 2026-07-04], [priority:: high], ...). Every result says where the task lives (path, line, heading; see Returns), so no follow-up reads are needed to locate it. Task lines inside fenced code blocks and %% %% comment blocks are not indexed. Checkboxes typed NON_TASK in the Tasks plugin's status registry are also excluded.

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 Example: vault_list_tasks({ folder: "Code Projects/vault-cortex" }) β€” all open tasks across a project tree (TASKS.md + task-notes/ subdirectories) Example: vault_list_tasks({ status: "done", done: { after: "2026-06-26" } }) β€” what got completed this week Example: vault_list_tasks({ top_level_only: true, path: "TASKS.md" }) β€” board cards only, excluding checklist sub-items

When to use: Reading task status and order on one board (path + sort_by: "position"; add status: "all" to include done and cancelled cards). Also 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) only when you need a lane's verbatim Markdown or a task's state right after a write. Prefer vault_search for full-text queries over note content.

Behavior: A file change takes a few seconds to appear here, so a task written moments ago may still show its old state.

Parameters:

  • status: "not_done" and "all" expand in arrays β€” ["not_done", "done"] matches todo + in_progress + done.

  • due / scheduled / start / done / created / cancelled: a date filter only matches tasks that HAVE that date.

  • folder: a whole folder, subfolders included ("Projects" covers "Projects/Archive" but not "ProjectsOld/"), ignoring ASCII letter case.

Errors:

  • "invalid due.before date: …" (any date filter's bound) β€” the bound isn't in YYYY-MM-DD form; use that form

  • "… is not a calendar date" β€” the bound has the YYYY-MM-DD form but names a day that doesn't exist, such as 2026-02-30; pass a real date

  • "path must end in .md" β€” add the ".md" extension

  • "tag must not be empty …" β€” tag is "#" alone; pass the tag name

  • No matches returns { total: 0, tasks: [] }, not an error

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

Returns: JSON { total, tasks }. Every task carries path, line, status, status_char, description, folder, depth (0 for top-level, 1+ for sub-tasks), is_kanban_task, depends_on, and tags (the arrays are [] when empty). Every other field appears only when the task has it: heading (nearest heading above the task), created/scheduled/start/due/done/cancelled dates, priority, recurrence, on_completion, task_id, block_id, parent_block_id (sub-tasks whose parent carries a ^block-id), done_lanes (Kanban boards only), and subtask_progress β€” { done, total } over the task's DIRECT checklist children, present only when the task has a checklist; done counts status "done" only (a cancelled child counts toward total, not done), and the counts ignore the query's filters β€” so a filtered or top_level_only read still shows each card's checklist progress.

Input Schema

NameRequiredDescriptionDefault
dueNoDue date (πŸ“… / [due:: ]) bounds
tagNoTag on the task line, "#" optional; matches nested tags, any letter case
doneNoDone date (βœ… / [completion:: ]) bounds
pathNoRestrict to one note (vault-relative path ending ".md", case-sensitive)
limitNoMax results (default 50); total always reports the full match count
startNoStart date (πŸ›« / [start:: ]) bounds
folderNoRestrict to a folder (e.g. "Code Projects/vault-cortex")
statusNoStatus filter, OR-combined (default "not_done" = todo + in_progress, excluding done and cancelled). "all" includes every status.not_done
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 (through the rest of due β†’ scheduled β†’ start β†’ created, in that order; done does not cascade); each fallback uses its own natural direction. "position" sorts by file path then line number β€” the natural order for Kanban boards.due
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.
top_level_onlyNoWhen true, only top-level tasks (depth 0) are returned β€” excludes indented sub-tasks and checklist items. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.54.16
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / cancelled / additionalProperties
      Added value: +false
    • addedInput schema / properties / created / additionalProperties
      Added value: +false
    • addedInput schema / properties / done / additionalProperties
      Added value: +false
    • addedInput schema / properties / due / additionalProperties
      Added value: +false
    • addedInput schema / properties / scheduled / additionalProperties
      Added value: +false
    • addedInput schema / properties / start / additionalProperties
      Added value: +false
  2. Changed1 schema field changedv0.54.13
    • changedInput schema / properties / tag / description
      Previous value: -"Inline task tag, bare name without \"#\"; parent tags match children"New value: +"Tag on the task line, \"#\" optional; matches nested tags, any letter case"
  3. Changed3 schema fields changedv0.54.9
    • addedInput schema / properties / priority / minItems
      Added value: +1
    • changedInput schema / properties / sort_by / description
      Previous value: -"Sort 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."New value: +"Sort key (default \"due\"). Date sorts cascade through related fields when the primary is absent (through the rest of due β†’ scheduled β†’ start β†’ created, in that order; done does not cascade); each fallback uses its own natural direction. \"position\" sorts by file path then line number β€” the natural order for Kanban boards."
    • changedInput schema / properties / status / description
      Previous value: -"Status 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."New value: +"Status filter, OR-combined (default \"not_done\" = todo + in_progress, excluding done and cancelled). \"all\" includes every status."
  4. Changed2 schema fields changedv0.54.7
    • changedInput schema / properties / folder / description
      Previous value: -"Restrict to a note-path prefix (e.g. \"Code Projects/vault-cortex\")"New value: +"Restrict to a folder (e.g. \"Code Projects/vault-cortex\")"
    • changedInput schema / properties / path / description
      Previous value: -"Restrict to one note (vault-relative path ending \".md\")"New value: +"Restrict to one note (vault-relative path ending \".md\", case-sensitive)"
  5. Changed4 schema fields changedv0.50.0
    • addedInput schema / properties / limit / default
      Added value: +50
    • addedInput schema / properties / sort_by / default
      Added value: +"due"
    • addedInput schema / properties / status / default
      Added value: +"not_done"
    • addedInput schema / properties / top_level_only / default
      Added value: +false
  6. Changed5 schema fields changedv0.41.2
    • changedInput schema / properties / limit / description
      Previous value: -"Max results (default 50)"New value: +"Max results (default 50); total always reports the full match count"
    • 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 / top_level_only
      Added value: +{
      +  "description": "When true, only top-level tasks (depth 0) are returned β€” excludes indented sub-tasks and checklist items. Default false.",
      +  "type": "boolean"
      +}
  7. Changed11 schema fields changedv0.26.4
    • addedInput schema / properties / heading / anyOf
      Added value: +[
      +  {
      +    "minLength": 1,
      +    "type": "string"
      +  },
      +  {
      +    "items": {
      +      "minLength": 1,
      +      "type": "string"
      +    },
      +    "minItems": 1,
      +    "type": "array"
      +  }
      +]
    • changedInput schema / properties / heading / description
      Previous value: -"Exact heading text above the task (case-sensitive) β€” a Kanban lane name (e.g. \"Active\")"New value: +"Exact heading text or array of headings, OR-combined, case-sensitive (e.g. \"Active\" or [\"Active\", \"Up Next\"])"
    • removedInput schema / properties / heading / minLength
      Removed value: -1
    • removedInput schema / properties / heading / type
      Removed value: -"string"
    • changedInput schema / properties / sort_by / description
      Previous value: -"Sort key (default \"due\" β€” ascending, dateless tasks last)"New value: +"Sort 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."
    • changedInput schema / properties / sort_by / enum
      Previous value: -[
      -  "due",
      -  "scheduled",
      -  "start",
      -  "created",
      -  "done",
      -  "priority",
      -  "note_mtime"
      -]New value: +[
      +  "due",
      +  "scheduled",
      +  "start",
      +  "created",
      +  "done",
      +  "priority",
      +  "note_mtime",
      +  "position"
      +]
    • changedInput schema / properties / sort_direction / description
      Previous value: -"Sort direction (default \"asc\" for due/scheduled, \"desc\" for start/created/done/note_mtime)"New value: +"Sort 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."
    • addedInput schema / properties / status / anyOf
      Added value: +[
      +  {
      +    "enum": [
      +      "not_done",
      +      "todo",
      +      "in_progress",
      +      "done",
      +      "cancelled",
      +      "all"
      +    ],
      +    "type": "string"
      +  },
      +  {
      +    "items": {
      +      "enum": [
      +        "not_done",
      +        "todo",
      +        "in_progress",
      +        "done",
      +        "cancelled",
      +        "all"
      +      ],
      +      "type": "string"
      +    },
      +    "minItems": 1,
      +    "type": "array"
      +  }
      +]
    • changedInput schema / properties / status / description
      Previous value: -"Status filter (default \"not_done\" = todo + in_progress, excluding done and cancelled)"New value: +"Status 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."
    • removedInput schema / properties / status / enum
      Removed value: -[
      -  "not_done",
      -  "todo",
      -  "in_progress",
      -  "done",
      -  "cancelled",
      -  "all"
      -]
    • removedInput schema / properties / status / type
      Removed value: -"string"
  8. Addedv0.26.0

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the read-only/idempotent annotations, the description discloses indexing exclusions (fenced code blocks, comment blocks, NON_TASK statuses), freshness latency after writes, detailed error conditions, and return behavior. These are meaningful operational traits that annotations alone do not cover.

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?

The definition is front-loaded with purpose, examples, usage guidance, and alternatives, which suits a 16-parameter tool. It is long but mostly structured and purposeful, though the examples and Returns section could be trimmed slightly without losing essential guidance.

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?

Given the tool's complexity, 16 parameters, and lack of an output schema, the description is complete: it explains scope, indexing behavior, filtering semantics, alternatives, errors, and the full return shape including subtask_progress. An agent has enough information to call it correctly and interpret results.

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 schema already documents each parameter and enum. The description still adds useful semantics beyond the schema, such as date filters only matching tasks that actually have that date, folder subfolder/case behavior, status array expansion, and how top_level_only interacts with checklist items.

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 opens with a specific verb and resource: list checkbox tasks across the vault with structured filters, and frames it as the Tasks-plugin data model over MCP. It clearly distinguishes this from sibling tools by naming vault_read_note and vault_search as alternatives for different needs.

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?

It provides explicit when-to-use guidance, multiple concrete examples for common queries, and clear alternatives: prefer vault_read_note for verbatim Markdown or post-write state, and vault_search for full-text content searches. This leaves little ambiguity about when to choose this tool.

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