A Claude bridge to Zendesk

All of Zendesk, safely readable - and carefully writable.

zendesk-mcp puts Support tickets and the Help Centre in front of Claude as 48 read tools over 253 operations. Reads can't touch your data. Writes are tiered: notes, status and tags are always on; customer-facing replies stay behind a switch and a confirmation.

Reads can't modify anything Public replies gated + always confirmed
48 tools253 GET operations, Support + Help Centre
Zero-config loginBrowser OAuth, no tokens to manage
Replies OFF by defaultOpt in once, confirm every send

The problem

Answering a ticket means knowing the whole story first.

Before an agent can help anyone, they're deep in Zendesk - the thread, the audits, the customer, the org, the macros - just to reconstruct what happened. zendesk-mcp puts all of it one question away, and lets Claude take the safe actions from the same conversation.

Today, per ticket

  • Open Zendesk, hunt down the ticket and its thread
  • Dig through comments, audits, the user and their org
  • Cross-check macros, tags, SLA and status by hand
  • Copy-paste between Zendesk and every other tool

With zendesk-mcp

  • The ticket, its history and the customer in one conversation
  • Search across tickets and the Help Centre from Claude
  • Draft or send a macro reply, personalised per ticket
  • Note, status, tag - safe writes without leaving the chat

How it works

Login → Read → Act → Reply

Everything up to a customer-facing message is friction-free. The one thing that reaches a customer is the one thing that always asks first.

1

Login

One browser sign-in with PKCE - no client secret, no tokens to manage. Claude refreshes it for you when it expires.

2

Read

48 tools over 253 operations across Support and the Help Centre. Every one is GET-only; none can change your data.

3

Act

Internal notes, status changes, tags and assignment are always available - reversible, agent-only, safe.

4

Reply

Customer-facing replies are gated behind a switch and confirmed on every send. Nothing reaches a customer without your word.

Three tiers of write

Reads can't write. Safe writes are always on. Replies need your word.

The worry with letting an assistant near your helpdesk is that it says the wrong thing to a customer. zendesk-mcp makes that structurally hard - the write surface is split into three tiers, and the customer-facing one is the most guarded.

Public replies are off until you say so.

Flip /zendesk-writes on and every send still prompts - even in auto-accept mode. Flip it off and the tool disappears from Claude's reach entirely.

read · 253 opsGET-only. Can never modify data.
internal notePrivate, agent-only. Always on.
status · assignOpen, pending, solved… reversible. Always on.
tagsAppended, never overwritten. Always on.
public replyGated by /zendesk-writes, confirmed every send.
bulk replyMany tickets, one approval, macro-personalised.

Why it's worth it

Powerful reads, careful writes, nothing to configure.

Reads can't write

Every read tool is a hardcoded GET - no non-GET request can even be expressed through it. Point it at production without a second thought.

Safe writes, always ready

Internal notes, status, tags and assignment are reversible and agent-only. The everyday moves, no switch required.

Customer replies stay gated

Public replies are off by default, behind /zendesk-writes, and confirmed on every send - even in auto-accept mode.

Personalised bulk replies

Send one macro to 10+ tickets on a single approval; Zendesk fills each customer's name server-side, so no name is ever guessed.

Nothing to configure

Browser OAuth with PKCE, no client secret. The token is stored 0600 and refreshed automatically - no env vars, no key management.

Support + Help Centre

40 Support tools and 8 Help Centre tools: tickets, users, orgs, macros, SLAs, triggers, articles, sections and search.

Reads that can't write, replies that can't slip out unapproved. Built to sit safely on a live helpdesk.

GET-only reads

The read bundle contains only GET operations, and the HTTP client hardcodes the method - no read action can express a write. It's read-only by construction, not by convention.

Replies always confirmed

The public-reply tools carry a required-interaction flag and prompt on every call - no "don't ask again", even in bypass mode. A human sees every customer-facing message.

Fails loud, not silent

If your Zendesk role can't post publicly, the tool detects the reply landed as a private note and tells you - no silent misfires disguised as sends.

What it can reach

48 resource tools across Support and the Help Centre.

Grouped the way you'd actually work a ticket - from the thread in front of you out to the SLA and the knowledge base behind it.

TICKETS & PEOPLE

ticketscommentsauditsusersorganizationsgroupsrequests

SEARCH & VIEWS

searchviewssaved searchessuspendedincremental exportticket metrics

AUTOMATION & SLA

macrostriggersautomationsSLA policiesskill-based routingsatisfaction

CONFIG & META

ticket fieldsformscustom statusestagsbrandscustom objectsaudit logs

HELP CENTRE

articlessectionscategoriesHC searchlabelsattachments

WRITE ACTIONS

add internal noteset statusassignadd tagspublic reply *bulk reply *

* gated behind /zendesk-writes and confirmed on every send.

Where it is today

Built, shipped, and in use on the support desk.

Straight with you on status - the reads, the login and the tiered writes are all real and running. What grows is the write surface, added only as each path proves safe.

Live
48 read tools, 253 operations, v1.9.0.

Support tickets and the Help Centre, exposed across the full Zendesk OpenAPI surface - all GET-only.

Live
Zero-config browser login.

Public OAuth client with PKCE, no secret. Token stored 0600 and self-refreshing - nothing to configure or rotate by hand.

Live
Tiered writes.

Internal notes, status, tags and assignment always on; public and bulk replies gated behind /zendesk-writes and confirmed on every send.

Live
Macro-personalised bulk replies.

One macro to 10+ tickets on a single approval, each customer's name filled server-side by Zendesk - never guessed, per-ticket at save time.

Next
More write paths, as they prove safe.

New write actions are added one at a time, each behind the same confirm-and-gate model - the safe surface grows without loosening the guarantees.

One of a family of internal Claude plugins. Scout, the human-in-the-loop support agent, runs on this plugin and on seatfrog-mcp.