get_ticketsLABSCO SUMMARY
The reply is drafted against your Help Center, not from memory.
Reading the ticket and its thread is the easy half. What makes the draft usable is that the knowledge base is available at the same moment, so the answer matches the one you published.
What it is
A Zendesk integration in three parts: tools for reading and writing tickets and their comments, the entire Help Center exposed as a resource, and two prompts - one that analyses a ticket, one that drafts a response to it.
What you get
- A single ticket read in full, or a page of tickets with the sort order and page size under your control
- A ticket's comment thread
- New tickets created, with requester and assignee set
- Comments posted back onto a ticket
- The whole Help Center article set available as a resource, so a draft is written against what you have actually published
- Two ready prompts: analyse a ticket, and draft a response to it
Requirements
Zendesk credentials in a .env file - the repository ships an example to copy - and uv to build and run. A Dockerfile is included: the image installs from a lockfile, drops to a non-root user and takes all configuration from the environment. Add -i when wiring the container to a client that talks over stdin and stdout.
Setup effort
Build from source — git clone https://github.com/reminia/zendesk-mcp-server
USE CASES
Drafting a reply that matches what you have published
Read the ticket and its comments, then draft with the Help Center in reach so the answer is the documented one.
Getting up to speed on a ticket somebody escalated
Pull the ticket and its whole thread in one go, instead of scrolling the agent view.
Posting the answer where the customer will see it
Add the comment to the ticket from here, once the draft is right.
Logging an issue that arrived somewhere else
Create the ticket with requester and assignee set, so it enters the queue properly rather than as a note.
Looking across the queue for a pattern
Page through tickets with the sort order and page size you want, to see whether the same thing keeps being reported.
6 tools
Listed in project docs. Your client may show a different list.
get_ticketget_ticket_commentscreate_ticket_commentcreate_ticketupdate_ticketBEFORE YOU INSTALL
What to know first
Tools you get
6 tools named in the project's documentation.
Requires
- uv and Python 3.12+
- A Zendesk account whose admin can create a public OAuth client
- Docker only for the container route
INSTALLATION
Connect your client
You clone this one yourself.
Server setup
git clone https://github.com/reminia/zendesk-mcp-server
cd zendesk-mcp-server
uv venv && uv pip install -e .In Zendesk Admin Center, go to Apps and integrations > APIs > OAuth clients and create a Public client with redirect URL http://localhost:4567/callback; note its Identifier
Copy .env.example to .env and set ZENDESK_SUBDOMAIN (acme for https://acme.zendesk.com) and ZENDESK_CLIENT_ID (the Identifier)
uv run zendesk-authApprove access in the browser that opens; the tokens are stored locally and renewed by the server.
MCP Clients
Claude Desktop
{
"mcpServers": {
"zendesk": {
"command": "uv",
"args": [
"--directory",
"<YOUR_PATH_TO_ZENDESK_MCP_SERVER>",
"run",
"zendesk"
]
}
}
}<YOUR_PATH_TO_ZENDESK_MCP_SERVER> is the full path of your clone.
Claude Code
Build the image inside the clone:
docker build -t zendesk-mcp-server .Authorize on the host, not in the container:
uv run zendesk-authAdd this entry:
{
"mcpServers": {
"zendesk": {
"command": "/usr/local/bin/docker",
"args": [
"run",
"--rm",
"-i",
"--env-file",
"<YOUR_PATH_TO_ZENDESK_MCP_SERVER>/.env",
"--user",
"<YOUR_UID>:<YOUR_GID>",
"-e",
"ZENDESK_TOKEN_FILE=/tokens/tokens.json",
"-v",
"/Users/<YOUR_USERNAME>/.config/zendesk-mcp:/tokens",
"zendesk-mcp-server"
]
}
}
}/usr/local/bin/docker is the usual docker path; yours is where docker is on your machine. <YOUR_PATH_TO_ZENDESK_MCP_SERVER>/.env is your .env, the .config/zendesk-mcp folder is your token folder (zendesk-auth writes tokens there), and <YOUR_UID>:<YOUR_GID> are the numbers id -u and id -g print — the client does not run a shell, so $(id -u) is not expanded. The mount must stay writable: the server rewrites the token file whenever it renews access.