Skip to main content
Glama

get_ticket

Get a complete ticket with its subtasks, expanded labels, and current version. Read before writing to handle concurrent edits; a 409 means the ticket changed, so re-fetch and retry.

Instructions

One ticket in full: its fields, its subtasks, its expanded labels objects, and the version every write needs. Read this before you write. update_ticket, move_ticket, archive_ticket and the rest all take that version and answer 409 if it has moved on since you read it — that 409 is the signal to call this again and retry against the fresh version, never to drop the version or force the write. labels arrive expanded rather than as bare uuids because this reply carries no board dictionary to resolve them against; get_board returns label_uuids instead, and that bare-uuid shape is the one update_ticket wants. A ticket you cannot open answers 404, the same 404 as one that never existed, so a 404 here is not proof the ticket is gone.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
task_uuidYesThe ticket's uuid, from list_tickets, get_board or search
Behavior5/5

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

With no annotations, the description carries the full burden. It discloses the expanded label format and why (no board dictionary in this response), the 409/version interaction, and the ambiguous 404 ('the same 404 as one that never existed'). This is rich behavioral context beyond a simple 'get a ticket' statement, exactly what an agent needs to interpret responses correctly.

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 dense but every sentence adds value: response contents, usage guidance, label format explanation, and error semantics. It is front-loaded with the core meaning and structured logically, making it efficient despite its length.

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?

There is no output schema, so the description must cover return values and edge cases. It explains the essential parts of the response (version, expanded labels) and clarifies error semantics (409 retry, ambiguous 404). Given the tool's simplicity (one parameter) and the thorough description, the agent has everything needed to invoke it correctly.

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?

The input schema already provides 100% description coverage for the only parameter, `task_uuid`, including its source. The description adds no additional parameter-specific semantics, so the baseline score 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 opens with 'One ticket in full: its fields, its `subtasks`, its expanded `labels` objects, and the `version` every write needs.' This is a specific verb+resource with a clear scope, and it implicitly distinguishes get_ticket from siblings like list_tickets or get_ticket_comments by enumerating what is included in the full ticket representation.

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?

Explicitly instructs 'Read this before you write' and explains that update_ticket, move_ticket, and archive_ticket all require the version field and will respond with 409 if it is stale. It further details the retry behavior and clarifies the difference between get_ticket's expanded labels and get_board's bare `label_uuids`, leaving no doubt about when 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.

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