Skip to main content
Glama
fruggr

Zendesk MCP Server by Fruggr

Get Zendesk Ticket History

get_ticket_history
Read-onlyIdempotent

Retrieve chronological ticket change history showing who changed what and when, including status, priority, assignee, group, tags, and custom fields, with system notifications filtered out for clarity.

Instructions

Read a ticket's change history — its audit trail — as a chronological, oldest-first timeline of who changed what and when. Each entry shows the actor (name and id) and the channel, then the field changes that update carried (status, priority, assignee, group, tags, custom fields) as before → after, with assignee/requester/group ids resolved to names. Comments appear as one-line presence markers (public comment vs internal note added), not their text — fetch the bodies with get_ticket(include_comments=true). Purely system-generated notification events (trigger emails, collaborator/CC notifications, pushes) are filtered out — note this filters notification delivery, not CC-list edits, which are shown as changes — and an update carrying only such events produces no entry, so the timeline stays a readable narrative rather than a raw log. Use it to answer "what happened on this ticket?", "why was it reassigned?" or "when did it go to pending?", reading oldest-first so the founding context is not missed. Read-only, and cursor-paginated oldest-first: pass the returned cursor to page a long-lived ticket toward its most recent changes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cursorNoPagination cursor from a previous response; omit for the first page. The timeline is ordered oldest-first, so paging forward moves toward the most recent changes.
page_sizeNoAudits (ticket updates) per page (1-100, default 100). Each audit is one update to the ticket and may expand to several change lines; audits carrying only system events are dropped, so a page can render fewer entries than this.
ticket_idYesTicket ID — the numeric id of the ticket whose change history to read. Obtain it from search_tickets or list_tickets.
Behavior5/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. Description adds critical behavior: pagination order, filtering of system events, marker for comments, resolution of IDs to names. No contradictions.

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?

Single paragraph but well-structured. Front-loaded with purpose. Every sentence adds value, though slightly lengthy. Could be broken into multiple paragraphs for readability, but not overly verbose.

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?

No output schema, but description thoroughly explains result structure: actor, channel, field changes (before→after), comment markers. Covers pagination, filtering, and usage. Complete for a read-only tool.

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?

Schema coverage is 100% with descriptions. Description adds further context: cursor source, page_size meaning with dropped events, ticket_id origin. Enhances understanding beyond 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 change history (audit trail) as a chronological timeline. It distinguishes itself from siblings like get_ticket (which can fetch comment bodies) and other tools.

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?

Explicitly suggests use cases: answering 'what happened?', 'why reassigned?', etc. Also advises reading oldest-first and mentions that for comment text, use get_ticket. Provides clear guidance on when to use this tool over alternatives.

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

Install Server

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