Skip to main content
Glama
BenjaminJ

enterprise-mcp-gateway

by BenjaminJ
OverviewSchemaRelated ServersScoreDiscussions
Go
Hybrid

createSupportTicket

Open and route a new customer support incident ticket into the CRM queue. Escalate technical issues, report system bugs, or file service requests that require support team intervention.

Instructions

Open and route a new customer support incident ticket - Creates a new support incident or customer inquiry ticket in the CRM queue.

[Usage Guidelines]

  • When to use: Use this tool to escalate customer technical issues, report system bugs, or file service requests that require support team intervention.

  • When NOT to use: Do NOT use this tool before checking if a similar ticket already exists; use 'listSupportTickets' first to prevent duplicate tickets. Do NOT use to reset passwords; use 'adminResetPassword' instead.

  • Prerequisites: Requires a confirmed customerId obtained from 'listCustomers' or 'getCustomerDetails'.

[Behavior]

  • Operation: Mutating and non-idempotent. Each invocation assigns a new unique ticket ID and dispatches notifications to support engineers.

  • Side effects: Creates a persistent ticket record and routes to on-call queues.

  • Authorization: Requires 'support_agent' or 'admin' role ('readonly_agent' tokens are rejected with 403).

[Parameters & Validation]

  • 'customerId' (string, required): Customer identifier string (e.g. 'cust-001') the ticket is filed on behalf of.

  • 'subject' (string, required): Concise summary line of the incident (10 to 120 characters).

  • 'description' (string, required): Detailed problem statement, reproduction steps, or error messages.

  • 'priority' (string, optional): Urgency level: 'low', 'normal', 'high', or 'urgent'. Defaults to 'normal' if omitted.

[Returns]

  • Returns HTTP 201 Created with JSON object: ticketId (e.g. 'tick-902'), customerId, subject, priority, status ('open'), and createdAt timestamp.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
subjectYesConcise summary line or title describing the core problem (e.g., 'Database latency issue on invoice generation'). Between 10 and 120 characters.
priorityNoUrgency priority level for routing and SLA dispatch. Defaults to 'normal' when omitted. Use 'urgent' only for total outages.normal
customerIdYesUnique customer ID associated with this support request (e.g., 'cust-001'). Must be an existing account identifier.
descriptionYesFull detailed explanation of the incident, steps to reproduce, user impact, or relevant error codes.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed4 schema fields changedv1.0.3
    • changedInput schema / properties / customerId / description
      Previous value: -"The customer ID associated with this support request (e.g., 'cust-001')."New value: +"Unique customer ID associated with this support request (e.g., 'cust-001'). Must be an existing account identifier."
    • changedInput schema / properties / description / description
      Previous value: -"Detailed explanation of the customer issue, reproduction steps, or question."New value: +"Full detailed explanation of the incident, steps to reproduce, user impact, or relevant error codes."
    • changedInput schema / properties / priority / description
      Previous value: -"Urgency priority level for the ticket routing."New value: +"Urgency priority level for routing and SLA dispatch. Defaults to 'normal' when omitted. Use 'urgent' only for total outages."
    • changedInput schema / properties / subject / description
      Previous value: -"Brief summary or title of the support issue (e.g., 'Database latency issue')."New value: +"Concise summary line or title describing the core problem (e.g., 'Database latency issue on invoice generation'). Between 10 and 120 characters."
  2. Changed10 schema fields changedv1.0.1
    • addedInput schema / properties / customerId / description
      Added value: +"The customer ID associated with this support request (e.g., 'cust-001')."
    • addedInput schema / properties / customerId / example
      Added value: +"cust-001"
    • addedInput schema / properties / description / description
      Added value: +"Detailed explanation of the customer issue, reproduction steps, or question."
    • addedInput schema / properties / description / example
      Added value: +"Customer reported timeouts when generating PDF invoices for Q3."
    • addedInput schema / properties / priority / default
      Added value: +"normal"
    • addedInput schema / properties / priority / description
      Added value: +"Urgency priority level for the ticket routing."
    • addedInput schema / properties / priority / enum
      Added value: +[
+  "low",
+  "normal",
+  "high",
+  "urgent"
+]
    • addedInput schema / properties / priority / example
      Added value: +"high"
    • addedInput schema / properties / subject / description
      Added value: +"Brief summary or title of the support issue (e.g., 'Database latency issue')."
    • addedInput schema / properties / subject / example
      Added value: +"Database latency issue on invoice generation"
  3. First observedv1.0.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description fully discloses that the operation is mutating and non-idempotent, that each call assigns a new ticket ID and dispatches notifications, that it creates a persistent record, and that authorization requires support_agent or admin with readonly_agent rejected. This exceeds the burden normally placed on the description.

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?

Description is organized into labeled sections and front-loaded with the core operation. The opening line is slightly redundant ('Open and route' vs 'Creates a new support incident'), but the structure makes the content immediately scannable and every section carries actionable information.

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?

For a four-parameter mutating tool with no annotations and no output schema, the description covers operation semantics, side effects, authorization guards, usage exclusions, prerequisites, parameter validation rules, and the exact HTTP response shape. Nothing an agent needs to call it correctly is missing.

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 itself documents all four parameters with types, defaults, enums, and examples. The description's Parameters & Validation section largely restates the schema, adding minor context (e.g., 'filed on behalf of') but no substantial new meaning, so 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?

States a specific verb ('Creates', 'Open and route'), resource ('customer support incident ticket'), and context ('CRM queue'). It clearly distinguishes from sibling listSupportTickets by framing this as creation rather than retrieval, and names the operation the tool performs.

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

Usage Guidelines5/5

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

Contains explicit When to use / When NOT to use sections, naming listSupportTickets as a duplicate-prevention step and adminResetPassword as the alternative for password resets. Also gives a concrete prerequisite: confirmed customerId from listCustomers or getCustomerDetails.

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/BenjaminJ/enterprise-mcp-gateway'

If you have feedback or need assistance with the MCP directory API, please join our Discord server