Skip to main content
Glama

list_tasks

Read-onlyIdempotent

List tasks visible to the caller, with optional filters: projectId, parentId (pass "null" string or JSON null for top-level-only), status, assigneeId (or the sentinels "me" / "unassigned"), assignedToAgentPersona, collaboratorId (or "me": tasks a person collaborates on without holding them), title with titleMode ("contains" default, "equals", "startsWith"; all case-insensitive), dueBefore / dueAfter, overdueOnly, orderBy. Each row carries collaborators, the people working on it besides its assignee, isManual and datesFromSubtasks (true when its dates come from its subtasks), and url, the task's link in the Onplana web app. Returns up to 200 tasks per call with cursor-based pagination (nextCursor). Without parentId, matching tasks at every depth are returned, subtasks included; parentId "null" narrows to top-level tasks. underTaskId narrows to every task under one task at any depth, such as a phase with its work packages and their tasks. workItemsOnly true leaves out summary tasks (a task with subtasks), false includes them; the response's workItemsOnly field, when present, says which it read; milestonesExcluded true, when present, says milestones were left out (pass workItemsOnly to include them). When the response carries hasMore, total counts every matching task and hasMore says more exist past this page: pass nextCursor back as cursor for the next page, or read summarize_project for project-wide counts. PREFER get_plan when you need the whole project tree in one call; PREFER list_assigned_tasks for your own queue. Use list_tasks when drilling parent to children or paginating through a large project. When you pass projectId, the response carries projectResolved: if it is false the id did not match any project visible to you and the empty tasks list says NOTHING about whether that project has work in it, re-check the id (use full ids from list_projects, never abbreviated) rather than concluding the project is empty or unsaved.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_tasks"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoDefault 25, max 200.
titleNoCase-insensitive match on task title. See titleMode for how it matches.
cursorNoLast-id pagination cursor from a prior call's nextCursor.
statusNo
orderByNoDefault 'dueDate'. Combined with priority desc as secondary.
dueAfterNoISO date - show tasks due after this date.
parentIdNoParent task id, "null" string, or JSON null for top-level-only.
dueBeforeNoISO date - show tasks due before this date.
projectIdNoOptional - restrict to one project.
titleModeNoHow title is matched: 'contains' (default), 'equals', or 'startsWith'. All case-insensitive.
assigneeIdNoShow tasks assigned to one user. Special values: 'me' (the caller), 'unassigned' (no assignee).
overdueOnlyNoWhen true, only return tasks due before today in the time zone of the user and not DONE (a task due today is not overdue).
underTaskIdNoOnly tasks under this task (a phase or other summary task), at any depth.
customFieldsNoFilter by custom-field value(s); multiple entries are ANDed. Each entry is { fieldId, op, value? }. Ops must be valid for the field type , numeric (NUMBER/CURRENCY/RATING): eq/gt/gte/lt/lte/isNotEmpty; DATE: eq/before/after/isNotEmpty; text/DROPDOWN: eq/contains/isNotEmpty; MULTI_SELECT: contains/isNotEmpty; CHECKBOX: isChecked/isUnchecked (unchecked includes never set). Omit value for isNotEmpty, isChecked and isUnchecked. No neq / isEmpty. Get field ids from list_custom_field_defs.
workItemsOnlyNoTrue: leave out summary tasks (tasks with subtasks). False: include them.
collaboratorIdNoOnly tasks this user collaborates on (works on without holding). Special value: 'me' (the caller).
includeSubtasksNoAccepted for compatibility and has no effect: subtasks at every depth are always included unless parentId is set.
assignedToAgentPersonaNoWhen true, only return tasks whose assignee is an agent persona ("what are the agents working on").

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / underTaskId
      Added value: +{
      +  "description": "Only tasks under this task (a phase or other summary task), at any depth.",
      +  "type": "string"
      +}
    • addedInput schema / properties / workItemsOnly
      Added value: +{
      +  "description": "True: leave out summary tasks (tasks with subtasks). False: include them.",
      +  "type": "boolean"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / overdueOnly / description
      Previous value: -"When true, only return tasks past their due date and not DONE."New value: +"When true, only return tasks due before today in the time zone of the user and not DONE (a task due today is not overdue)."
  3. Changed1 schema field changed
    • changedInput schema / properties / includeSubtasks / description
      Previous value: -"When true, include matching subtasks at any depth (not just top-level). Default false."New value: +"Accepted for compatibility and has no effect: subtasks at every depth are always included unless parentId is set."
  4. Changed3 schema fields changed
    • changedInput schema / properties / customFields / description
      Previous value: -"Filter by custom-field value(s); multiple entries are ANDed. Each entry is { fieldId, op, value? }. Ops must be valid for the field type , numeric (NUMBER/CURRENCY/RATING): eq/gt/gte/lt/lte/isNotEmpty; DATE: eq/before/after/isNotEmpty; text/DROPDOWN: eq/contains/isNotEmpty; MULTI_SELECT: contains/isNotEmpty; CHECKBOX: eq/isNotEmpty. Omit value only for isNotEmpty. Inclusion-only in v1 (no neq / isEmpty). Get field ids from list_custom_field_defs."New value: +"Filter by custom-field value(s); multiple entries are ANDed. Each entry is { fieldId, op, value? }. Ops must be valid for the field type , numeric (NUMBER/CURRENCY/RATING): eq/gt/gte/lt/lte/isNotEmpty; DATE: eq/before/after/isNotEmpty; text/DROPDOWN: eq/contains/isNotEmpty; MULTI_SELECT: contains/isNotEmpty; CHECKBOX: isChecked/isUnchecked (unchecked includes never set). Omit value for isNotEmpty, isChecked and isUnchecked. No neq / isEmpty. Get field ids from list_custom_field_defs."
    • changedInput schema / properties / customFields / items / properties / op / enum
      Previous value: -[
      -  "eq",
      -  "contains",
      -  "gt",
      -  "gte",
      -  "lt",
      -  "lte",
      -  "before",
      -  "after",
      -  "isNotEmpty"
      -]New value: +[
      +  "eq",
      +  "contains",
      +  "gt",
      +  "gte",
      +  "lt",
      +  "lte",
      +  "before",
      +  "after",
      +  "isNotEmpty",
      +  "isChecked",
      +  "isUnchecked"
      +]
    • changedInput schema / properties / customFields / items / properties / value / description
      Previous value: -"Comparison value; omit for isNotEmpty."New value: +"Comparison value; omit for isNotEmpty, isChecked and isUnchecked."
  5. Changed2 schema fields changed
    • addedInput schema / properties / collaboratorId
      Added value: +{
      +  "description": "Only tasks this user collaborates on (works on without holding). Special value: 'me' (the caller).",
      +  "type": "string"
      +}
    • addedInput schema / properties / customFields
      Added value: +{
      +  "description": "Filter by custom-field value(s); multiple entries are ANDed. Each entry is { fieldId, op, value? }. Ops must be valid for the field type , numeric (NUMBER/CURRENCY/RATING): eq/gt/gte/lt/lte/isNotEmpty; DATE: eq/before/after/isNotEmpty; text/DROPDOWN: eq/contains/isNotEmpty; MULTI_SELECT: contains/isNotEmpty; CHECKBOX: eq/isNotEmpty. Omit value only for isNotEmpty. Inclusion-only in v1 (no neq / isEmpty). Get field ids from list_custom_field_defs.",
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "fieldId": {
      +        "description": "CustomFieldDefinition id (scoped to this org + entity).",
      +        "type": "string"
      +      },
      +      "op": {
      +        "enum": [
      +          "eq",
      +          "contains",
      +          "gt",
      +          "gte",
      +          "lt",
      +          "lte",
      +          "before",
      +          "after",
      +          "isNotEmpty"
      +        ],
      +        "type": "string"
      +      },
      +      "value": {
      +        "description": "Comparison value; omit for isNotEmpty.",
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "fieldId",
      +      "op"
      +    ],
      +    "type": "object"
      +  },
      +  "maxItems": 20,
      +  "type": "array"
      +}
  6. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds substantial behavioral context beyond them: a 200-task cap, cursor-based pagination with nextCursor, hasMore/total semantics, projectResolved=false meaning the project id did not resolve, and detailed hierarchy behavior for parentId and underTaskId.

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 description is front-loaded with purpose and scope, then filters, return shape, pagination, and alternatives. It is long but appropriately dense for an 18-parameter tool; the main flaw is minor repetition, such as explaining the parentId top-level-only behavior twice.

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?

For a complex tool with 18 parameters and no output schema, the description is thorough. It covers returned row fields (collaborators, isManual, datesFromSubtasks, url), pagination mechanics, hierarchy semantics, workItemsOnly and milestonesExcluded response fields, and the important projectResolved false-positive-empty warning.

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 description coverage is 94%, so the baseline is 3. The description still adds real meaning beyond the schema for several parameters, including parentId's 'null' string or JSON null for top-level-only, collaboratorId 'me' as working without holding, underTaskId's any-depth scope, workItemsOnly, and the projectResolved response behavior, though it leaves status, orderBy, and customFields mostly to the schema.

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 tasks visible to the caller.' It immediately distinguishes scope with 'visible to the caller' and later names sibling tools (get_plan, list_assigned_tasks, summarize_project), so an agent can tell exactly what this tool is for without opening the schema.

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 explicitly routes the agent: 'PREFER get_plan when you need the whole project tree in one call' and 'PREFER list_assigned_tasks for your own queue.' It then gives the precise condition for using this tool: 'Use list_tasks when drilling parent to children or paginating through a large project.'

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.