Skip to main content
Glama
maxkuminov

Obsidian MCP (pgvector + Ollama, self-hosted)

by maxkuminov

List tasks

list_tasks
Read-onlyIdempotent

Lists checkbox tasks across an Obsidian vault from the index without reading notes; filter by folder, status, due or scheduled date, and tags, with cursor pagination.

Instructions

List checkbox tasks (- [ ] …) across the vault in one call, from the index — no note is read.

Reads the index, refreshed each pass (default every 300 s): a just-edited note may show its previous tasks until the next pass. Tasks-plugin and Dataview query blocks are fenced text and are not evaluated; only the checkbox lines themselves are tasks. A checkbox inside a fenced code block or inline code is not a task.

Status: [ ], [/] (in progress) and any other marker are open; [x] and [X] are done; [-] is cancelled — excluded from open, included in all. Each line shows the raw marker.

Ordering: due date ascending, undated tasks last, then path, then line. When more rows match than fit, the header says more: yes and the response ends with next: <cursor>; pass it back as cursor with the same filters to continue. A cursor from other filters or another owner is refused (invalid_argument); so is a compact cursor whose note has since gone — start again without one.

Each task is one line: the marker, the path in backticks with :line, then any of due, scheduled, start and done dates, priority, the task's own #tags, the heading path (under:), and text: last, as written (Tasks-plugin emoji included). Text past 1,000 characters is cut and labelled; a task whose tags were capped (64 kept) says tags cut. A first row too long for the response is shown abbreviated rather than skipped.

The header always states not yet scanned for tasks (notes the index has not re-derived yet, e.g. right after an upgrade), tasks could not be indexed and over the task cap (5,000 per note), each even when zero, and with tags the count of tasks whose tags were cut. When either of the first two is non-zero the list is incomplete and the response says so — "no tasks" then does not mean none exist.

Args: folder: Only notes under this path prefix (e.g. "Projects/"). status: open (default), done, cancelled or all. due_by: YYYY-MM-DD; only tasks due on or before this date. Tasks with no due date are excluded when it is given. scheduled_by: YYYY-MM-DD; only tasks scheduled on or before this date. Tasks with no scheduled date are excluded when it is given. tags: Only tasks carrying every one of these inline tags on the task line itself (a leading # is optional; note-level tags are not consulted). At most 32, each 1–128 characters. limit: Maximum tasks per page (1–500, default 100). The response size cap can end a page sooner; next then continues it. cursor: The next value from the previous page of the same query.

Input Schema

NameRequiredDescriptionDefault
tagsNo
limitNo
cursorNo
due_byNo
folderNo
statusNoopen
scheduled_byNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.10.0

TDQS

A4.7/5.0
Behavior5/5

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

Well beyond the annotations, which only declare read-only/idempotent/non-destructive: the description discloses index staleness (refresh default 300 s, so just-edited notes may be stale), truncation rules (text cut past 1,000 chars, 64 tags kept, 5,000-task-per-note cap), cursor failure modes (invalid_argument on mismatched filters, stale compact cursors), and header health flags where a non-zero value means the list is incomplete. Nothing conflicts with the annotations.

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 and read/no-read scope are front-loaded, and the dense paragraphs on ordering, paging, row format and header flags each carry non-obvious information. It is long, but length is justified by a 7-param tool with 0% schema documentation; only minor redundancy (restating that a non-zero flag means the list is incomplete, then "'no tasks' then does not mean none exist") could be trimmed.

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 annotations already covering the safety profile and an output schema present, the description still supplies everything an agent needs: ordering, page/continuation mechanics, row layout, truncation markers, and the caveat that header flags can make an empty result unreliable. No material gap remains 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?

Schema description coverage is 0%, yet the Args block documents all seven parameters with meaning beyond the schema: folder is a path prefix, status enumerates and defines open/done/cancelled/all plus the marker-to-status mapping, due_by/scheduled_by exclude undated tasks and require YYYY-MM-DD, tags are task-line-only (note-level tags not consulted) with 32-tag/1–128-char bounds, limit bounds 1–500 with a size cap that can shorten pages, and cursor must come from the same query.

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 checkbox tasks across the vault") plus the defining mechanism ("from the index — no note is read"), which immediately distinguishes it from note-content siblings like read_note or keyword_search. It also scopes what counts as a task (checkbox lines only, code fences excluded).

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?

Gives clear context for when this is the right call: vault-wide task enumeration without reading notes, with explicit boundaries (Tasks-plugin/Dataview blocks not evaluated, inline-code checkboxes ignored). It does not name an alternative sibling or state when NOT to use it (e.g. use keyword_search for text, read_note to see a task's surrounding note), so it stops short of full routing guidance.

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