Retrieve tasks from a markdown vault using optional project and status filters to find specific work items.
List tasks with optional filters.
Args: project_filter: Filter tasks by project name. status_filter: Filter tasks by status ('todo', 'in-progress', 'blocked', 'done', 'cancelled', 'archived').
| Name | Required | Description | Default |
|---|---|---|---|
| status_filter | No | ||
| project_filter | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.3.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. 'List' clearly conveys a non-mutating retrieval operation and the filters are specified, but the description does not disclose pagination, ordering, matching semantics, or whether archived tasks are included by default; these are notable gaps for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: one summary sentence followed by two one-line parameter definitions. Every sentence adds value and there is no filler, while the Args block is cleanly separated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple optional-filter list operation with an output schema present, the description covers the core calling contract: what it returns conceptually, how to filter, and which statuses are valid. It is not fully complete because it omits ordering/pagination behavior and exact-match semantics, but these are secondary for a basic list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no per-parameter descriptions, but the description compensates fully: project_filter is explained as filtering by project name and status_filter lists the exact allowed status values. This adds meaning beyond the raw string/null schema types and gives an agent actionable filter syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 tasks') and immediately scopes the operation to an optional-filter list. This clearly distinguishes it from singular/detail task tools like get_task_details and from mutating task tools like update_task_status without needing to inspect their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to prefer list_tasks over sibling tools such as get_task_details, search_notes, or update_task_status, and no exclusions are given. The read-only listing use case is implied by the verb, but the description does not state context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.