superops-mcp

superops_tickets_update

Update an existing ticket's status, priority, assignment, category, or resolution code in SuperOps PSA. Use for structured ticket changes, not free-text notes.

Instructions

Update an existing ticket - change status, priority, assignment, or category. Free-text resolution notes belong in superops_tickets_add_note; only the tenant's configured resolutionCode can be set here.

Input Schema

TableJSON Schema

Name	Required	Description
`impact`	No	New impact. SuperOps ships with: High, Medium, Low. Your tenant may rename or extend this list.
`status`	No	New status. SuperOps ships with: Open, On Hold, Resolved, Closed, Waiting on third party. Your tenant may rename or extend this list.
`subject`	No	New subject/title
`urgency`	No	New urgency. SuperOps ships with: High, Medium, Low. Your tenant may rename or extend this list.
`category`	No	New service category name. SuperOps ships with: Database, Hardware, Help, Network, Software. Your tenant may rename or extend this list.
`priority`	No	New priority. SuperOps ships with: Critical, High, Medium, Low, Very Low. Your tenant may rename or extend this list.
`ticketId`	Yes	The ticket ID to update
`requestType`	No	New request type, e.g. Incident or Service Request
`subcategory`	No	New service subcategory name; must be one of the subcategories defined under the chosen category.
`techGroupId`	No	Group ID of the technician group to assign
`technicianId`	No	User ID of the technician to assign
`resolutionCode`	No	Resolution code, for resolving/closing tickets. SuperOps ships with: Permanent Fix, Workaround, Resolved by Requester, Exception. Your tenant may rename or extend this list.

Schema Changelog

Changes observed during successful MCP inspections.

Changed16 schema fields changedv2.0.2Oct 7, 2026

removedInput schema / properties / assigneeId

Removed value: -{
-  "description": "ID of technician to assign",
-  "type": "string"
-}

addedInput schema / properties / category

Added value: +{
+  "description": "New service category name. SuperOps ships with: Database, Hardware, Help, Network, Software. Your tenant may rename or extend this list.",
+  "type": "string"
+}

addedInput schema / properties / impact

Added value: +{
+  "description": "New impact. SuperOps ships with: High, Medium, Low. Your tenant may rename or extend this list.",
+  "type": "string"
+}

changedInput schema / properties / priority / description

Previous value: -"New priority: Low, Medium, High, Critical"New value: +"New priority. SuperOps ships with: Critical, High, Medium, Low, Very Low. Your tenant may rename or extend this list."

removedInput schema / properties / priority / enum

Removed value: -[
-  "Low",
-  "Medium",
-  "High",
-  "Critical"
-]

addedInput schema / properties / requestType

Added value: +{
+  "description": "New request type, e.g. Incident or Service Request",
+  "type": "string"
+}

removedInput schema / properties / resolution

Removed value: -{
-  "description": "Resolution notes (for resolving/closing tickets)",
-  "type": "string"
-}

addedInput schema / properties / resolutionCode

Added value: +{
+  "description": "Resolution code, for resolving/closing tickets. SuperOps ships with: Permanent Fix, Workaround, Resolved by Requester, Exception. Your tenant may rename or extend this list.",
+  "type": "string"
+}

changedInput schema / properties / status / description

Previous value: -"New status: Open, In Progress, Pending, Resolved, Closed"New value: +"New status. SuperOps ships with: Open, On Hold, Resolved, Closed, Waiting on third party. Your tenant may rename or extend this list."

removedInput schema / properties / status / enum

Removed value: -[
-  "Open",
-  "In Progress",
-  "Pending",
-  "Resolved",
-  "Closed"
-]

addedInput schema / properties / subcategory

Added value: +{
+  "description": "New service subcategory name; must be one of the subcategories defined under the chosen category.",
+  "type": "string"
+}

addedInput schema / properties / subject

Added value: +{
+  "description": "New subject/title",
+  "type": "string"
+}

addedInput schema / properties / techGroupId

Added value: +{
+  "description": "Group ID of the technician group to assign",
+  "type": "string"
+}

removedInput schema / properties / techGroupName

Removed value: -{
-  "description": "Name of technician group to assign",
-  "type": "string"
-}

addedInput schema / properties / technicianId

Added value: +{
+  "description": "User ID of the technician to assign",
+  "type": "string"
+}

addedInput schema / properties / urgency

Added value: +{
+  "description": "New urgency. SuperOps ships with: High, Medium, Low. Your tenant may rename or extend this list.",
+  "type": "string"
+}

First observedv1.2.5Jun 30, 2026

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the resolutionCode-only constraint on the resolution path, which is genuinely useful, but says nothing about partial-update semantics (are omitted fields left unchanged?), required permissions, validity of status transitions, or reversibility for what is 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero filler, with the core capability front-loaded and the disambiguation constraint second. Every clause carries information the agent needs.

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

Completeness3/5

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

For a 12-parameter mutation tool with no annotations and no output schema, the description covers what can be changed and the resolution nuance, but omits partial-update behavior, permission requirements, and any indication of success/failure response. Adequate but with clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3, and the description earns an increment by clarifying that only the tenant-configured resolutionCode belongs here while free-text resolution content must go elsewhere. It does not clarify the assignment pair (technicianId vs techGroupId) or the category/subcategory dependency beyond what the schema states.

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?

States a specific verb (update) plus resource (existing ticket) and enumerates the mutable facets: status, priority, assignment, category. The second sentence distinguishes this tool from superops_tickets_add_note, so an agent can route without opening either 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?

Gives an explicit when-not with the alternative named: free-text resolution notes go to superops_tickets_add_note, and only a configured resolutionCode may be set here. It does not cover update vs. superops_tickets_create or prerequisites, but the boundary case that most easily causes misuse is handled.

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

superops_tickets_update

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools