Skip to main content
Glama
fruggr

Zendesk MCP Server by Fruggr

by fruggr

List Zendesk Ticket Comments

list_ticket_comments
Read-onlyIdempotent

Fetch paginated ticket comments with full bodies, author, timestamp, and attachment IDs. Use for long threads to avoid response truncation and to see the latest reply first.

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
Install Server

TDQS

A5/5.0
Behavior5/5

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

Annotations already declare readOnly and idempotent, and the description adds behavioral details: cursor-based pagination, default small page size due to response character limits, and what the response contains (comment id, author, timestamp, public/internal flag, attached file ids). This goes beyond annotations to disclose runtime behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but well-structured, using semicolons and explicit cross-references. Every sentence adds value—no fluff or repetition. It efficiently packs purpose, differentiation, pagination, and parameter guidance into a few lines.

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, the description covers the return content, pagination behavior, sort order, and relationship to sibling tools. It addresses the likely questions an agent would have (how to get ticket_id, when to use alternatives) and aligns with the openWorldHint annotation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers all parameters with descriptions, and the tool description augments them: ticket_id source (search_tickets/list_tickets), sort_order semantics (desc starts at newest, asc replays forward), and page_size rationale (deliberately small to avoid truncation). This gives full parameter context beyond 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?

The description clearly states the tool reads a ticket's conversation, specifying the resource (ticket) and the action (list comments). It explicitly differentiates from get_ticket, get_ticket_history, and get_ticket_attachments, making its niche unambiguous for an agent.

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?

It gives explicit usage guidance: prefer this over get_ticket for long threads or when only needing latest exchange, and directs to get_ticket_history for audit trails and get_ticket_attachments for file downloads. It also explains how to use sort_order and cursor for pagination.

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

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/fruggr/zendesk-mcp-server'

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