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's official MCP server is announced; check whether it has shipped. Until it does, "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. Zendesk has announced an official MCP server; check whether it has shipped.
So the gap is real on both ends. Claude Code ships no Zendesk adapter, and Zendesk's own MCP server is announced, not yet documented as of 2026-10-07. 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
Run the CLI-and-skill setup from the last section for a while and this is the shape the gap takes. A ticket comes in reporting that a scheduled export has returned empty two cycles running. From your Claude Code session you run zdcli ticket show against it, get the full thread and the account's plan tier without opening a browser tab, trace the failure to a date-range bug a recent migration introduced, ship a PR, and close the ticket with zdcli ticket reply.
Weeks later a complaint lands in the support Slack channel saying the same numbers came back empty again. Nothing in that sentence points back to the original ticket. Whoever picks it up pastes it into their own session, traces it the same way, and ships a second PR patching the same job, not knowing it was already fixed.
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. The example above shows it directly: a CLI that talks to Zendesk gives you Zendesk, and nothing tells you 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 runs as a standing layer rather than a script someone has to keep alive. 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 clusters the ticket 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 (with Stripe connected) 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 starts doing work a person cannot 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 costs a team the 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 Modem's server, whose record tools change Modem's own data and not Zendesk's, covers what you need or whether you still need a Zendesk write path too.