superops-mcp

superops_tickets_create

Create a new ticket in SuperOps.ai with subject, client ID, and optional fields like priority, status, and category to log support issues.

Instructions

Create a new ticket in SuperOps.ai. Status, priority, category and subcategory are free-text strings that must match the values configured in your SuperOps tenant.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`impact`	No	Ticket impact. SuperOps ships with: High, Medium, Low. Your tenant may rename or extend this list.
`siteId`	No	Client site ID
`source`	No	How the ticket originated (default: INTEGRATION)	INTEGRATION
`status`	No	Initial status; defaults to the tenant's default status. SuperOps ships with: Open, On Hold, Resolved, Closed, Waiting on third party. Your tenant may rename or extend this list.
`subject`	Yes	Ticket subject/title
`urgency`	No	Ticket urgency. SuperOps ships with: High, Medium, Low. Your tenant may rename or extend this list.
`category`	No	Service category name. SuperOps ships with: Database, Hardware, Help, Network, Software. Your tenant may rename or extend this list.
`clientId`	Yes	Client account ID
`priority`	No	Ticket priority. SuperOps ships with: Critical, High, Medium, Low, Very Low. Your tenant may rename or extend this list.
`description`	No	Detailed description of the issue
`requestType`	No	Request type, e.g. Incident or Service Request
`requesterId`	No	User ID of the client user reporting the issue
`subcategory`	No	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

Schema Changelog

Changes observed during successful MCP inspections.

Changed16 schema fields changedv2.0.2Oct 7, 2026

addedInput schema / properties / category

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

removedInput schema / properties / categoryName

Removed value: -{
-  "description": "Service category name",
-  "type": "string"
-}

addedInput schema / properties / impact

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

changedInput schema / properties / priority / description

Previous value: -"Ticket priority: Low, Medium, High, or Critical"New value: +"Ticket 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": "Request type, e.g. Incident or Service Request",
+  "type": "string"
+}

removedInput schema / properties / requesterEmail

Removed value: -{
-  "description": "Email of the person reporting the issue",
-  "type": "string"
-}

addedInput schema / properties / requesterId

Added value: +{
+  "description": "User ID of the client user reporting the issue",
+  "type": "string"
+}

addedInput schema / properties / siteId

Added value: +{
+  "description": "Client site ID",
+  "type": "string"
+}

addedInput schema / properties / source

Added value: +{
+  "default": "INTEGRATION",
+  "description": "How the ticket originated (default: INTEGRATION)",
+  "enum": [
+    "FORM",
+    "AGENT",
+    "EMAIL",
+    "AI",
+    "PHONE",
+    "INTEGRATION",
+    "SCHEDULE",
+    "CONTRACT_REMINDER",
+    "CONTRACT",
+    "INSTANT_MESSAGING"
+  ],
+  "type": "string"
+}

addedInput schema / properties / status

Added value: +{
+  "description": "Initial status; defaults to the tenant's default status. SuperOps ships with: Open, On Hold, Resolved, Closed, Waiting on third party. Your tenant may rename or extend this list.",
+  "type": "string"
+}

addedInput schema / properties / subcategory

Added value: +{
+  "description": "Service subcategory name; must be one of the subcategories defined under the chosen category.",
+  "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 the 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": "Ticket urgency. SuperOps ships with: High, Medium, Low. Your tenant may rename or extend this list.",
+  "type": "string"
+}

Addedv1.6.3Aug 7, 2026
Removedv1.6.0Jul 18, 2026
First observedv1.2.5Jun 30, 2026

TDQS

B3.3/5.0

Behavior3/5

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

No annotations exist, so the description carries full burden. It usefully discloses one real constraint—status/priority/category/subcategory are free-text and must match tenant-configured values—but omits permissions/auth needs, side effects, whether the ticket is auto-assigned, and any response semantics for a 15-param mutation.

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 tight sentences, purpose front-loaded in the first clause and the constraint note second. Every sentence earns its place with no filler.

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?

With 15 parameters, no output schema, and no annotations, the description is thin: it never says what the call returns (e.g., the created ticket ID) or what happens on failure. Parameter documentation is complete via schema, so it is minimum-viable but not sufficient for a mutation of this complexity.

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 the schema already documents all 15 parameters richly (including enum and per-field tenant notes). The description's note about free-text match requirements marginally reinforces four fields but adds little beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Create a new ticket in SuperOps.ai'), which plainly contrasts with siblings like superops_tickets_update, superops_tickets_get, and superops_tickets_list. It is clear, though it never names an alternative to further sharpen the distinction.

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

Usage Guidelines2/5

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

There is no when-to-use/when-not guidance and no mention of alternatives such as tickets_update for existing tickets or add_note for follow-ups. The agent must infer the appropriate context (a genuinely new ticket) from the verb alone.

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

superops_tickets_create

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools