MCP field guide / Zendesk
// mcp field guide · support
Reading and triaging tickets is safe. The sharp edge is a public reply — it emails the customer, and you can't un-send it. Worse: in the popular community server, the comment tool defaults to public, so an agent that means to leave an internal note can email the customer by omission. That's exactly why a guard has to read the public flag, not trust the tool name.
GUARD FIT · READS + TRIAGE + NOTES
LOWRead tickets/threads, knowledge base, and internal notes change nothing customer-facing. Let them flow.
GUARD FIT · PUBLIC REPLY + DELETES
STRONGA public comment emails the customer (irreversible); deletes (where exposed) are consequential. Gate on the effective public value.
Overall fit: MODERATE → STRONG — concentrated on the customer-facing reply.
Zendesk itself ships MCP in two directions: an MCP client (its AI agents calling out to external MCP servers as action-flow steps) which is documented and in early access, and a first-party MCP server (letting external agents act inside Zendesk, per-tenant at <subdomain>.zendesk.com/api/mcp over OAuth) announced for early access in 2026 — whose exact tool surface isn't clearly documented yet.1 For "an MCP server that exposes Zendesk to an agent" today, the community reminia/zendesk-mcp-server (Python, Apache-2.0) is the de-facto reference; michaelrice/zendesk-mcp is a smaller alternative notable for a safer comment design.23
Names below are from the community reminia server; the first-party server's tool names are unverified (early access).
| Tier | Tools |
|---|---|
| read-only | get_tickets, get_ticket, get_ticket_comments, the zendesk://knowledge-base resource, and the analyze-ticket/draft-ticket-response prompts (produce text, send nothing) |
| mutating | create_ticket, update_ticket (status/priority/assignee/tags); an internal note (agent-only) — in michaelrice a separate zendesk_post_internal_note |
| consequential | create_ticket_comment — public=true emails the customer (irreversible once sent). Delete ticket/user is not exposed by either community server. |
The public-by-default trap. In the reminia server, create_ticket_comment calls post_comment(..., public: bool = True) — so a comment goes out as a customer-facing email unless the caller explicitly sets public=false. A model that "just adds a note" can email the customer by omission, with no dry-run. The safer design (michaelrice) splits public reply and internal note into two tools. Either way: a guard must key on the effective public value at call time, not the tool name.
Triage & summarization. Read a long thread, summarize for escalation/handoff, apply tags/routing via update_ticket.
Grounded reply drafting. Pull Help Center content + ticket history, produce a draft (draft-ticket-response) for a human to review before sending.
Backlog analytics. Natural-language questions over tickets ("common themes in billing tickets last month") — reads only.
Reads, triage, and internal notes → weak. get_*, knowledge-base reads, and the analyze/draft prompts change nothing customer-facing; an internal note is agent-only. Let them flow.
The public reply → strong. This is the Slack/Twilio-class hazard aimed at a customer: once the comment posts public, Zendesk emails the requester and it can't be un-sent. Gate every public reply with a human-readable diff — recipient, ticket, full body, and the resolved public flag surfaced explicitly — because the danger lives in a parameter, not the tool name.
Deletes → strong where present. Not exposed by the two leading community servers, but if a server (including Zendesk's write-scoped first-party one) exposes ticket/user delete: Zendesk soft-deletes first (recoverable within a window), then a separate permanent delete that's irreversible — gate both.
The honest line: an internal note is genuinely safe — but only if the server distinguishes it as its own tool or the caller reliably sets public=false. Where note and public reply are the same tool with a public-by-default flag, "it's just a note" can't be trusted; classify by the effective public value. Gate the consequence, read the parameters.
ChronoMCP classifies a Zendesk comment by its resolved public flag — holding customer-facing replies for a human while reads and internal notes flow.
reminia/zendesk-mcp-server (post_comment public-by-default, verified in source): github.com/reminia/zendesk-mcp-servermichaelrice/zendesk-mcp (splits public reply vs internal note): github.com/michaelrice/zendesk-mcpProfiles describe third-party software from its public sources; ChronoMCP is not affiliated with Zendesk, and the community servers are independent, unofficial projects. Zendesk's first-party MCP server is early-access and its tool surface is unverified; multiple community servers exist with differing tool coverage — inspect the running server's tools/list before trusting any name. Risk groupings are our classification. Sources current as of Aug 2026 — check the source links.