Skip to main content
Glama

List work packages

list_work_packages
Read-onlyIdempotent

List work packages with structured filters for assigned, overdue, sprint, and progress queries. Get paginated results with server-side grouping and sums.

Instructions

List work packages with structured filters — the workhorse read tool.

Use it for every "what is assigned to me", "what is overdue", "what is in this sprint" question. Convenience queries are parameters here, not separate tools: overdue → due_before=<today>; unassigned → assignee=['none']; nearly done → percentage_done_min=80; subtasks of a ticket → parent_id=<id>.

Returns the standard list envelope: compact rows plus pagination, plus groups when group_by was requested and sums when show_sums was requested. Groups and sums are computed server-side over the whole filtered set, independent of paging — never re-add them from the rows on one page.

Pitfalls: this returns open work packages only unless you pass status_scope or status_ids, so say so when you report counts. status_ids overrides status_scope. Status, type, priority and version ids differ per instance and must come from get_project_metadata, never from memory.

For text lookups use search_work_packages; for one work package's description, custom fields and children use get_work_package.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo1-based page number.
queryNoOptional free text, AND-combined with every other filter. Matches subject, description and comments. For text-only lookups prefer search_work_packages.
authorNoAuthor (creator) user ids, or 'me'. 'none' is not valid here.
projectNoNumeric project id or project identifier (URL slug) to scope the query. Both come from list_projects. Omit for a cross-project view.
sort_byNoServer-side sort as snake_case pairs, e.g. [['due_date','asc'],['priority','desc']]. An unknown key fails with the allowed set listed.
watcherNoWork packages watched by these user ids, or 'me'.
assigneeNoAssignee filter: numeric user ids, the single value 'me', or the single value 'none' for unassigned work. Ids come from search_principals; get_instance_info gives the current user.
group_byNoGroup the full filtered set by one snake_case column (e.g. 'status', 'assignee'). Counts in `groups` cover every page, not just this one.
type_idsNoWork package type ids (Task, Bug…); from get_project_metadata.
due_afterNoDue on or after this ISO date (YYYY-MM-DD).
fetch_allNoAggregate every page into one result instead of returning page 1. Capped at 500 items with a note when the cap bites; mutually exclusive with page.
page_sizeNoResults per page (max 100).
parent_idNoDirect children of this work package only. Mutually exclusive with top_level_only; use ancestor_id for the whole subtree.
show_sumsNoAsk the server for totals (estimated/remaining/spent hours, story points) over the full filtered set. Never add up pages yourself.
due_beforeNoDue on or before this ISO date (YYYY-MM-DD).
status_idsNoExact status ids. **Overrides status_scope** — the two never fight. Ids come from get_project_metadata.
ancestor_idNoEverything in this work package's subtree at any depth, unlike parent_id which is one level only.
raw_filtersNoEscape hatch for filters this tool does not type, most importantly custom fields: [{'name': 'customField12', 'operator': '=', 'values': ['4']}]. Custom field names and option ids come from get_work_package_schema.
responsibleNoAccountable user ids, 'me', or 'none' for no accountable user.
start_afterNoStarts on or after this ISO date (YYYY-MM-DD).
version_idsNoVersion / sprint ids; from get_project_metadata.
priority_idsNoPriority ids; from get_project_metadata. Never guess these — priority ids differ per instance.
start_beforeNoStarts on or before this ISO date (YYYY-MM-DD).
status_scopeNoStatus bucket: 'open' (default), 'closed' or 'all'. An explicit status filter is always sent, so the server's implicit open-only default never silently applies. Ignored when status_ids is given.open
created_sinceNoCreated on or after this ISO date (YYYY-MM-DD).
updated_sinceNoLast changed on or after this ISO date (YYYY-MM-DD).
top_level_onlyNoOnly work packages that have no parent. Excludes every subtask.
milestones_onlyNoOnly milestone-type work packages. Resolved against this instance's own types (no hardcoded ids) and intersected with type_ids when both are given.
percentage_done_maxNoMaximum progress percentage, 0-100.
percentage_done_minNoMinimum progress percentage, 0-100.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
sumsNoPresent only when show_sums was requested.
itemsNoThe page of results.
notesNoDegradation markers: capped aggregations, unavailable modules, …
groupsNoPresent only when group_by was requested.
paginationYesTotal/page/page_size/has_more.
Behavior5/5

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

Even though annotations already declare readOnly/openWorld/idempotent, the description adds critical behavioral context: it returns only open work packages unless status_scope/status_ids are passed, status_ids overrides status_scope, and groups/sums are computed server-side over the whole filtered set independent of paging. It also warns that IDs differ per instance and must come from get_project_metadata.

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 tightly structured with a clear opening label, use-case paragraph, return-envelope paragraph, pitfalls paragraph, and sibling-pointer paragraph. Every sentence delivers actionable information, and despite covering a complex 30-parameter tool, it remains readable and front-loaded.

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?

Given the tool's complexity (30 parameters, 0 required, rich schema, output schema, and many siblings), the description covers the essential use cases, limitations, return shape, and distinctions from adjacent tools. It is self-sufficient for an agent to know when and how to invoke it correctly.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds semantic value by translating natural-language queries into parameter combinations (overdue → due_before, unassigned → assignee=['none'], nearly done → percentage_done_min=80, subtasks → parent_id). It also clarifies cross-parameter interactions (status_ids overrides status_scope) and caveats like 'never re-add them from the rows on one page.'

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 'List work packages with structured filters — the workhorse read tool', clearly identifying the verb, resource, and scope. It explicitly distinguishes itself from siblings by pointing to search_work_packages for text lookups and get_work_package for single-package 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 provides concrete when-to-use guidance with example queries ('what is assigned to me', 'what is overdue', 'what is in this sprint') and maps them to specific parameters. It explicitly names alternatives: 'For text lookups use search_work_packages; for one work package's description, custom fields and children use get_work_package.'

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/kar-thik/openproject-mcp'

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