Zendesk MCP Server

Zendesk MCP Server

A Model Context Protocol (MCP) server that puts Zendesk inside your AI assistant, for both sides of the conversation.

For agents: it finds answers in the Help Center; drafts, updates and translates articles while keeping the languages in sync; and handles Support tickets end to end, comments, triage and image attachments included.

For your customers: the Help Center's "Submit a request" form, in plain language: pick the request, answer its questions, follow the replies, close it. See End-user mode.

For your Zendesk admins: teach the assistant how *your* team works, with house tone, lexicon, procedures and ready-made workflows, from a dedicated back-office, with no redeploy. See Context and customizations.

It all happens in plain language, without switching apps.

It does roughly what the Zendesk agent for Microsoft 365 Copilot does, minus the tie to one vendor: it drops into any MCP client (Claude Desktop, Claude Code, Cursor, VS Code, and the rest). And it always acts with each user's own Zendesk permissions, never a shared admin key.

What your assistant can do

Ask in natural language; the assistant works out the context and the intent, then calls the right tools on your behalf.

• Find answers in the Help Center. "How do I request a software license?" or "what's the time-off policy?" surfaces the right article, matched by meaning rather than by keyword.
• Create, view and update tickets without leaving the conversation: open a ticket, check its status, add a public reply or an internal note, change the priority or the assignee, mark it solved.
• Summarize a ticket for a report or a quick decision. The assistant pulls the details and the full comment thread and gives you the gist in a sentence.
• Read the screenshots and photos attached to a ticket. Error dialogs, UI captures and product photos are handed to your assistant's own model as images, so it can describe them or act on what they show.
• Search and triage your queue in plain language: "show me my open tickets about billing from this week."
• Draft and maintain knowledge-base articles. You can write a new one, or revise a large one a single section at a time, so the whole HTML body never has to round-trip through the model.
• Follow your team's playbook. Instructions, prompts and skills written by your admins reach every user's assistant, whatever MCP client they use.
• Submit and follow a request as a customer, not an agent. Choose between the kinds of request the vendor offers, answer only the questions that form asks, and then track it: what was replied, what you replied, and whether it's done.

Why this server

Most Zendesk integrations run on a shared admin API key, which hands every user full access to every ticket, and bolt on a fixed set of tools. This one is built differently.

• Per-user authentication, OAuth only. Both transports use OAuth 2.1 PKCE: each user signs in with their own Zendesk credentials, so the assistant sees and touches exactly what that person is allowed to, the same scoping you get by signing into Zendesk directly. Static API tokens are deliberately not supported (why).
• Two audiences, one server. Because auth is per-user rather than a shared admin key, the same install serves your agents and your customers — the end-user surface is a namespace you switch on, speaking the API path Zendesk reserves for requesters. Most Zendesk MCP servers are agent-only by construction.
• Section-based article editing. For large Help Center articles, read and rewrite one section at a time (parsed by h1/h2/h3 headings) instead of shuffling the full HTML body through the assistant. On a targeted edit that cuts tokens by a factor of 10 to 100.
• Native multimodal attachments. Ticket images come back as native MCP image content, so the client's own model (Claude, GPT, Gemini, whichever) sees the pixels directly. No server-side vision model, no extra API key, and nothing tying you to one provider. Non-image attachments come back as text references, and both image caps are configurable.
• A tool surface you can cap. Expose every operation as its own tool, group them into namespace proxies, or collapse everything into a single unified tool. You can also filter by namespace or down to read-only operations, so each context loads only the surface it needs (see Tool surface).
• Your practices ship with the server. Most teams hand-distribute a skill or a rules file per AI client. Here admins author instructions, prompts and skills once, inside the server, behind a back-office reserved to Zendesk admins, and every MCP client receives them. Skills fall back to prompts on clients that don't support them yet.
• Two deployment shapes, same auth story, on a lean stack. Run it on your laptop as a stdio MCP server, or deploy it as a private remote MCP server reached over HTTP, each client carrying its own user's token; underneath, the official MCP TypeScript SDK plus zod, speaking to the Zendesk Support and Help Center (Guide) APIs.

Look elsewhere when:

• You need Zendesk products outside Support and Guide (Talk, Explore analytics, Sell). Those endpoints aren't covered.
• You need a single shared service account, or static API-token auth. This server supports neither, by design (see below).

What this server does *not* do

