Weft

List Tasks

list_tasks

Read-only

Use this when the user wants tasks scoped to a specific column, sprint or dates. Without filters, returns every task on the board (capped at 200 — filter by columnId/sprintId if truncated). Sprint-scoped listing includes the sprint's archived (swept) tasks, so completed sprints show their full history. With from/to it reads the calendar: every task due, starting or running inside those days, in date order — use it for 'what is due next week?' or 'what did I have on the 3rd?'. Prefer get_board_state when the user wants a general overview.

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

Name	Required	Description
`to`	No	Calendar: last day to include, inclusive. Defaults to six weeks after `from`.
`from`	No	Calendar: first day to include (ISO date-time, only the date is used). Use with `to`.
`project`	No	Filter by project — name (case-insensitive) or ID. Pass 'none' to get tasks that belong to no project
`assignee`	No	Filter by executor: a member's name, first name or email, 'me' (tasks assigned to you, the calling agent), or 'none' (unassigned)
`columnId`	No	Filter by column ID
`sprintId`	No	Filter by sprint ID
`createdSource`	No	Filter by who created the task: 'user' = a human in the app, 'mcp' = an AI client over MCP (Claude, ChatGPT, Cursor, …)

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 14, 2026

changedInput schema / properties / assignee / description

Previous value: -"Filter by executor: a member's name or email, 'me' (tasks assigned to you, the calling agent), or 'none' (unassigned)"New value: +"Filter by executor: a member's name, first name or email, 'me' (tasks assigned to you, the calling agent), or 'none' (unassigned)"

Changed2 schema fields changedOct 23, 2026

addedInput schema / properties / from

Added value: +{
+  "description": "Calendar: first day to include (ISO date-time, only the date is used). Use with `to`.",
+  "format": "date-time",
+  "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
+  "type": "string"
+}

addedInput schema / properties / to

Added value: +{
+  "description": "Calendar: last day to include, inclusive. Defaults to six weeks after `from`.",
+  "format": "date-time",
+  "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
+  "type": "string"
+}

Changed1 schema field changedOct 9, 2026
- removedInput schema / $schema
```
Removed value: -"https://json-schema.org/draft/2020-12/schema"
```

Changed1 schema field changedOct 8, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

First observedSep 16, 2026

TDQS

A4.7/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, so safety is covered, yet the description adds substantive behavior: a 200-item cap with truncation remediation, inclusion of archived/swept tasks in sprint-scoped listing, and the exact date-overlap semantics and ordering for from/to queries.

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-loaded with the usage trigger, and every sentence carries distinct information (cap, archive behavior, calendar semantics, alternative tool). It is dense and slightly long for a list operation, and the get_board_state steering would be more useful earlier, but there is no filler.

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

Completeness4/5

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

With no output schema, the description covers the important operational risks an agent would otherwise hit: truncation, archived tasks inflating sprint results, and date-range matching semantics. The remaining gap is that it never indicates what a returned task record contains, which matters for a 7-parameter list tool.

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 boundary is the schema's job, but the description still adds meaning: from/to match tasks that are due, starting or running within the range and return date-ordered, and sprintId implicitly widens results to archived tasks. It does not explain project/assignee/createdSource behavior beyond the schema, keeping it just short of a 5.

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 plus scope: tasks filtered by column, sprint or dates. It explicitly contrasts with get_board_state, so an agent can distinguish this from the overview sibling without inspecting either 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 gives concrete when-to-use triggers, including example user phrasings ('what is due next week?', 'what did I have on the 3rd?'), states the unfiltered default, and closes with an explicit alternative ('Prefer get_board_state when the user wants a general overview').

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

All Weft tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.