Skip to main content
Glama

update_ticket

Update a ticket on Laver with version-checked writes. Change status, title, priority, due date, description, labels, assignees, custom fields; send the current version to avoid overwriting.

Instructions

Change a ticket. version must be the one from get_ticket; a 409 means somebody wrote first and you should re-read. Markdown in description is parsed, and it replaces the whole description rather than appending to it. label_uuids, assignee_uuids and custom_fields each REPLACE the whole set rather than adding to it, so send what is already on the ticket alongside what you are adding or you will silently remove the rest. custom_fields is keyed by the field's uuid — read them off get_ticket, since a name will not do — and a uuid no field on that board has is DROPPED SILENTLY rather than refused: the call answers 200 and the value is simply not there. The task in the reply carries the stored custom_fields, so read them back to confirm a write landed rather than assuming a 200 means it did.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleNoReplaces the title. Omit to leave it as it is.
statusNoMove it to this column, by name as shown on the board. Send this or `status_uuid`, not both. move_ticket is the tool for a move alone.
versionYesThe `version` from the ticket as you last read it. Not a number you choose or increment: send back exactly what get_ticket gave you. If somebody else has written since, the call answers 409 rather than overwriting them — re-read with get_ticket and retry against the new version.
due_dateNoDue date as an ISO 8601 date, e.g. 2026-08-14. Explicit null clears it; omitting it leaves it unchanged. Those are different, so do not send null to mean 'no change'.
positionNoSort key within the column, not an index — smaller sorts higher. Read the neighbours' `position` off get_board and send a number between them; omit it to append to the bottom. Positions come back as decimal strings ('1000.000000') and are sent as numbers.
priorityNoOne of low, medium, high or urgent. Omit to leave it alone; there is no value here that clears a priority already set.
task_uuidYesThe ticket's uuid, from list_tickets, get_board or search
descriptionNoReplaces the whole body, Markdown, up to 20000 characters — it does not append. To add a line, read the current description with get_ticket and send it back with your addition included.
label_uuidsNoThe ticket's labels, as the complete set after the write — it REPLACES rather than adds, so include the ones already on the ticket or you remove them. Bare uuids, which is the shape get_board returns as `label_uuids`; get_ticket returns expanded objects, so take the uuid out of each. An empty array removes every label.
status_uuidNoMove it to this column, by uuid, from get_board. The exact form of `status`, unaffected by a column being renamed.
custom_fieldsNoCustom field values, keyed by the FIELD's uuid — read them off get_ticket, a field's name will not work. REPLACES the whole set, so send the values already on the ticket alongside the ones you are changing. A key no field on that board has is dropped silently: the call still answers 200 and the value is simply absent, so read `custom_fields` back off the reply to confirm the write landed.
assignee_uuidsNoThe ticket's assignees, as the complete set after the write — it REPLACES rather than adds, so include whoever is already assigned. The uuids come from the board's `members`. An empty array unassigns everyone.
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 excels: it discloses the 409 conflict behavior, whole-set replacement for labels/assignees/custom_fields, silent dropping of unknown custom field UUIDs, and the need to read back custom_fields to confirm writes. This is exemplary behavioral disclosure.

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 a dense paragraph with no wasted words, but it covers a lot of ground. It is appropriately sized for a tool with 12 parameters and many gotchas, though it could benefit from bullet points for readability. Still, every sentence earns its place.

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 (12 params, nested objects, no output schema), the description is remarkably complete. It explains concurrency, replacement semantics, silent failures, and even mentions that the reply carries stored custom_fields. It leaves few unanswered behavioral questions.

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 substantial value by highlighting the most critical param behaviors: version must come from get_ticket, description replaces rather than appends, and the replace semantics for label_uuids, assignee_uuids, and custom_fields. It goes well beyond the baseline by summarizing and reinforcing the schema details.

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 'Change a ticket,' a specific verb and resource. It clearly distinguishes from sibling tools like create_ticket, move_ticket, and comment_on_ticket by implication, and the detailed context about versioning and replace semantics makes the tool's purpose unmistakable.

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

Usage Guidelines3/5

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

The description gives clear context for how to use the tool (version handling, replace semantics) but does not explicitly state when to use it vs alternatives. The schema's status parameter mentions 'move_ticket is the tool for a move alone,' but the description itself lacks that exclusionary 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