Skip to main content
Glama
Sign In
Vibeflow

Vibeflow

by zorcec
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

List tasks

list_tasks
Read-onlyIdempotent

Browse or search the task board with filters for status, type, assignee, tag, and fuzzy search; results are paginated and can include child tasks when needed.

Instructions

List tasks with optional filters — the same listing as vibeflow tasks (same filters, same scope, same order). Unfiltered: ROOT tasks only (a child belongs to its parent's card — set children:true to include them). Filtered (status/type/user/tag/search): an explicit search returning EVERY match, children included. search is a fuzzy relevance search over title, description, comments and tags (same shared matcher as vibeflow tasks --search and the v0 q param: every whitespace-separated token must match as an ordered subsequence of one field, case-insensitive and typo-tolerant, AND across tokens; spans every status with matching children always included; ranked by score asc then id asc, named in the order echo). Counts are labelled by scope: totalMatching (every match), totalRoots (matching roots), hiddenChildren (matches omitted by root-only scope), returned (rows in tasks), limit (echoed RESOLVED — 0 is not supported and falls back to the default of 20, named in limitNotice; there is no unbounded mode, page with nextCursor or CLI --all for everything), truncated + hint (present only when the limit cut rows). Position: offset (0-based index of the first returned row), remaining (rows in THIS query's scope NOT in this response — totalRoots-based when root-only, totalMatching-based otherwise, so offset + returned + remaining always equals the scope size; 0 means exhausted), nextCursor (opaque continuation, null exactly when exhausted), order (the effective sort applied, so a continuation is stable). Projected rows (fields) always carry commentCount/fileCount even when the arrays are omitted. Use it to browse or search the board; use get_task when you already hold an id, and claim_next_task when you want the next unit of work claimed rather than just listed.

Input Schema

