Skip to main content
Glama
Sign In
Zendesk MCP Server by Fruggr

Zendesk MCP Server by Fruggr

by fruggr
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get Tickets In A View

get_view_tickets
Read-onlyIdempotent

Read tickets in a Zendesk view using its configured sort order, matched by title or numeric ID, with cursor pagination and each ticket's next SLA breach shown.

Instructions

Read the tickets inside a Zendesk view, in the view's own configured sort order — the same order the agent sees in the Zendesk UI — which is the natural way to work a named queue like "Unassigned tickets" or "Breaching today". Accepts the view by title or by numeric id (discover both with list_views); a title is matched case-insensitively against the agent's active views, and on no match the available titles are returned so you can retry in one step. Tickets come back with the same fields as list_tickets and are cursor-paginated. Each ticket an SLA policy covers also shows its next SLA breach: only the one metric closest to breaching, read from the view itself at no extra cost (use get_ticket or search_tickets for every metric). sort_by/sort_order override the view's order when you want a different cut. Each ticket's description is cut to a 200-character excerpt; get_ticket returns it in full.

Input Schema

NameRequiredDescriptionDefault
viewYesThe view to read: its exact title as shown in Zendesk (e.g. "Unassigned tickets") or its numeric id from list_views. A title is matched case-insensitively against your active views; on no match the tool returns the available titles instead of erroring, so you can retry with a correct one.
cursorNoPagination cursor from a previous response; omit for the first page.
sort_byNoOptional column to sort by, overriding the view's own sort. Must be one of the view's columns (e.g. "status", "priority", "updated_at", or a custom field id); "subject" and "submitter" are not sortable. Omit to keep the view's configured order.
page_sizeNoTickets per page (1-100, default 25).
sort_orderNoSort direction applied to sort_by: "asc" (oldest/lowest first) or "desc" (newest/highest first). Only meaningful together with sort_by; omit to keep the view's configured direction.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv3.5.2
    • changedInput schema / properties / page_size / default
      Previous value: -100New value: +25
    • changedInput schema / properties / page_size / description
      Previous value: -"Tickets per page (1-100, default 100)."New value: +"Tickets per page (1-100, default 25)."
  2. Changed1 schema field changedv2.24.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  3. Addedv2.11.0

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, yet the description still adds real behavior: title matching is case-insensitive, a no-match returns available titles rather than erroring, results are cursor-paginated, descriptions are truncated to a 200-character excerpt, and only the closest SLA metric is included. What it doesn't state is result size/limits or what happens with an unknown numeric id — a small remaining gap.

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?

Front-loads purpose and sort-order semantics, then layers in matching behavior, pagination, SLA, and truncation — each sentence carries information. It is dense with em-dash parentheticals and slightly longer than needed, but no sentence is filler.

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?

With no output schema, the description still tells the agent what comes back (same fields as list_tickets, cursor pagination, next-SLA-breach field, 200-char description excerpt). Combined with the fully documented schema and safety annotations, an agent has everything needed to call this correctly on the first try.

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 100%, so baseline is 3, but the description adds semantic framing the schema only implies: the view is addressed by title or numeric id with a recoverable no-match path, and sort_by/sort_order are positioned as overrides of the view's configured order rather than the default behavior. That override relationship is the key thing an agent must understand before passing those optional params.

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 ('Read the tickets inside a Zendesk view') plus the defining scope: the view's own configured sort order. It cleanly separates itself from siblings by naming list_views for discovery, list_tickets as the field-equivalent, and get_ticket/search_tickets for full data.

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 explicit when-to-use framing ('the natural way to work a named queue like "Unassigned tickets"'), names list_views as the prerequisite for discovering the view argument, and routes agents elsewhere for adjacent needs: get_ticket or search_tickets for every SLA metric, get_ticket for the full description.

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

Deploy Server

Other Tools