custsupport
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BQ_PROJECT_ID | Yes | Your own Google Cloud project ID, used for BigQuery access. Set in .env as BQ_PROJECT_ID. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_open_ticketsA | List open support tickets, optionally filtered by category, persona, or priority. Read-only. Returns ticket_id, created_at, category, persona, priority, subject, body, status, sla_hours for each match. |
| get_ticketA | Get full detail on a single ticket by its ticket_id. Read-only. Returns an empty dict if the ticket_id doesn't exist. |
| sla_breachesA | List all open tickets that have already exceeded their SLA window, ordered by how badly overdue they are (most overdue first). Read-only. |
| category_breakdownA | Aggregate ticket counts grouped by category, priority, and status — useful for seeing what's piling up in the queue. Read-only. |
| sla_risk_summaryA | Summarize SLA risk across the open queue: how many tickets are already breached vs. approaching their SLA deadline (over 75% of their SLA window elapsed but not yet breached). Read-only. |
| daily_digestA | Generate a plain-text summary of the current ticket queue: total open tickets, SLA risk, and a breakdown by category/priority/status — the kind of summary you'd post to a team channel each morning. Read-only and deterministic (pure aggregation of BigQuery data, no LLM involved). |
| draft_replyA | Generate a suggested reply to a ticket via a local LLM (Ollama). Read-only — this does NOT send anything or modify the ticket. A human should review the draft before using it; if approved, call update_ticket_status separately to record the outcome. |
| suggest_escalationA | Heuristic escalation recommendation for a ticket, based on SLA breach status and priority. Read-only — recommends whether a human should escalate; does not escalate anything itself. |
| update_ticket_statusA | WRITE operation — the only tool in this server that modifies data. Updates a ticket's status ('open', 'pending', or 'resolved') in BigQuery, optionally attaching a note. Intended to be called only after a human has reviewed and approved a draft_reply or suggest_escalation result — never autonomously. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Tools are largely distinct, but aggregation tools like daily_digest, category_breakdown, and sla_risk_summary overlap in the data they summarize, which could lead to misselection. Descriptions clarify their differences, but the boundary between daily_digest and category_breakdown is subtle.
Names follow snake_case and are generally clear, but mix verb-first (list_open_tickets, get_ticket) with noun-first patterns (sla_breaches, category_breakdown). Despite the mix, the naming is predictable and readable, with no camelCase or chaotic variations.
9 tools is well within the ideal 3-15 range for a focused domain. Each tool covers a distinct part of the support workflow—listing, detail, aggregation, SLA monitoring, draft replies, escalation, and status updates—without redundancy or bloat.
The surface covers the main support lifecycle: read (list, get), aggregate (breakdowns, SLA risk), assist (draft reply, escalation), and write (update status). Minor gaps exist, such as no tool to create or assign tickets, but these may be handled externally. The core workflow is well supported with no dead ends.