NameRequiredDescriptionDefault
tagNoEvery listed tag must be present on the task (AND, not OR). Combines with the other filters.
typeNoTask type, matched case-insensitively (a task with no type counts as Task). Combines with the other filters.
userNoAssignee match, trimmed and case-insensitive. Combines with the other filters.
limitNoHow many tasks to return (default 20). 0 is NOT supported and is resolved to the default LOUDLY — the response echoes the resolved limit and names the fallback in `limitNotice` — so never pass 0 meaning "all": there is no unbounded mode. A negative value is refused by input validation before the tool runs. Cost of asking for everything: roughly ~900 tokens per task, so a 500-task board costs ~450k context tokens — keep the default page and continue via offset/remaining/nextCursor (CLI: --all pages for you).
fieldsNoReturn only these task fields per row (e.g. ["id","title","status"]) to save context. Omit for the full task objects. Projected rows ALWAYS carry commentCount/fileCount even when the comments/files arrays are omitted, so a projection never silently hides that discussion or attachments exist.
searchNoFuzzy search over title, description, comments and tags (same shared matcher as `vibeflow tasks --search` and the v0 `q` param): every whitespace-separated token must match as an ordered subsequence of a single field (case-insensitive, typo-tolerant; AND across tokens), no per-field weights — the best field wins. A search spans every status and always includes matching children. Ranked by relevance (score asc, then id asc), named in the `order` echo — the same ids in the same order on every surface (a remote board narrows server-side first, then ranks the same way). Combines with the other filters.
statusNoExact status match (backlog, todo, in-progress, review, done). Combines with the other filters: every given filter must match.
childrenNoInclude child tasks in an UNFILTERED listing (default false: roots only, matching the board). A filtered query always includes matching children, so this flag only matters when no status/type/user/tag filter is given.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.26.0
    • addedInput schema / properties / search
      Added value: +{
+  "description": "Fuzzy search over title, description, comments and tags (same shared matcher as `vibeflow tasks --search` and the v0 `q` param): every whitespace-separated token must match as an ordered subsequence of a single field (case-insensitive, typo-tolerant; AND across tokens), no per-field weights — the best field wins. A search spans every status and always includes matching children. Ranked by relevance (score asc, then id asc), named in the `order` echo — the same ids in the same order on every surface (a remote board narrows server-side first, then ranks the same way). Combines with the other filters.",
+  "maxLength": 200,
+  "type": "string"
+}
  2. Changed8 schema fields changedv0.22.0
    • addedInput schema / properties / children / description
      Added value: +"Include child tasks in an UNFILTERED listing (default false: roots only, matching the board). A filtered query always includes matching children, so this flag only matters when no status/type/user/tag filter is given."
    • changedInput schema / properties / fields / description
      Previous value: -"Return only these task fields per row (e.g. [\"id\",\"title\",\"status\"]) to save context. Omit for the full task objects."New value: +"Return only these task fields per row (e.g. [\"id\",\"title\",\"status\"]) to save context. Omit for the full task objects. Projected rows ALWAYS carry commentCount/fileCount even when the comments/files arrays are omitted, so a projection never silently hides that discussion or attachments exist."
    • changedInput schema / properties / limit / default
      Previous value: -5New value: +20
    • changedInput schema / properties / limit / description
      Previous value: -"How many tasks to return. 0 (or less) means no limit. A negative value is refused by input validation before the tool runs."New value: +"How many tasks to return (default 20). 0 is NOT supported and is resolved to the default LOUDLY — the response echoes the resolved limit and names the fallback in `limitNotice` — so never pass 0 meaning \"all\": there is no unbounded mode. A negative value is refused by input validation before the tool runs. Cost of asking for everything: roughly ~900 tokens per task, so a 500-task board costs ~450k context tokens — keep the default page and continue via offset/remaining/nextCursor (CLI: --all pages for you)."
    • addedInput schema / properties / status / description
      Added value: +"Exact status match (backlog, todo, in-progress, review, done). Combines with the other filters: every given filter must match."
    • addedInput schema / properties / tag / description
      Added value: +"Every listed tag must be present on the task (AND, not OR). Combines with the other filters."
    • addedInput schema / properties / type / description
      Added value: +"Task type, matched case-insensitively (a task with no type counts as Task). Combines with the other filters."
    • addedInput schema / properties / user / description
      Added value: +"Assignee match, trimmed and case-insensitive. Combines with the other filters."
  3. Changed2 schema fields changedv0.21.1
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / fields / description
      Added value: +"Return only these task fields per row (e.g. [\"id\",\"title\",\"status\"]) to save context. Omit for the full task objects."
  4. First observedv0.20.0

TDQS

A4.8/5.0
Behavior5/5

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

Adds substantial behavior beyond the read-only/idempotent annotations: filtered versus unfiltered scope, fuzzy search semantics, limit 0 fallback, pagination invariants, truncation hints, token cost, and projection guarantees. Nothing contradicts the annotations; the read-only listing behavior is consistent.

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?

Front-loaded and logically structured from purpose to scope to search to counts to pagination to alternatives. It is dense and occasionally repetitive about CLI parity and the no-unbounded-mode warning, but most of the length carries behaviorally important detail for an 8-parameter list/search tool.

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?

No output schema exists, yet the description explains the returned counts, position metadata, pagination behavior, truncation indicators, and projected-row guarantees. This is complete enough for an agent to invoke the tool and interpret the response correctly.

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 baseline is 3, but the description adds useful cross-parameter semantics: children only affects unfiltered listings, limit 0 resolves loudly to the default, and filters/search combine as AND conditions. It repeats many schema details, but the cross-param context justifies a 4.

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 tasks') and clearly distinguishes unfiltered root-only browsing from filtered every-match search. It explicitly names sibling alternatives get_task and claim_next_task, so an agent can identify the tool's role without opening schemas.

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?

Gives explicit usage guidance: use this to browse or search the board, use get_task when an id is already known, and use claim_next_task when claiming work. It also explains when the children flag matters versus when filtered queries automatically include children.

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

Deploy Server

Other Tools