zendesk-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ZENDESK_EMAIL | Yes | Email of the Zendesk user that owns the API token | |
| ZENDESK_API_TOKEN | Yes | Your Zendesk API token | |
| ZENDESK_SUBDOMAIN | Yes | Your Zendesk subdomain (e.g., 'yourcompany' if your Zendesk is yourcompany.zendesk.com) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tasks | {
"list": {},
"cancel": {},
"requests": {
"tools": {
"call": {}
},
"prompts": {
"get": {}
},
"resources": {
"read": {}
}
}
} |
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_ticketsA | Search tickets (GET /api/v2/search). Use this first to find tickets, then get_ticket / get_ticket_comments for detail. Returns slim tickets. API caps results at 1000 per query; narrow with date ranges if needed. |
| get_ticketA | Get full details of one ticket (GET /api/v2/tickets/{id}). |
| get_ticket_commentsA | Get the conversation thread of a ticket, public replies and internal notes, newest first (GET /api/v2/tickets/{id}/comments). |
| create_ticketC | WRITE: Create a new ticket (POST /api/v2/tickets). |
| update_ticketA | WRITE: Update ticket fields: status, priority, assignee, tags (PUT /api/v2/tickets/{id}). Does not add comments; use add_ticket_comment for that. |
| add_ticket_commentA | WRITE: Add a comment to a ticket (PUT /api/v2/tickets/{id} with a comment object). Defaults to an internal note; set public=true only to send a customer-visible reply. |
| get_userA | Get a Zendesk user by ID (GET /api/v2/users/{id}). Use to resolve requester_id / assignee_id values returned by ticket tools. |
| search_usersA | Search users by name or email (GET /api/v2/users/search). |
| create_or_update_userA | WRITE: Create a user, or update it if one already exists with the same email or external_id (POST /api/v2/users/create_or_update). Idempotent: cannot create duplicates. |
| search_organizationsA | Find organizations by name (GET /api/v2/organizations/autocomplete). Returns organizations whose names begin with the given value. |
| list_org_ticketsA | List all tickets of one organization, the account-health view (GET /api/v2/organizations/{id}/tickets). Use search_organizations first to get the organization_id. |
| create_or_update_organizationA | WRITE: Create an organization, or update it if one matches by external_id (POST /api/v2/organizations/create_or_update). Idempotent. |
| search_articlesA | Search Help Center knowledge base articles by relevance (GET /api/v2/help_center/articles/search). Use before answering questions that the knowledge base may already cover. |
| get_articleA | Get one Help Center article including its full HTML body (GET /api/v2/help_center/articles/{id}). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 14 tools
Each tool targets a distinct resource-action pair: ticket creation/update/comment/search/get/comments, user search/get/upsert, org search/upsert/ticket-listing, and article search/get. No overlapping purposes; even search_tickets vs list_org_tickets have clearly different scopes.
All tool names follow a consistent verb_noun pattern in snake_case (create_ticket, search_users, get_article, list_org_tickets, etc.). The verb prefixes are uniform (create, update, add, get, search, list), with only minor abbreviation like 'org' that doesn't break the pattern.
14 tools is well-scoped for a Zendesk server, covering four core entities (tickets, users, organizations, articles) with essential operations. Each tool earns its place without redundancy or bloat.
The surface covers the main workflows: full ticket lifecycle (create, update, comment, search, get, comments), user lookup/upsert, organization search/upsert and ticket listing, plus article search/get. Minor gaps like delete operations or get_organization by ID exist, but agents can work around them with current tools.