Skip to main content
Glama
fruggr

Zendesk MCP Server by Fruggr

by fruggr
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

List Zendesk Ticket Comments

list_ticket_comments
Read-onlyIdempotent

Read a ticket's public replies and internal notes one paginated page at a time, newest first. Use for long threads or when only the latest exchange is needed.

Instructions

Read a ticket's conversation — public replies and internal notes with their full bodies — one cursor-paginated page at a time, newest comment first. Each entry carries the comment id, the author resolved to a name, the timestamp, whether it is public or internal, and the ids of any attached files. Prefer this over get_ticket(include_comments=true) whenever a thread is long or you only need the latest exchange: get_ticket appends the thread as one unpaginated block and cuts it past the response character limit, which drops the most recent comments first. Keep sort_order "desc" (the default) to read the latest reply first and follow the returned cursor to walk further back in time, or pass "asc" to replay the conversation forward from the ticket's opening description. For who changed which field and when — without comment bodies — use get_ticket_history; to download the attached files themselves, pass the attachment ids shown here to get_ticket_attachments.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cursorNoPagination cursor from a previous response; omit for the first page. Zendesk issues it for the ordering that response used, so after changing sort_order drop the cursor and start again from the first page.
page_sizeNoComments per page (1-100, default 20). The default is deliberately small because comment bodies are long and a bigger page risks being cut short by the response character limit; follow the returned cursor rather than raising it.
ticket_idYesTicket ID — the numeric id of the ticket whose conversation to read. Obtain it from search_tickets or list_tickets.
sort_orderNoChronological direction of the page. "desc" (the default) starts at the most recent comment and walks backward in time, which is what you want to see the latest reply; "asc" replays the conversation forward, starting from the ticket's opening description — that first comment therefore lands on the last page under "desc".desc

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
  2. Addedv2.20.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), so this adds context instead: the truncation behavior of the alternative tool and which end it drops, cursor invalidation when sort_order changes, and the deliberately small default page size rationale. These are non-obvious operational traits an agent cannot infer from annotations or schema.

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-loaded with purpose and returns, followed by tool routing and parameter guidance — a sensible ordering. It is dense and the final sentence runs long, but each clause carries a distinct routing or behavioral fact rather than 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 enumerates the returned fields (comment id, resolved author name, timestamp, public/internal flag, attachment ids), and it covers pagination, ordering, and sibling alternatives. An agent has everything needed to invoke and use the result correctly.

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 much of the parameter detail duplicates the schema (cursor semantics, page_size bounds, sort_order enum). The description still adds decision-level guidance — keep the default 'desc' for the latest reply, follow the cursor rather than raising page_size — which is meaning beyond the raw field definitions.

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 a ticket's conversation — public replies and internal notes with their full bodies') and immediately scopes the retrieval model (cursor-paginated, newest first). It explicitly distinguishes itself from get_ticket, get_ticket_history, and get_ticket_attachments by name.

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 routing rule: 'Prefer this over get_ticket(include_comments=true) whenever a thread is long or you only need the latest exchange,' and explains why (unpaginated block truncated past the character limit, dropping newest comments). It also routes field-change history to get_ticket_history and file downloads to get_ticket_attachments.

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