Skip to main content
Glama
Zendesk MCP Server by Fruggr

Zendesk MCP Server by Fruggr

List SLA Alerts

list_sla_alerts
Read-onlyIdempotent

List SLA alerts for breached or soon-to-breach tickets, ordered by urgency, and choose tickets by scope, view, or query so teams can prioritize at-risk requests.

Instructions

List the SLA metrics that are breached or about to breach across a set of tickets, most urgent first. Pick the set with exactly one of scope (mine, my_groups or all unsolved tickets), view (a Zendesk view by title or id) or query (any Zendesk ticket search). Each running metric that is breached, or closer to its breach than its CRITICAL or WARNING threshold, is one line under BREACHED, CRITICAL or WARNING, soonest breach first, with the ticket id, metric, time left or overdue, subject, status and priority; paused and achieved metrics never appear. Thresholds are per metric family (reply metrics vs every other metric), the caller's own when set with configure_sla_alerts, else the server's; warning and critical override them for this call only. When no set is given the client may be asked which one, otherwise it defaults to the caller's own tickets and says so; on a user's first call the thresholds are shown too (in that form, or in the reply), and thresholds edited there apply to this call only. Never changes Zendesk; its one side effect is remembering, in this connector's own per-user state, that the user has been shown the thresholds. Results are cached per user for about a minute, and a set larger than a few hundred tickets is read in part, with a notice. For one ticket's full SLA state use get_ticket; for elapsed times use get_ticket_metrics.

Input Schema

NameRequiredDescriptionDefault
viewNoA Zendesk view to check, by its exact title (matched case-insensitively) or numeric id, as listed by list_views. Use instead of scope or query.
queryNoA Zendesk ticket search query selecting the tickets to check, e.g. "status<solved priority:urgent" or "organization:acme status<solved"; "type:ticket" is added automatically. Use instead of scope or view.
scopeNoA named set of unsolved tickets: "mine" (assigned to you), "my_groups" (in any group you belong to) or "all" (the whole account, as far as your role sees it). Use instead of view or query.
withinNoOnly list alerts breaching within this time from now (breached ones aside, see include_breached). A readable duration: 30m, 4h, 2d, 1w, or a mix like 1d4h. Omit to list everything inside the thresholds.
warningNoOverride the WARNING threshold of every metric family for this call only: how much time left before a breach counts as a warning. Given alone, a family's critical threshold is lowered to it where longer. A readable duration: 30m, 4h, 2d, 1w, or a mix like 1d4h.
criticalNoOverride the CRITICAL threshold of every metric family for this call only. Given alone, a family's warning threshold is raised to it where shorter; given with warning, it must not exceed it. A readable duration: 30m, 4h, 2d, 1w, or a mix like 1d4h.
include_breachedNoWhether to list metrics already past their deadline (BREACHED). Defaults to true; set false to see only what can still be saved.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.5.0

TDQS

A4.8/5.0
Behavior5/5

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

Goes well past the readOnly/idempotent annotations: results are cached per user for about a minute, sets larger than a few hundred tickets are partially read with a notice, paused and achieved metrics never appear, and thresholds are resolved per metric family. It even discloses the one side effect (remembering in per-user state that thresholds were shown) rather than hiding it behind readOnlyHint.

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?

Dense but front-loaded, leading with purpose and the scope/view/query choice before the output-format and threshold detail. The single long semicolon-chained sentence carrying the display-format rules is harder to scan than it needs to be, but little of the content is filler for a seven-parameter tool.

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 read-only list tool with no output schema, the agent gets output shape (one line per metric under BREACHED/CRITICAL/WARNING with id, metric, time left, subject, status, priority), caching and truncation behavior, threshold resolution order, and where to go for adjacent needs. Nothing material is missing.

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 coverage is already 100%, but the description adds real meaning: the mutual exclusivity of scope/view/query, how a lone warning lowers critical and a lone critical raises warning, and that each running metric is only listed if closer to breach than its threshold. The within/include_breached interaction is described but only by pointing back at the schema.

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 and resource ("List the SLA metrics that are breached or about to breach across a set of tickets, most urgent first") including the ordering and the inclusion rule. It also explicitly distinguishes itself from get_ticket and get_ticket_metrics, which are the closest siblings.

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?

Gives an explicit selection rule — "exactly one of scope (...) view (...) or query" — and names the follow-up tools for the adjacent jobs (get_ticket for a single ticket's SLA state, get_ticket_metrics for elapsed times). It also documents the no-argument fallback: the client may be prompted, otherwise it defaults to the caller's own tickets and says so.

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