Zendesk MCP Server
Lets agents fetch, create and update Zendesk tickets and comments, with Help Center articles as a knowledge base.
Add to your client
Copy the config for your MCP client and paste it into its config file.
uv venv && uv pip install -e .Paste into ~/Library/Application Support/Claude/claude_desktop_config.json
{
"mcpServers": {
"zendesk-mcp-server": {
"command": "uv",
"args": [
"--directory",
"/path/to/zendesk-mcp-server",
"run",
"zendesk"
]
}
}
}Step-by-step guides: Add to Claude Desktop · Add to Cursor · Add to Windsurf
Before you start
- uv installed (server runs via `uv --directory ... run zendesk`)
- A Zendesk account with an API token (Admin Center → Apps and integrations → APIs), plus your subdomain and agent email
- A .env file in the repo based on .env.example holding those credentials
About Zendesk MCP Server
This server covers the day-to-day loop of a support inbox rather than the whole Zendesk API surface. get_tickets pages through recent tickets with sort controls (created_at, updated_at, priority, status), get_ticket and get_ticket_comments pull a full thread, and the write side handles the three things agents actually do: comment (public or internal via the public flag), create tickets with priority/type/tags/custom fields, and update status, assignee, priority or due dates.
The knowledge-base resource is the differentiator. zendesk://knowledge-base loads your Help Center articles as MCP context, which means the bundled draft-ticket-response prompt can ground replies in your actual documentation instead of hallucinating policy. analyze-ticket does the same for triage — the model reads the real thread before opining.
Setup is clone-and-configure: uv venv && uv pip install -e . (or uv build), copy .env.example to .env with your Zendesk subdomain, email and API token, then point your MCP client at uv --directory /path/to/zendesk-mcp-server run zendesk. The Dockerfile is production-minded — installs from requirements.lock, drops to a non-root user, takes config exclusively from env vars — and the README shows the corresponding docker-run config block for Claude with --env-file.
Scope limits to be aware of: there's no ticket-search tool (you page through recent tickets or fetch by ID), and no user/organization management — it's tickets, comments and the knowledge base. Apache 2.0, ~106 stars, and small enough to read in one sitting if you need to extend it.
Tools & capabilities (6)
get_ticketsList recent tickets with pagination and sorting (created_at, updated_at, priority, status)
get_ticketRetrieve a ticket by ID
get_ticket_commentsRetrieve all comments on a ticket
create_ticket_commentAdd a comment to a ticket, public or internal
create_ticketCreate a ticket with subject, description, priority, type, tags and custom fields
update_ticketUpdate ticket fields: status, priority, type, assignee, tags, due date
When to use it
- Morning triage: list overnight tickets sorted by priority and get an analysis of each before assigning
- Draft grounded replies: use the draft-ticket-response prompt with the Help Center knowledge base as context
- Bulk hygiene: close stale solved tickets or retag a batch by updating status and tags conversationally
- Escalation summaries: pull a full comment thread and produce a handoff summary for engineering
Quick setup
- 1Clone the repo and build: `uv venv && uv pip install -e .`
- 2Copy .env.example to .env and fill in your Zendesk subdomain, email and API token
- 3Add the config block to Claude Desktop: command `uv`, args `["--directory", "/path/to/zendesk-mcp-server", "run", "zendesk"]`
- 4Restart Claude; optionally use the Docker path instead (`docker build -t zendesk-mcp-server .` and a docker-run config with --env-file)
- 5Test with 'list my latest Zendesk tickets' before trying comment or update tools
Security notes
Zendesk credentials (subdomain, email, API token) live in a .env file inside the repo — keep it out of version control; the Docker setup reads the same file via --env-file. The server can post public comments and change ticket status on real customer threads, so review agent output before it goes customer-facing.
Zendesk MCP Server FAQ
Is zendesk-mcp-server safe to point at a production Zendesk?
Reasonably, with one rule: it can post public comments and change ticket status, so keep a human review step before customer-facing writes. Credentials stay in a local .env (never sent anywhere but Zendesk's API), the Docker image runs non-root, and it's Apache 2.0 open source you can audit in an afternoon.
Can it search tickets or access the Help Center?
No search tool — you list recent tickets (with sort and pagination) or fetch by ID. The Help Center is fully available though: the zendesk://knowledge-base resource exposes all articles as context, which the draft-ticket-response prompt uses to ground replies in your real docs.
What credentials does it need?
Three values in .env: your Zendesk subdomain, agent email, and an API token generated in Admin Center. It authenticates to the standard Zendesk API — no OAuth app registration and no PyPI package; you clone the repo and run it with uv.
Alternatives to Zendesk MCP Server
Compare all alternatives →
Connect your personal WhatsApp: search, read and send messages and media locally
Lets agents read LinkedIn profiles, companies, jobs and messages through your own logged-in browser session.
Powerful Slack MCP with stdio/SSE/HTTP, DMs, group DMs and no-admin token auth
Compare Zendesk MCP Server with: