Skip to main content
Glama
hajekd
by hajekd

list_tickets

Retrieve tickets with optional filters such as category, stage, priority, agent, contact, date, or search text. Get a paginated list to locate specific tickets.

Instructions

List tickets with optional filters. Returns one page of results.

Args: category: Filter by category internal name (use list_ticket_categories to find valid names). stage: Ticket lifecycle stage — exact values (case-sensitive): 'OPEN' = agent actively working on it, 'WAIT' = reply sent, awaiting customer response, 'CLOSE' = resolved/solved, 'ARCHIVE' = resolved and archived. When user says "open tickets", use stage='OPEN'. priority: Filter by priority: LOW, MEDIUM, HIGH. user: Agent name — pass either a display name (e.g. 'John Doe') or login name (e.g. 'john.doe'). Display names are resolved automatically. You do NOT need to call list_users first. contact: Filter by contact internal ID (e.g. 'contact_674eda46162a8403430453'). NOT a person's name — call list_contacts(search='...') first to find the ID. search: Full-text search across ticket title and description (partial match). status: Filter by workflow status name (e.g. 'S0-Qualify', 'S1-Discovery'). Use list_statuses to see available status names. This filters on the ticket's statuses MN relation — useful for sales pipeline stages, custom workflows, etc. date_from: Filter tickets created on or after this date (YYYY-MM-DD). date_to: Filter tickets created on or before this date (YYYY-MM-DD). include_merged: Include tickets that were merged into other tickets (default: false). sort: Field to sort by. Useful values: edited (default), created, sla_deadtime, sla_close_deadline, last_activity. sort_dir: Sort direction: asc or desc (default: desc). skip: Number of records to skip for pagination (default: 0). take: Number of records to return (default: 50, max: 200).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
skipNo
sortNoedited
takeNo
userNo
stageNo
searchNo
statusNo
contactNo
date_toNo
categoryNo
priorityNo
sort_dirNodesc
date_fromNo
include_mergedNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

With no annotations, the description fully discloses behavioral details: pagination ('Returns one page of results', 'skip', 'take' max 200), case-sensitivity and exact values for stage, automatic resolution of display names ('You do NOT need to call list_users first'), the need to call list_contacts for contact internal IDs, and the 'statuses MN relation' behavior. This is comprehensive and transparent.

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 opens with a concise summary, then uses a structured, scannable list for parameters. Each parameter is explained in one or two lines with clear formatting. Despite the length (14 parameters), every sentence adds value. No fluff or repetition.

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?

For a tool with 14 parameters and no annotations, the description covers all necessary context: filtering semantics, pagination defaults, sort options, and cross-tool dependencies. Having an output schema means return values need no explanation. The description is sufficiently complete for an agent to select and invoke the tool 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 description coverage is 0%, so the description must fully compensate. All 14 parameters are described with formats, defaults, examples, and cross-tool references. For instance, 'contact' clearly states it is an internal ID and explains how to find it via list_contacts. 'sort' lists valid values. This is exemplary parameter documentation.

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 clearly states the tool's function: 'List tickets with optional filters. Returns one page of results.' The verb 'List' with resource 'tickets' makes it distinct from siblings like get_ticket (single ticket) and count_tickets (count). The scope is well-defined.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides effective context on when to use the tool, including a direct example: 'When user says "open tickets", use stage='OPEN'.' It also cross-references related tools for parameter validation (list_ticket_categories, list_statuses, list_contacts) and clarifies when not to call list_users. However, it does not explicitly state when NOT to use this tool over alternatives like get_ticket or list_account_tickets.

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/hajekd/mcp-daktela'

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