Zendesk (API token) MCP server

What it does

This server reads and works Zendesk Support tickets, looks up users and organizations, and reads and edits Help Center articles. It is @enterpret/zendesk-mcp-server, an MIT-licensed fork of Digital4Better's @fruggr/zendesk-mcp-server that kept API token sign-in after the original moved to a browser OAuth flow. Zendesk does not maintain it. Statio runs version 0.3.3 with an agent's email and API token, and every call goes to your own <subdomain>.zendesk.com.

Zendesk has announced its own MCP server, with early access promised for summer 2026. As of October 2026 I found no setup docs for it on Zendesk's help center.

Tools

In its default mode the server lists three tools. Each one takes an operation name and a params object, and dispatches to one of 38 operations. None of the three set a read-only hint.

The operations behind them:

There is no operation that deletes a ticket, user, organization or article, and none that creates or edits users or organizations.

Set it up

Both setups need an API token. You must be a Zendesk admin. In Admin Center, go to Apps and integrations, then APIs > API tokens, and click Add API token. Copy it when it appears, because Zendesk never shows the full token again. The server also needs your subdomain, the part before .zendesk.com, and the email of the agent account it should act as.

Zendesk is removing API tokens. Its help center says tokens unused for 30 days are deleted automatically from July 28, 2026, and every API token stops working by April 30, 2027. A token for an agent that only runs occasionally can disappear before then. The package also supports OAuth, through a browser sign-in on the first call or a ZENDESK_OAUTH_BEARER token from a broker, and that is the path to plan for.

Claude Code, directly:

claude mcp add zendesk \
  -e ZENDESK_SUBDOMAIN=your-company \
  -e ZENDESK_EMAIL=agent@your-company.com \
  -e ZENDESK_API_TOKEN=your-token \
  -- npx -y @enterpret/zendesk-mcp-server@0.3.3

Cursor, directly, in ~/.cursor/mcp.json or .cursor/mcp.json:

{
  "mcpServers": {
    "zendesk": {
      "command": "npx",
      "args": ["-y", "@enterpret/zendesk-mcp-server@0.3.3"],
      "env": {
        "ZENDESK_SUBDOMAIN": "your-company",
        "ZENDESK_EMAIL": "agent@your-company.com",
        "ZENDESK_API_TOKEN": "${env:ZENDESK_API_TOKEN}"
      }
    }
  }
}

Run directly, the server takes flags after the package name. --read-only drops every write operation, --namespace tickets (repeatable) keeps only the tools you name, and --mode all lists the 38 operations as 38 separate tools. Add them to the args before an agent starts using it.

The client tutorials, How to add MCP servers to Claude Code and How to set up MCP servers in Cursor, explain config scopes and how to keep the token out of files you commit.

Through Statio: install Zendesk from the catalog, paste the subdomain, email and token under the server's Credentials, and grant tools under Permissions. A new server has no grants, so nobody can call it until you add some. The desktop app then writes your client configs. The manual entry is the local proxy URL with the server name from your dashboard, http://127.0.0.1:7777/zendesk/mcp, added in Claude Code with claude mcp add --transport http zendesk <url> or as a "url" in Cursor. Tools missing after that? Start a fresh session, then work through How to debug an MCP server that won't connect.

What to hold back

Start with what a grant means here. Statio grants access per tool, and this server has three tools. A grant on zendesk_tickets is a grant on all 11 ticket operations, so an agent that may search tickets may also reassign them, close them and reply to customers. Statio can't split reads from writes inside one tool. It can keep zendesk_tickets or zendesk_help_center from an agent completely, and it can grant zendesk_users alone, which only reads. If an agent needs ticket reads without ticket writes, the switch is the server's own --read-only flag, which the catalog image doesn't set, so that agent needs a direct connection with the flag for now.

add_public_comment is the write with the widest reach, because the requester sees the comment, posted as the agent account. A drafting agent should use add_private_note and leave sending to a person, but both sit behind the same tool, so you can't give it one without the other.

update_ticket changes status, assignee, group and custom fields. Your triggers and automations act on those changes as they would on a person's, so a loop that "tidies up" old tickets can solve ones customers are still waiting on.

On zendesk_help_center, update_article_translation and update_article_section rewrite published article text, and update_article can change an article's visibility. A support agent answering questions needs the reads only.

Ticket text arrives from customers. Anyone who can email your support address can put instructions in a ticket, and the agent reads them as part of its context. An agent that holds both the ticket reads and the write operations is the setup where that turns into actions.

The token is the last boundary. Help Center reads use the connected user's Zendesk permissions, so the email you configure decides what the agent can see. Make it a dedicated agent account with the narrowest role that does the job, and not an admin's. That only holds while the token stays out of reach, though. Zendesk's own docs say an API token isn't tied to a user and can be used to impersonate anyone in the account, including admins, by pairing it with their email. Through Statio the token is stored encrypted and added to each call, so the agent never sees it. In a local config, anything that can read the file can read it too.

MCP permissions covers how grants and denies combine.

Questions