Skip to main content
Glama

tasks_list

Read-only

Lists sprints, tasks, and subtasks as an indented tree with derived statuses, letting you filter by assignee, sprint, status, text, or leaves and optionally include descriptions and notes.

Instructions

List sprints/tasks/subtasks as an indented tree with their (derived) status.

Input Schema

NameRequiredDescriptionDefault
idNoOnly this item and everything below it
descNoAlso print each item's description
textNoCase-insensitive match in title/description
notesNoAlso print each item's notes
leavesNoOnly items without children
sprintNoOnly this sprint id
statusNonone (brak), in_progress (w trakcie), blocked (bloker, needs reason), done (gotowe), cancelled (anulowane), review (w przeglądzie)
assigneeNoOnly this assignee

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.6

TDQS

B3.2/5.0
Behavior3/5

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

readOnlyHint=true already tells the agent this is a safe read. The description adds real value by disclosing the return shape (indented tree) and that status is derived rather than stored, but it says nothing about default scope when no filters are given, pagination, or ordering.

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?

A single compact sentence with the key information (scope, tree format, derived status) front-loaded. No filler, though it is arguably too terse given 8 parameters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only listing tool with no output schema, the description covers the output shape but omits default behavior (does it list everything when called with no arguments?), ordering, and how filters combine. The rich schema compensates for the parameter side, but output expectations remain thin.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% across all 8 parameters, so the schema already explains each filter. The description adds only the general idea of hierarchy and derived status, no per-parameter meaning, so the baseline 3 applies.

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 (List), the resources (sprints/tasks/subtasks) and the output shape (indented tree with derived status), which is more informative than a bare 'list tasks'. It does not distinguish itself from close siblings like tasks_overview, tasks_brief or tasks_view, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus tasks_overview, tasks_next, tasks_sprint or tasks_brief. An agent must infer the use case from the name alone.

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