There is no API-token authentication. The server speaks OAuth 2.1 PKCE and nothing else: no ZENDESK_EMAIL + ZENDESK_API_TOKEN (Basic auth) mode, in any transport. That is deliberate, for two reasons.

1. API tokens are insufficiently secure. A Zendesk API token is a long-lived, static, shared secret that carries the full rights of the user who issued it. There is no per-user scoping, no short expiry, and no per-user consent or revocation. OAuth 2.1 PKCE issues per-user, revocable tokens instead.
2. API tokens don't scale. A single static credential can't attribute actions to individual users, and it can't be revoked granularly. It also makes a multi-user remote deployment unsafe: over HTTP it would expose the issuing user's rights to every caller.

If you specifically need an API-token or service-account mode (headless CI with a shared account, say), use one of the other Zendesk MCP servers that support it. A few are listed under Inspiration & related projects.

Quick start: local (stdio)

The default shape: one developer, one Zendesk account, OAuth 2.1 PKCE in the browser. You need Node.js >= 22 and a Zendesk instance (Support or Suite).

Install

# Run without installing

npx -y @fruggr/zendesk-mcp-server

Or install globally

npm install -g @fruggr/zendesk-mcp-server zendesk-mcp-server

Signing in needs a Zendesk OAuth client, so register one first (next section).

Zendesk OAuth setup

1. Go to Admin Center → Apps and integrations → APIs → OAuth Clients
2. Create a public client:

• Identifier: _zendesk (or set ZENDESK_OAUTH_CLIENT_ID)
• Redirect URL: http://localhost:27439/callback (change the port to match OAUTH_CALLBACK_PORT / --callback-port if you override it; Zendesk accepts several redirect URLs, one per line)

If the client restricts its allowed scopes, it needs read — plus write unless the server runs with --read-only, which asks Zendesk for the read scope alone.

On the first tool call the server starts the sign-in flow: it opens a browser window and returns the authorize URL in a tool message. The call does not block waiting for sign-in, so authenticate in the browser and then retry the request. The token is persisted to an owner-only file and reused across restarts, so you don't authenticate again every time your MCP client respawns the server (path and overrides: OAUTH_TOKEN_FILE). Several instances can run side by side — a read-write one and a --read-only one, say — without trading credentials.

MCP client wiring

Claude Desktop

Add to your claude_desktop_config.json:

{

"mcpServers": { "zendesk": { "command": "npx", "args": ["-y", "@fruggr/zendesk-mcp-server", " ", "--mode", "single"] } } }

Claude Code

claude mcp add zendesk -- npx -y @fruggr/zendesk-mcp-server <your-subdomain> --mode single

VS Code (Copilot / Continue / Cline)

Add to your .vscode/mcp.json:

{

"servers": { "zendesk": { "command": "npx", "args": ["-y", "@fruggr/zendesk-mcp-server", " ", "--mode", "single"] } } }

Something not working? See Troubleshooting.

Quick start: remote (HTTP)

Experimental. The HTTP transport ships, but it has not yet been exercised

end-to-end against a real Zendesk tenant from every MCP client. Local stdio is

the supported path.

You can also deploy a private remote MCP server for one Zendesk account. It is its own OAuth authorization server: web clients such as claude.ai and ChatGPT add it by URL and register themselves, each user signs in to Zendesk through it, and no shared admin key or per-client Zendesk setup is involved. Each release also ships a hardened, distroless container image for it (ghcr.io/fruggr/zendesk-mcp-server), signed and attested. The full guide covers the image, the one redirect URL to add to your Zendesk OAuth client, the master secret and grant store, --public-url behind a reverse proxy, trusted clients, MCP client wiring, CORS and what stays the operator's job: [docs/http-deployment.md](docs/http-deployment.md).

Tool surface

Tools are grouped into namespaces: Tickets, Help Center, Users & Organizations, Search, Connector preferences — this server's own per-user settings, such as SLA alert thresholds, never written to Zendesk — and Requests — the end-user surface, which is opt-in and covered under End-user mode. The server registers them in one of three modes, so you can trade granularity against context budget:

• `all`: every operation as its own tool, for clients with good tool selection;
• `namespace` (default): one proxy tool per namespace, a balanced middle ground;
• `single`: a single zendesk tool, for models with limited tool slots (the connector's own preferences keep their connector_preferences proxy beside it).

Proxies take `{ "operation":