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

Zendesk MCP Server by Fruggr

by fruggr
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get Zendesk Ticket Attachments

get_ticket_attachments
Read-onlyIdempotent

Fetch files attached to a ticket's comments, returning images embedded inline and other files as references with name, id, content type, size, and download URL.

Instructions

Download the files attached to a ticket's comments so you can look at them: images come back embedded inline, other files as text references (file name, id, content type, size, download URL). Use it to see an attached image, or a file's name, size and download URL (only images come back with their content); to learn which files a comment carries, list_ticket_comments already shows their ids. Pass those ids as attachment_ids to fetch only them, or omit it to collect the attachments of the ticket's comments, read up to a page cap (10 pages of 100 comments by default); past it the response says later comments were not scanned, and attachment_ids fetches their files. An image over the per-image size limit or past the embedded-image cap comes back as a reference saying why, and once the response size budget is spent the remaining files are counted as omitted.

Input Schema

NameRequiredDescriptionDefault
ticket_idYesTicket ID — the numeric id of the ticket whose attachments to fetch. Obtain it from search_tickets or list_tickets.
attachment_idsNoAttachment IDs to fetch directly (e.g. extracted from a previous list_ticket_comments or get_ticket(include_comments=true) call). When provided, skips the comments fetch entirely. When omitted, the attachments of the ticket's comments are returned, read up to a page cap: on a very long thread the scan stops there, and the response says so.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.7.0
    • changedInput schema / properties / attachment_ids / description
      Previous value: -"Attachment IDs to fetch directly (e.g. extracted from a previous list_ticket_comments or get_ticket(include_comments=true) call). When provided, skips the comments fetch entirely. When omitted, all attachments of the ticket are returned."New value: +"Attachment IDs to fetch directly (e.g. extracted from a previous list_ticket_comments or get_ticket(include_comments=true) call). When provided, skips the comments fetch entirely. When omitted, the attachments of the ticket's comments are returned, read up to a page cap: on a very long thread the scan stops there, and the response says so."
  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. Changed1 schema field changedv2.20.0
    • changedInput schema / properties / attachment_ids / description
      Previous value: -"Attachment IDs to fetch directly (e.g. extracted from a previous get_ticket(include_comments=true) call). When provided, skips the comments fetch entirely. When omitted, all attachments of the ticket are returned."New value: +"Attachment IDs to fetch directly (e.g. extracted from a previous list_ticket_comments or get_ticket(include_comments=true) call). When provided, skips the comments fetch entirely. When omitted, all attachments of the ticket are returned."
  4. Changed1 schema field changedv2.6.0
    • changedInput schema / properties / ticket_id / description
      Previous value: -"Ticket ID"New value: +"Ticket ID — the numeric id of the ticket whose attachments to fetch. Obtain it from search_tickets or list_tickets."
  5. Changed1 schema field changedv2.3.1
    • addedInput schema / additionalProperties
      Added value: +false
  6. First observedv1.7.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial operational detail beyond them: a 10-page-of-100-comments scan cap with a notice in the response, per-image size limits, an embedded-image cap, and a response-size budget that converts remaining files into an 'omitted' count. These are exactly the degradations an agent needs to anticipate.

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 the action and the return shape, and every clause carries real information (caps, fallbacks, truncation signals) rather than padding. The middle sentence is dense and parenthetical-heavy, making the alternative-to-sibling guidance harder to scan than it needs to be.

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?

There is no output schema, so the description carries the return-format burden and does: images embedded inline, other files as references with name, id, content type, size and URL, plus explicit explanation of partial results. For a 2-parameter read tool, nothing needed for a correct call 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 100%, so the baseline is 3, but the description adds meaning the schema only implies: attachment_ids skips the comments fetch entirely, while omitting it triggers the page-capped comment scan and the truncation message. It also tells the agent where ids come from and how to recover files from unscanned comments.

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 + resource: 'Download the files attached to a ticket's comments.' It also distinguishes itself from the nearest sibling by noting that list_ticket_comments returns attachment ids rather than content, so an agent can pick correctly without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete use cases ('to see an attached image, or a file's name, size and download URL') and routes metadata-only needs to list_ticket_comments. It also explains the two invocation modes (pass attachment_ids vs. omit). It stops short of explicit exclusions such as 'do not use for full comment text.'

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