Skip to main content
Glama

update_ticket

Idempotent

Change a ticket: its status (open, on hold, pending, closed, or one of the workspace's own), its team, who it is assigned to, its priority, its tags, its team fields, whether it is spam, or whether it is kept from auto-delete. Give only what should change.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "ticket_id": "<ticket_id>"
    },
    "name": "update_ticket"
  }
}

Input Schema

NameRequiredDescriptionDefault
keepNotrue keeps a closed ticket from being auto-deleted, false lets it go again. Needs an owner or admin, on a plan that has it.
spamNotrue marks the ticket as spam, false unmarks it.
tagsNoThe ticket's tags, all of them: this replaces the list. Up to 10, each up to 30 characters; [] removes them all.
teamNoThe team it is with, by the team's name as a ticket's `team_name` shows it, or "none".
statusNo"open", "on_hold" (waiting on someone else), "pending" (waiting on the customer) or "closed"; or the name of one of the workspace's own statuses, as a ticket's `status_name` shows it.
priorityNoHow soon it should be looked at: "low", "normal", "high" or "urgent".
assign_toNoA teammate's id from list_teammates, or "nobody" to unassign.
ticket_idYesThe ticket's id (a uuid), from list_tickets.
team_fieldsNoThe team's own fields to set, by key, each to its value as text; null clears one. A ticket's `team_values` shows them.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / team_fields / additionalProperties
      Added value: +true
    • addedInput schema / properties / team_fields / type
      Added value: +"object"
  2. Changed7 schema fields changed
    • changedInput schema / properties / assign_to / type
      Previous value: -[
      -  "string",
      -  "null"
      -]New value: +"string"
    • changedInput schema / properties / keep / type
      Previous value: -[
      -  "boolean",
      -  "null"
      -]New value: +"boolean"
    • changedInput schema / properties / priority / type
      Previous value: -[
      -  "string",
      -  "null"
      -]New value: +"string"
    • changedInput schema / properties / spam / type
      Previous value: -[
      -  "boolean",
      -  "null"
      -]New value: +"boolean"
    • changedInput schema / properties / status / type
      Previous value: -[
      -  "string",
      -  "null"
      -]New value: +"string"
    • changedInput schema / properties / tags / type
      Previous value: -[
      -  "array",
      -  "null"
      -]New value: +"array"
    • changedInput schema / properties / team / type
      Previous value: -[
      -  "string",
      -  "null"
      -]New value: +"string"
  3. First observed

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare readOnly=false, idempotent=true, destructive=false, so the safety profile is carried. The description adds the partial-update semantic, which is genuinely useful. However, it omits the one non-obvious hazard: supplying `tags` replaces the entire list, which is in tension with "give only what should change" — an agent skimming the description alone could clear tags by accident.

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?

One front-loaded sentence naming the resource and the changeable facets, closed by a short imperative. No filler, nothing to trim.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter mutation with rich per-field schema descriptions and annotations covering idempotency and non-destructiveness, the definition is nearly sufficient. The remaining gap is the absence of any statement about the result of the call (no output schema, and the description says nothing about what is returned or about no-op/unchanged tickets).

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?

Schema description coverage is 100%, so every parameter is already documented with enums, formats, and source-of-truth hints (`status_name`, `team_name`, `list_teammates`). The description restates the field list but adds no syntax or format details beyond the schema. Baseline 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?

Specific verb plus resource ("Change a ticket") followed by an exhaustive enumeration of the mutable facets: status, team, assignee, priority, tags, team fields, spam, and keep-from-auto-delete. An agent can distinguish this from get_ticket, reply_to_ticket, and the other update_* siblings without opening any schema.

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?

"Give only what should change" establishes that this is a partial/patch operation, so the agent knows to send a minimal body rather than a full ticket representation. It does not discuss prerequisites (e.g. that `keep` needs an owner/admin) or when a different sibling should be used, but for an update tool of an obvious resource the invocation context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources