List tasks
list_tasksList all tasks across every project in the active workspace. Returns the API's JSON array, in each project's outline order. To find a task by name, search is far cheaper on a large workspace. A Guest sees only the projects granted to them, without assignees. Pass milestonesOnly=true for the workspace's schedule gates alone — the quickest answer to "what's coming up" on a large workspace, since it filters server-side. A milestone marks a dated gate rather than a span of work (launch date, sign-off, go/no-go). The server holds it to one date — endDate is forced to equal startDate, so naming either one is enough — with duration 0 and progress that is only ever 0 or 100 (100 exactly when it is in the workspace's finished status). Setting isMilestone on a task that already has a date range collapses it onto its start date. WORK BREAKDOWN STRUCTURE. Tasks nest via wbsParentId, and every task carries a read-only wbscode — its dotted outline number within the project ("1", "2.3", "2.3.1") — plus issummary. wbsParentId is NOT a scheduling dependency: a WBS child sits INSIDE its parent's span and in fact defines it, whereas a predecessor runs BEFORE its successor. Predecessors are their own resource — create_task_dependency — and are unrelated to nesting. A task with at least one WBS child is a SUMMARY TASK and owns none of its own schedule: its startDate, endDate, duration, percentComplete and status are all recomputed from its children (dates span the children; progress is their span-weighted average). Writing any of those on a summary returns 422 — change the children instead. wbscode is derived from tree position, so it shifts whenever tasks are reordered or re-parented: display it, never store or match on it.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| milestonesOnly | No | Return only milestones (optional, default false) |