Skip to main content
Glama
YOLKINS
by YOLKINS

List Weeek tasks

weeek_list_tasks
Read-onlyIdempotent

Filter and paginate Weeek task summaries by project, board, column, assignee, or status to locate the task you need without pulling full details.

Instructions

PRIMARY tool for task discovery and filtering: returns one page of Weeek tasks filtered by project_id / board_id / board_column_id / assignee_id / completed, paginated by offset+per_page (default 20, max 100). Use the filters to locate the card a write tool is about to act on instead of paging a whole project. DISTINCT from weeek_get_task — this returns task summaries (no description / details); fetch a single full task via weeek_get_task. Use when the agent needs a list view; follow hasMore for the next page.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
offsetNoPagination offset (number of items to skip)
board_idNoFilter to tasks on this board (id from weeek_list_boards). An id that does not exist is rejected as an error, not answered with an empty list.
per_pageNoPagination page size (1-100). Default 20 — sized so a single page fits comfortably under the 25k MCP-token cap that most clients use for `tools/call` responses; raise explicitly if you need a larger page and have the budget for it.
completedNoIf true, return only completed tasks; if false, only open ones
project_idNoFilter to tasks of this project
assignee_idNoFilter to tasks this member is assigned to — matches any assignee, not only the primary one (a task where the member is a secondary assignee still matches). UUID from weeek_list_members.id. A UUID that is not a member of this workspace is rejected as an error (weeek_validation_error, HTTP 422), not answered with an empty list.
board_column_idNoFilter to tasks sitting in this board column — the status filter (id from weeek_list_board_columns). Column ids are unique across boards, so this narrows on its own; board_id is not required alongside it. An id that does not exist is rejected as an error, not answered with an empty list.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
tasksYesTasks matching the filters
hasMoreYesTrue if more tasks exist beyond this page; call again with offset = previous offset + tasks.length
truncatedYesTrue if the response was clipped by the server's MAX_RESPONSE_CHARS gate. Independent from hasMore (pagination): truncated=true means the local byte-budget gate fired, so re-issue with smaller per_page / narrower filters or raise MAX_RESPONSE_CHARS in the server env.
Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds behavioral context: returns only one page, pagination via offset/per_page (default 20, max 100), returns summaries without description/details, and to follow hasMore for the next page. No contradictions.

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 compact and front-loaded with 'PRIMARY tool', then lists what it does, offers usage guidance, clarifies the distinction from weeek_get_task, and closes with pagination advice. Every sentence 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?

Despite having 7 optional parameters and an output schema, the description covers the main use case, pagination, the summary-versus-detail distinction, and the next-page mechanism. The output schema supplies return-value details, so the description is adequately complete.

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 description coverage is 100% with rich per-parameter descriptions (e.g., error behavior for invalid IDs, assignee matching semantics). The description merely restates the filter names without adding new meaning, so the baseline of 3 applies.

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 states this is the PRIMARY tool for task discovery and filtering, returns one page of Weeek tasks with explicit filter parameters, and distinguishes itself from weeek_get_task (summaries vs full details). This clearly identifies the tool's function and scope.

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?

The description explicitly says 'Use the filters to locate the card a write tool is about to act on instead of paging a whole project' and instructs to 'fetch a single full task via weeek_get_task' when details are needed, plus when a list view is required. This provides clear when-to-use and alternative guidance.

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/YOLKINS/weeek-mcp'

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