Connecting Claude Code to Zendesk Without Building Your Own CLI
There's no setting to flip. Claude Code has no built-in Zendesk connection, and Zendesk doesn't ship an official MCP server for it, so "read and update my tickets" only works if something in between speaks both sides. That something is either a REST call you write yourself, a small CLI plus a Claude Code skill wrapping that call, or an MCP server someone else already built and you point Claude Code at.
Anthropic's own MCP documentation describes this gap as the normal case. You connect a server the moment you notice yourself copying data out of a system like an issue tracker and pasting it into chat, so Claude can read and act on that system directly instead of working from what you typed in. Zendesk tickets are that system for a support-adjacent engineering team. The question isn't whether you need a bridge, it's which bridge is worth building for how often you'll use it.
Why Claude Code doesn't already do this
Claude Code's model for reaching outside tools is MCP. You connect a server over stdio, HTTP, or SSE, and that server exposes tools Claude can call. Nothing about Zendesk is special-cased inside Claude Code itself; it's a generic client, and it only knows about the systems you've wired up. Zendesk's Support API documentation covers tickets, users, and organizations over plain REST, but it's a REST reference, not an MCP server, and Zendesk hasn't published one of its own alongside it.
So the gap is real on both ends. Claude Code ships no Zendesk adapter, and Zendesk ships no Claude Code adapter. Whatever sits between them is something a team has to stand up.
The three ways people actually close the gap
Paste it in. For a one-off, open the ticket, copy the two or three lines that matter, the customer's ask, the account name, the priority, and drop them into the prompt. No credential touches Claude Code, and nothing beyond what you typed is ever exposed. This is the right answer for an engineer who looks at a Zendesk ticket a couple of times a month.
Build a CLI and a skill. Past that frequency, teams write a small command-line tool against the Zendesk API, then document its commands in a SKILL.md file so Claude Code knows when and how to call it. andmarios/zendesk-skill is a public example of exactly this shape. It pairs a zd-cli binary, 28 commands across tickets, users, organizations, views, and metrics, with a skill file describing the workflows, and it also bundles an MCP server variant so other MCP clients could use the same access. That third piece is the tell. A skill only helps Claude Code specifically, and an MCP server is what makes the same access reusable everywhere else too.
Connect an MCP server that already covers Zendesk. If someone has already built and maintained the bridge, point Claude Code at it with claude mcp add and skip writing the CLI. The catch is finding one that's actually maintained, and Zendesk's ticket model, tickets, side conversations, satisfaction ratings, macros, tags, is wide enough that most third-party servers only cover a slice of it.
The same export bug, fixed twice
Priya Chandrasekaran's team has had a version of the CLI-and-skill setup from the last section running against their own Zendesk instance for about a year: a zdcli binary wrapping ticket search, replies, and status updates, with a skill file that tells Claude Code when to reach for it. She rotates onto the two-week #eng-support shift every quarter.
Ticket #8814: "The weekly route export has come back empty two cycles running. We need this fixed before Monday's dispatch."
She runs zdcli ticket show 8814 from her Claude Code session, gets the full thread and the account's plan tier without opening a browser tab, and traces the failure to a date-range bug a recent migration introduced. She ships a PR fixing the export job and closes the ticket with zdcli ticket reply before lunch.
Three weeks later, a different engineer picks up a complaint in the support Slack channel: "dispatch numbers came back empty again this week." Nothing about that sentence points back to ticket #8814. He pastes it into his own Claude Code session, traces it the same way Priya did, and ships a second PR patching the same export job, not knowing anyone had already fixed it. The CLI did exactly what it was built for. It read and wrote Zendesk tickets. It was never built to know that a Slack message and a Zendesk ticket were describing the same job.
What connecting Zendesk alone still won't tell you
A hand-built skill and CLI, or even a general-purpose MCP server, solves the connection problem. Claude Code can now read and write Zendesk tickets on its own. It doesn't solve the problem underneath it, which is that Zendesk tickets are only one channel a customer uses, and the same complaint just as often lands in Slack, a sales call, or an email thread that nothing ties back to the ticket. Priya's team found that out directly: a CLI that talks to Zendesk gave them Zendesk, and nothing told them a ticket and a Slack message were the same export job until the second PR was already merged.
That's usually the point teams stop maintaining the bespoke bridge and look for something that already ingests Zendesk alongside everything else. Modem is built for that layer. Its Zendesk integration captures tickets and conversations and groups them with feedback from Intercom, Jira Service Desk, Slack, and your other connected sources into prioritized topics with the customer attached, instead of one ticket at a time. Watching both channels would have clustered ticket #8814 and the Slack complaint into one topic before the second engineer ever opened a session.
Modem's MCP server (currently in beta) is where that context becomes something Claude Code can ask about directly: a Zendesk ticket's account, prior history, and plan tier, in plain language, without writing a zdcli or a skill file yourself. That answers the read half of the original question. It doesn't answer the write half. Modem's write tools reshape Modem's own topics and company records; none of them update a Zendesk ticket's status or post a reply back to a customer. If updating and replying from Claude Code matters as much as reading, keep the CLI and skill from earlier for that half, or pair Modem's cross-channel context with a Zendesk MCP server that has write scope, and let each tool handle the half it's built for.
We build Modem, and that split is worth sitting with before you adopt it. If Zendesk is the only system you need Claude Code to reach, and updating tickets matters as much as reading them, a narrow CLI and skill is a real, working answer on its own; you don't need Modem for that. Modem earns its place once the same request is also showing up in Slack or a sales call and someone has to notice that before writing the fix, which is exactly what cost Priya's team a second PR. Related reading: connecting Zendesk tickets to Linear without losing customer context covers the tracker side of the same problem, and the best tools to give Claude Code customer context compares Modem against the other options directly.
Start from how often tickets land on you, not the tooling
If Zendesk tickets land on your desk a few times a month, keep pasting them in by hand. It costs nothing and exposes nothing beyond what you chose to copy. If they land daily and always come with the same follow-up questions, account name, plan tier, whether this has come up before, write that list down before you write a line of CLI code. That list is the actual spec for whatever bridge you build or buy next, and it's also the test for whether a read-only server like Modem's covers what you need or whether you still need the write side too.
