Skip to main content
Glama

List tasks

list_tasks
Read-only

Retrieve tasks with optional filters for board, status, priority, assignee, due date, and search. Returns compact task summaries by default to manage token limits.

Instructions

List tasks with optional filters. Without any filter returns all tasks the user has access to across every board. By default returns a COMPACT shape to stay within token limits: { board: { id, name, slug, columns } | null, tasks: [{ id, number, title, status, priority, columnId, stageId, tags (names), assignees (count), dueDate }], count }. Pass detailed=true for full task objects (heavy — can exceed limits on large boards) or use get_task / get_task_by_number for one full task.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNoISO date string YYYY-MM-DD — filter tasks by this date
slugNoDeprecated alias of board_slug
limitNoMax number of tasks to return
todayNoReturn only today's relevant tasks (assigned to user, due today or overdue)
numberNoExact task number (#N without '#')
offsetNoPagination offset
searchNoSearch in task title/description; numeric value also matches task number
statusNoFilter by task status
detailedNoReturn full task objects instead of the compact shape (default false)
group_byNoGroup counters by field
priorityNoFilter by task priority
board_slugNoBoard slug — limits results to tasks of that board
watcher_idNoFilter by watcher user UUID
assignee_idNoFilter by assignee user UUID
Behavior5/5

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

Beyond the readOnlyHint and openWorldHint annotations, the description reveals the default COMPACT response shape with exact fields, warns that detailed=true 'can exceed limits on large boards,' and clarifies that with no filters it returns tasks across all accessible boards. This adds meaningful behavioral context without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense yet efficient: three sentences front-load the core purpose, then provide the compact-shape structure, the detailed alternative, and a pointer to single-task tools. Every sentence serves a purpose, and the embedded JSON snippet is a compact, structured reference.

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 14 optional parameters and no output schema, the description covers the essential behavior, response shape, token-limit caveat, and alternatives. It is sufficiently complete for an agent to select and invoke the tool appropriately without needing additional external information.

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 each parameter is already documented. The description adds value by explaining the interaction of the detailed parameter with token limits and by stating the global effect of omitting all filters. This goes slightly beyond the schema while not repeating every field.

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 clear verb+resource combination: 'List tasks with optional filters.' It distinguishes itself from related tools by stating 'use get_task / get_task_by_number for one full task,' clearly differentiating a bulk-list operation from single-task retrieval.

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?

Explicit guidance is provided: the default compact shape conserves tokens, detailed=true should be used cautiously on large boards, and get_task/get_task_by_number are recommended when a single full task is needed. This gives clear when-to-use and when-not-to-use direction relative to alternatives.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/gonnagetapower/kelvia-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server