Partially update a ticket by sending only the fields you want to change, so you can adjust status, priority, assignments, and other details without replacing the whole record.
Partially updates a ticket. Send only the fields you want to change.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Unified partial update for a ticket. | |
| ticketId | Yes | Ticket to update. |
Changes observed during successful MCP inspections.
v1.1.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-read-only but non-destructive, and the description adds the meaningful PATCH contract that omitted fields are untouched. It does not disclose side effects of the update (e.g. array fields replacing entire sets, close-date/audit-field overrides), permission requirements, or error behavior, all of which are relevant for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, and the core partial-update rule is front-loaded. Nothing could be removed without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema is very rich and annotations cover the safety profile, so the description needn't enumerate fields. But for a 20+ field nested mutation with no output schema, it omits what happens on success (does it return the updated ticket?), and gives no warning about the consequential fields (ClosedOn, UpdatedOn, billing override) an agent should handle carefully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the nested body documents all 20+ fields including replacement semantics for asset/uptime arrays. The description adds nothing field-specific beyond the general partial-update rule, which is the correct baseline when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('partially updates') and resource ('a ticket'), and the word 'partially' immediately separates it from a full-replacement or create operation. It doesn't name siblings like gorelo_get_ticket or gorelo_create_ticket, so the differentiation is implicit rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Send only the fields you want to change' gives clear invocation guidance for PATCH semantics, which is the primary usage decision for this tool. However, it never says when to prefer it over alternatives (e.g. status changes via comments/approvals) or notes any prerequisites such as permissions or the ticket needing an existing client.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.