Zendesk for support agents, reached through Claude, should let the frontline read and update tickets and do nothing that can empty a queue. In Elaichi that comes down to two block rules on the frontline role: one on deleting tickets, one on changing many tickets at once. An access request gives the support lead the exception an outage needs. Frozen parameters on a toolbox shared with the team keep new tickets in the right brand and group.
The delete block matters more than it looks. The catalog's Zendesk connector has no bulk-delete tool, and it does not need one. Zendesk's Tickets API lets its single-ticket delete run 400 times a minute. An assistant working down a search result is a bulk delete.
Which Zendesk tools should a frontline agent reach?
The reads, plus the writes that change one ticket at a time. In Zendesk's API a reply or an internal note is a comment added through a ticket update, so one update tool carries most of the writing.
| What the agent asks Claude for | Tool that runs |
|---|---|
| The customer's open tickets | list_all_zendesk_search |
| A ticket and its whole thread | get_single_zendesk_ticket_by_id, list_all_zendesk_ticket_comments |
| A public reply or internal note, a new status, priority or assignee | update_a_zendesk_ticket_by_id |
| A tag added or removed | zendesk_ticket_tags_add, zendesk_ticket_tags_remove |
| Who the requester is, and their company | get_single_zendesk_user_by_id, get_single_zendesk_organization_by_id |
| The help center article to quote | list_all_zendesk_help_center_articles, get_single_zendesk_help_center_article_by_id |
| A macro's wording, reused on one ticket | get_single_zendesk_macro_by_id |
The second list is shorter and matters more. A frontline agent's Claude should not reach these:
delete_a_zendesk_ticket_by_id, which deletes one ticket per call and can be called again and again.create_a_zendesk_deletion_scheduleandupdate_a_zendesk_deletion_schedule_by_id. A deletion schedule tells Zendesk to delete data automatically once it meets the schedule's conditions, per Zendesk's deletion schedules reference.zendesk_tickets_update_many, which changes up to 100 tickets in one call.create_a_zendesk_macroandupdate_a_zendesk_macro_by_id, which change what every agent sends.
Most teams write the first list by instinct and never write the second one down. The second list is the configuration.
How do you set up Zendesk for support agents in Claude?
Connect Zendesk once in Elaichi, put one address in Claude, and let each agent sign in as themselves. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Its own documentation calls it an open-source standard for connecting AI applications to external systems. Elaichi serves its 600+ connectors through one organization-wide endpoint, POST /mcp, behind OAuth, the sign-in standard that gives a client a revocable grant instead of a password.
In a Claude Team or Enterprise organization, an owner adds the address once, under Organization settings, Connectors, Add, then Custom and Web. Each agent then opens Customize, Connectors, clicks Connect beside it and signs in. On Pro and Max, each person adds the address under Customize, Connectors (Anthropic's custom connector guide). The address is the same for everyone. The grant differs per agent, and it is what you revoke when someone leaves.
Behind the address, four things decide what an agent's Claude can do. The role comes first. Each member holds exactly one, and it must carry tool:execute, the permission that gates the whole endpoint. Without it the tool list is empty, which is why Guest, Auditor and Billing Admin seats cannot run tools.
Sharing comes next. Pin the Zendesk tools the team needs into a toolbox, a saved set of tools you hand a team, and share the toolbox with the frontline team. Keep the Zendesk connection itself unshared, so every agent's call runs through the toolbox.
A restriction decides which connectors and which individual tools a target may reach. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. The role's rules apply to toolbox entries too, so they still hold if the toolbox grows. Frozen parameters, last, fix an argument's value on one toolbox entry.
Which two blocks stop bulk deletes and mass macro sends?
One block on deleting tickets and one on changing many tickets at once, both targeted at the frontline role.
The delete block names delete_a_zendesk_ticket_by_id and the two deletion-schedule writes. Zendesk lets only admins create a deletion schedule, so that half matters most when the connected account is an admin.
The bulk block names zendesk_tickets_update_many and the two macro writes. Zendesk's Macros API returns the changes a macro would make, and says plainly that "It doesn't actually change a ticket." A ticket update does the writing. A mass macro send is therefore a bulk ticket update, and Zendesk's bulk endpoint takes up to 100 tickets per call. The macro writes belong in the same block because a shared macro is what every agent sends. The catalog's description of update_a_zendesk_macro_by_id also warns that an update clears the macro's other actions unless they are included.
The bulk block has one cost. The catalog describes zendesk_tickets_update_many as the tool that tag changes on closed tickets require, so that job moves to the lead.
Use blocks rather than an allow list, so the rest of the connector stays open while the pilot runs. In Elaichi, the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything. A block also matches the tool's name or the operation Elaichi pinned at save time, so a renamed tool cannot slip past it. Blocks and allows match differently, and the difference is deliberate. Inside one rule set, blocks beat allows, so an allow added later that covers deletion does not reopen it.
A restricted tool is withheld from the tool list and cannot be called. Search names it, flagged restricted, with no schema (how restrictions shape tool search).
How does the support lead get the one exception an outage needs?
Through an access request that an admin approves. Each member holds exactly one role, so roles cannot stack, and a personal rule cannot lift a role block. A rule aimed at a member can only narrow what their role allows, and never replaces or loosens a role rule.
Take an outage. The lead needs to post one status update to every ticket it opened, and that is the bulk tool the frontline cannot reach. The lead files an access request for zendesk_tickets_update_many. An admin with member:manage approves it in the console, under Governance, then Access requests. Approval needs step-up sign-in, and nobody approves their own request. Neither an AI client nor the Elaichi Agent can approve or deny one.
Approval creates an access grant for the lead alone. The grant lifts exactly the approved tool out of the lead's role rules. The delete block and every other role rule keep applying to the lead. Nobody else changes, no rule is written, and the role is not edited. The grant lasts until the lead is removed or an admin approves a replacement. The bulk tool also needs an entry in the team's toolbox, where the role's block keeps it from everyone but the lead.
A separate role suits a different case. If five leads share the job, give them a Support lead role with its own rules, so the exception lives in one role rather than five grants. A personal rule still has a use: it can narrow one person, such as a new agent who should not update tickets yet.
How do you keep the assistant inside one brand and one group?
Freeze brand_id and group_id on the toolbox entry for create_a_zendesk_ticket. In Zendesk's ticket object, the first names the brand a ticket belongs to and the second the group it is assigned to, per the Tickets API. Copy the exact paths from the tool's schema in Elaichi before you freeze them, because a freeze written on the wrong path pins nothing.
A frozen field is removed from the tool's schema before Claude is handed it, so there is no brand for the model to choose. At execution the frozen value is written over the call's arguments, so sending the field anyway changes nothing. Every ticket the assistant opens lands in the support brand and the frontline group.
One condition: a freeze binds only calls made through its toolbox entry, so share the toolbox with the people it governs, not the connection itself. An agent who also holds use on the Zendesk connection, directly or through a team or organization share, reaches create_a_zendesk_ticket unfrozen. A block on that tool does not close the gap, because restrictions apply to toolbox entries too and would withhold the frozen entry as well. Leaving the connection unshared closes it.
Updates are a judgment call. Freezing group_id on update_a_zendesk_ticket_by_id stops the assistant moving a ticket into another team's queue. A freeze rewrites a call rather than refusing it, though, so every ticket the assistant updates ends up in the pinned group. Freeze it there only where agents work their own group's tickets.
Restrictions decide which operations exist, and frozen values decide where they land, so the model never guesses a brand from a prompt.
How do you prove the blocks held?
Wait about two minutes after saving, ask Claude to do what you blocked, and check the audit log. A role or restriction change takes about two minutes to reach every surface, and the offboarding guide sets out why removals land faster.
- Signed in as a frontline agent, ask Claude to delete a test ticket. It should find the delete tool only as restricted, and a call forced through
execute_toolis refused. - Ask the same Claude to reword a shared macro. It should find the macro tools only as restricted.
- As the lead, ask Claude to tag two closed test tickets in one request, which needs the bulk tool. It should go through.
- Filter the audit log by the lead as actor, the time of the test, and the tool name in free text. The lead's bulk update has an entry that names the outcome and the account. The frontline agent's refused delete has none, because a call refused before execution writes no row.
Elaichi keeps one entry for each connected-tool call that reaches execution (a call refused earlier writes none) (what each entry holds). It records the one path argument that names the object, as the target id, and nothing else about the arguments, so no ticket body or requester email lands in the log. The trail is eventually consistent, so give a row a moment to appear.
The reviewer who checks it can hold the Auditor seat, which is free and read-only.
Why not wait for Zendesk's own MCP server?
Zendesk's own server is the natural choice for a team that connects only Zendesk, once your account has it. Zendesk announced it on 19 May 2026. The server will let businesses connect "Zendesk tickets, knowledge, and other data to external AI systems in a trusted and governed way". The announcement lists it for "Early access this summer" (Zendesk's Relate 2026 announcement, read October 2026). Zendesk's September 2026 release notes cover its MCP client reaching general availability, not the server. Ask Zendesk where your account stands before you plan around it.
Where Zendesk's server wins is plain. It comes from Zendesk, so no second vendor sits between your agents and your tickets, and it would run under Zendesk's own permission model.
What Elaichi adds sits across apps rather than inside Zendesk. One address carries Zendesk, Jira and Slack to Claude, ChatGPT and Cursor. The frontline role's blocks are written once, beside its rules for every other app it reaches. Frozen parameters on the shared toolbox pin brand and group. One audit trail covers every app, and removing or suspending one person ends their access to all of them on their next call. The announcement does not describe role rules that span apps or arguments pinned per tool, so put those questions to Zendesk as early access opens.
What happens when a support agent leaves?
Their access through Claude ends on their next call. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. The grant is re-read on every call, with no cache.
If your directory deprovisions people through SCIM, the standard for syncing users from a directory, that suspends the member in Elaichi. Suspension ends access the same way. Removing the member is a separate step an admin takes in Elaichi, and it runs a preflight first. The preflight lists every Zendesk connection the agent owns, private and shared alike. A private one that a shared toolbox depends on blocks the removal until an admin transfers it to a member. A private one that nothing beyond the agent depends on cannot be transferred and is deleted with them. A shared one can go to a member who is staying, and it is deleted only if the admin asks.
Watch for the person who pinned the team's toolbox entries. If they are removed, suspended through SCIM or lose use on the connection, those entries stop resolving for every agent until someone re-pins them. Offboarding lists them as a warning rather than a blocker.
The agent's Zendesk account itself is a separate step in Zendesk. Offboarding a member who holds MCP connections walks the whole sequence, contractors included.
When should Zendesk's own permissions do the job instead?
When the Zendesk role behind the connection already forbids the action. Zendesk's Tickets API allows deletion only for admins and for agents with permission to delete tickets. Its deletion schedules reference lists creating a schedule as admin-only. If every agent connects a personal Zendesk account whose role cannot delete, Zendesk refuses the call. A matching Elaichi block then adds a second place to drift, and in a year nobody remembers which one carries the load. Personal connections have one cost: calls through an agent's own connection skip the toolbox, so its frozen brand and group do not apply to them.
The qualification is what the connection signs in as. Some teams share one Zendesk service account with admin rights, because that was the fast way to connect. Then the upstream role protects nothing, and the Elaichi block is the only gate.
If support is six people on one Zendesk account with no other connected app, a control plane is probably premature. Zendesk's own server may be the simpler route once it reaches your account. The case for holding off on a gateway lists the signals that end the wait.
What can this setup not protect against?
Two things: instructions hidden in ticket text, and a loop of single replies.
The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call. A ticket body with instructions in it is ordinary data to Zendesk and ordinary text to the model, so it can steer Claude toward a tool. The role's rules still decide whether that tool exists for the agent.
The bulk block stops one call reaching up to 100 tickets. It does not stop Claude calling update_a_zendesk_ticket_by_id once per ticket. A run of identical replies is not refused; it shows up in the audit trail, one entry per call.
The Salesforce playbook for a sales team runs the same order, and the finance team's Xero playbook builds the opposite shape, an allow list of reads. The helpdesk connectors and the twelve team pages are where to plan the next rollout.
