Skip to main content
Glama

get-task-list

Read-onlyIdempotent

Fetch tasks from a Dooray project with filters for assignees, workflow status, dates, tags, and milestones, plus sortable paginated results for focused task review.

Instructions

Get list of tasks in a Dooray project with powerful filtering and sorting.

IMPORTANT: projectId is REQUIRED. This tool fetches tasks from a specific project.

Note: Returns compact response with essential fields only. For complete task details, use get-task.

URL Pattern Recognition: When given a Dooray URL like "https://nhnent.dooray.com/task/PROJECT_ID" or "https://nhnent.dooray.com/task/PROJECT_ID/TASK_ID", extract the PROJECT_ID (the first numeric ID after "/task/") and use it as the projectId parameter. When a URL is provided, use get-project for project info instead of get-project-list.

Member ID Filters (use organizationMemberId from get-my-member-info):

  • toMemberIds: Tasks assigned to specific members

  • ccMemberIds: Tasks where members are in CC

  • fromMemberIds: Tasks created by specific members

Workflow Filters:

  • postWorkflowClasses: ["backlog", "registered", "working", "closed"]

  • postWorkflowIds: Project-specific workflow IDs

Date Filters (flexible patterns):

  • "today" - Today's tasks

  • "thisweek" - This week's tasks

  • "prev-7d" - Last 7 days

  • "next-7d" - Next 7 days

  • ISO8601 range: "2021-01-01T00:00:00+09:00~2021-01-10T00:00:00+09:00"

Examples:

  1. All tasks in project: {"projectId": "123456"}

  2. Tasks assigned to me: {"projectId": "123456", "toMemberIds": ["my-org-member-id"]}

  3. Tasks in "working" status: {"projectId": "123456", "postWorkflowClasses": ["working"]}

  4. Tasks due today: {"projectId": "123456", "dueAt": "today"}

  5. Recent tasks (sorted by update time): {"projectId": "123456", "updatedAt": "prev-7d", "order": "-postUpdatedAt"}

  6. Tasks with specific milestone and tags: {"projectId": "123456", "milestoneIds": ["milestone123"], "tagIds": ["tag456"]}

Sorting:

  • Default: Tasks are sorted by most recently updated first (-postUpdatedAt)

  • Custom: Use order parameter with: postDueAt, postUpdatedAt, createdAt

  • Prefix with - for descending (e.g., "-createdAt")

Returns paginated task list with id, number, subject, status, priority, dueDate, assignees, tags, and milestone.

Input Schema

NameRequiredDescriptionDefault
pageNoPage number (default: 0)
sizeNoItems per page (default: 20, max: 100)
dueAtNoFilter by due date (today, thisweek, prev-7d, next-7d, or ISO8601 range)
orderNoSort order: postDueAt, postUpdatedAt, createdAt (prefix with - for descending)
tagIdsNoFilter by tag IDs
subjectsNoFilter by task subject
createdAtNoFilter by creation date (today, thisweek, prev-7d, next-7d, or ISO8601 range)
projectIdYesProject ID (REQUIRED)
updatedAtNoFilter by update date (today, thisweek, prev-7d, next-7d, or ISO8601 range)
postNumberNoFilter by specific task number
ccMemberIdsNoFilter by CC member IDs
toMemberIdsNoFilter by assignee member IDs (organizationMemberId)
milestoneIdsNoFilter by milestone IDs
parentPostIdNoFilter by parent post ID (get subtasks)
fromMemberIdsNoFilter by creator member IDs
postWorkflowIdsNoFilter by workflow IDs
fromEmailAddressNoFilter by creator email address
postWorkflowClassesNoFilter by workflow classes: backlog, registered, working, closed

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already cover safety with readOnlyHint, idempotentHint, and openWorldHint. The description adds useful behavioral context: a compact response with essential fields, pagination, default sort order, and the fact that full details require get-task. It does not discuss auth or rate limits, so it falls short of a 5.

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?

The description is well organized with front-loaded purpose, required-parameter warning, filter groups, examples, sorting, and return info. It is longer than ideal but reasonably sized for an 18-parameter tool; some example and URL-pattern detail overlaps with schema or could be compressed.

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 no output schema, the description explains the compact return fields and pagination. It also covers the critical usage constraints, filtering patterns, sorting behavior, and alternatives, which is enough for an agent to call this tool correctly.

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 schema already documents all 18 parameters. The description still adds meaningful semantics beyond the schema: how to extract projectId from Dooray URLs, where to source organizationMemberId values, workflow class values, flexible date patterns, sorting defaults, and concrete examples.

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 a specific verb and resource: fetching a list of tasks in a Dooray project with filtering and sorting. It also explicitly distinguishes itself from get-task by noting that it returns compact fields while get-task is for complete task details.

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 names the alternative for full details (get-task) and gives URL routing guidance, including using get-project instead of get-project-list when a URL is provided. The required projectId constraint and numerous examples make clear exactly when and how to use this tool.

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