Skip to main content
Glama

list_tickets

Lists tickets from a board in board order, filterable by status or free text. Supports paging and incremental updates via server_time to detect new, changed, or removed tickets.

Instructions

Tickets on a board, in board order, optionally filtered by status or by free text. This is what to read a column or walk a whole board with; get_board returns the same tickets but takes neither limit nor a cursor. Paging: limit defaults to 50 and caps at 200, and next_cursor comes back only on a FULL page — a short page is the end of the walk, so stop when it is absent instead of calling again, and pass it back verbatim when it is there. Following a board over time: send the server_time from a previous reply as updated_since and you get only what changed since, plus removed_task_uuids for tickets that left the board or went out of view. Use the server's clock for that rather than your own, which is the whole point of server_time — your clock can drift and silently skip a ticket. Archived tickets are never returned.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoFree-text search over titles and descriptions, ranked by relevance. Whole words and prefixes, not mid-word substrings. A ranked reply cannot be paged, so this cannot be combined with cursor. A UUID, or its first eight characters or more, is not searched for — it is RESOLVED: you get the ticket with that uuid and nothing else, and an empty list if there is none. It never falls back to text search, so a uuid that matches nothing means no such ticket rather than 'here are some tickets that mention it'. That sentence used to read 'a uuid finds that ticket' and was wrong in the way that costs you an afternoon: it was ranked text matching, so asking for a uuid returned every ticket whose prose quoted it — commonplace on a board where tickets cross-reference each other — with the one you asked for ranked LAST. Archived tickets are still not returned, by uuid or by text.
limitNoTickets per page, 1 to 200. Defaults to 50. A reply holding exactly this many is a full page and carries a `next_cursor`; anything shorter is the last page.
cursorNoThe `next_cursor` from the previous page, passed back unchanged. It encodes a position on the board, so it is only meaningful for the same board and the same filters — do not build one yourself or reuse one across a different query, and a cursor Laver cannot read is a 400. Cannot be combined with `q`: ranked results have no stable order to page through, and asking for both is a 400 telling you so.
statusNoA status column's name, as shown on the board — 'To Do', 'In progress'. Matched against that board's columns, so a name from another board is a 400 rather than an empty list. Use status_uuid instead when you already hold the uuid, and do not send both.
board_uuidYesThe board to read, from list_boards
status_uuidNoA status column's uuid, from get_board. The exact form of `status`, and the one to prefer once you have read the board, since it survives a column being renamed.
updated_sinceNoReturn only tickets changed after this moment: an ISO 8601 timestamp, or — better — the `server_time` from a previous reply, which is the server's own clock and cannot drift against it. The reply then also carries `removed_task_uuids`, the tickets that left the board or went out of view since, which is the only way to notice a deletion by polling.
include_descriptionsNoSet false to leave `description` off every ticket, keeping titles, statuses, labels and uuids. Bodies are around 78% of a column listing, and you have not chosen a ticket to read yet — get_ticket has the full one. Defaults to true, and the reply with it left out is unchanged.
Behavior5/5

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

With no annotations, the description carries the full burden, and it delivers. It discloses that `next_cursor` appears only on a full page and that a short page means the walk is over. It explains the UUID-resolution pitfall in `q` (that a UUID returns only that ticket, never fallback text search), and it explicitly states archived tickets are never returned. It also reveals `removed_task_uuids` as the only way to notice deletions by polling.

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 front-loaded with purpose and then systematically covers paging, incremental refresh, and filters. However, it is quite lengthy, and the historical aside inside the `q` explanation ('That sentence used to read...') adds color but is not strictly necessary. Given the complexity and 8 parameters, the length is mostly justified, but a few sentences could be trimmed without losing essential guidance.

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?

The description is remarkably complete for a list tool with no output schema. It explains the return shape where relevant (paging cursor, removed_task_uuids, include_descriptions effect), covers all major behaviors (board order, filtering, paging, incremental updates, archived exclusion), and addresses edge cases like UUID resolution and cursor incompatibility with `q`. Nothing important is left unexplained.

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?

The schema already covers all parameters at 100%, but the description adds substantial meaning beyond names and types. For `q` it explains the ranked behavior, the no-mid-word-substring restriction, and the special UUID resolution semantics. For `cursor` it warns that it is board- and filter-specific and that a mismatched cursor is a 400. For `updated_since` it recommends passing the previous `server_time` to avoid clock drift. The `include_descriptions` parameter is given quantitative context (78% of a column listing).

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 clear, specific statement: 'Tickets on a board, in board order, optionally filtered by status or by free text.' It names the exact resource (tickets on a board), the operation (listing), and the scoping options. It also distinguishes itself from a sibling tool by noting 'get_board returns the same tickets but takes neither `limit` nor a cursor.'

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 explicitly states when to use this tool ('This is what to read a column or walk a whole board with') and contrasts with get_board. It also gives guidance on paging (stop when next_cursor is absent), on using updated_since for following a board, and on include_descriptions=false to save payload while deferring to get_ticket for full details. This is textbook usage 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/Developyn/laver-mcp'

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