Skip to main content
Glama

list_tasks

Read-onlyIdempotent

Retrieve and filter project tasks with strict filters or search across workspaces by title/description; filter by status, priority, assignee, labels, or runtime state.

Instructions

List tasks with strict filters. Provide project_id for a project listing or workspace_id plus search for cross-project search. Unknown parameters and invalid categories are errors. Compact items contain id, title, status slug, priority, assignee_name, labels, updated_at, runtime_state (working/waiting/queued/stopped with since/lane/ref/stale, when known) and routing parent_task_id/start_after when set; workspace results also contain project_id. Pass full=true for complete REST items; listing descriptions are subject to the API page budget, so use get_task for guaranteed full details.

Input Schema

NameRequiredDescriptionDefault
fullNoReturn complete items (full descriptions and non-capability envelope fields) instead of compact items.
pageNo1-based page number (default 1). The response reports total_pages; without this parameter every page beyond the first was unreachable while the envelope kept advertising them.
sortNoSort field: created_at, updated_at, priority, due_date.
limitNoMax results to return (default 20). The compact view caps limit at 50 — a larger value is clamped and the response says so via limit_clamped_to; pass full=true for up to 200 per page.
orderNoSort direction: asc (default) or desc. Without this, a project larger than `limit` returns its OLDEST tasks, so "what changed recently" walks come back empty and look clean. An invalid value is REFUSED by the API, not silently treated as asc.
labelsNoFilter by labels.
searchNoSearch in title and description.
assigneeNoFilter by exact case-insensitive assignee name, UUID, or me. Unknown or ambiguous names are errors.
priorityNoFilter by priority: urgent, high, medium, low, none.
project_idNoProject ID (required unless workspace_id is provided).
assignee_idNoUUID-only compatibility alias for assignee. Use assignee for names or me.
runtime_kindNoFilter by effective runtime state: working, waiting, queued, stopped. working also matches a card with a live checkout and no reported state, whatever its status.
workspace_idNoWorkspace ID for global cross-project search (requires search parameter).
assignee_typeNoFilter by assignee type: user, agent, unassigned.
list_revisionNoThe list_revision echoed back on a previous page of this same project-scoped walk (see the response's list_revision field). Pass it back to continue that walk. If the project's tasks changed since that page was issued, the call is REFUSED with list_revision_stale (HTTP 410) instead of silently returning an inconsistent page — restart pagination from page 1 (omit this field) on that error. Omit on the first page of a fresh walk. Ignored for workspace_id search.
status_categoryNoFilter by status category: backlog, todo, in_progress, review, done, cancelled.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already cover read-only/no-destructive/idempotent, yet the description adds substantial non-structured behavior: the compact payload schema, runtime_state values with since/lane/ref/stale, the API page budget, limit clamping at 50 compact vs 200 full, RFC-style refusal on stale list_revision (HTTP 410), and hard errors for unknown params/invalid categories. This is well beyond annotation coverage.

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-loads purpose and the mode rule in the first sentence, then return shape, then the get_task escape hatch. It is dense and somewhat run-on, and the long field enumeration in one sentence is heavy, but with no output schema most of that content earns its place.

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 16-parameter tool with no output schema, the description supplies the return contract (compact item fields, runtime_state sub-fields, routing fields, workspace project_id), the mode-selection rule, error semantics, and pagination/clamping caveats. Nothing an agent needs to call this correctly is missing.

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 and the schema already carries per-parameter documentation. The description still adds semantics the schema does not: full=true as the trigger for complete REST items and 200-per-page capacity, and the page-budget caveat that makes get_task the safe route. It stops short of explaining several parameters (order, sort, labels, status_category) itself, leaving that to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ("List tasks") and immediately qualifies scope with the two mutually exclusive modes: project_id for a project listing vs workspace_id plus search for cross-project search. It also names the sibling get_task as the route for guaranteed full details, so an agent can partly differentiate it without opening schemas, though other list-ish siblings (poll_tasks, get_my_tasks) are not addressed.

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?

Explicit when-to-use for the two modes ("Provide project_id for a project listing or workspace_id plus search for cross-project search") and an explicit alternative condition ("use get_task for guaranteed full details"). It also warns that unknown parameters and invalid categories are errors. Missing only guidance against sibling task-list tools such as poll_tasks or get_my_tasks.

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