Zendesk MCP Server: Tools, Setup, and Governing Customer-Visible Writes

Wat de Zendesk MCP server is

Model Context Protocol is de open standaard waarmee een AI-agent tools op een extern systeem kan ontdekken en aanroepen. Een Zendesk MCP server past dit toe op Zendesk Support, waardoor tickets, aanvragers en organisatie-records veranderen in tools die een agent rechtstreeks aanroept in plaats van via maatwerk-code.

Eén ding verschilt van de meeste servers in deze reeks: de documentatie van TrueFoundry behandelt Zendesk niet als een vooraf ingestelde catalogus-entry. Ze adviseren om een Zendesk MCP server-implementatie te implementeren of te selecteren en deze vervolgens te registreren als een remote OAuth2 MCP server met je eigen Zendesk OAuth-client. Jij bent eigenaar van de implementatie; TrueFoundry beheert de toegangslaag.

De documentatie beschrijft toegang tot deze gebieden:

Exacte toolnamen hangen af van de implementatie die je uitrolt, dus bekijk het tabblad Tools na het verbinden in plaats van uit te gaan van een vaststaande lijst.

Wat agents er daadwerkelijk mee doen

De meest waardevolle workflows ketenen aanroepen aan elkaar:

• Ticket-triage. Lees een ticket, zoek de aanvrager en hun organisatie op, en routeer op basis van die context.
• Conceptantwoorden. Lees de thread en de historie van de klant en stel vervolgens een antwoord op dat een mens kan beoordelen en verzenden. Dit is de workflow die de meeste teams daadwerkelijk willen.
• Escalatie-context. Haal elk openstaand ticket voor een organisatie op en geef een accountmanager één overzichtelijke briefing.
• Backlog-analyse. Doorzoek een wachtrij, cluster op basis van de hoofdoorzaak en breng de belangrijkste oorzaken in kaart.

Lezen en schrijven zijn hier totaal verschillende zaken. Een ticket lezen voor context heeft een laag risico. Een opmerking toevoegen is van een heel andere orde, en dat vormt het governance-verhaal voor deze server.

Waarom rechtstreeks verbinden op teamschaal misgaat

Een schrijf-actie hier bereikt een klant. Als een coding agent een slechte commit pusht, ziet een engineer dat. Als een agent reageert op een Zendesk-ticket, krijgt een betalende klant een melding die aan jouw bedrijf wordt toegeschreven. Een verkeerde toon, een verkeerd ingeschatte belofte over een terugbetaling of een antwoord op het verkeerde ticket is een merkincident. Geen enkele interne logging kan een bericht ongedaan maken dat al in iemands inbox staat.

Leesacties lekken standaard PII. Tickets bevatten namen, e-mailadressen, telefoonnummers, bestelreferenties en bijlagen die zonder veel nadenken zijn geüpload. Een agent die deze leest, trekt al die data in een model-prompt. Een read-only agent is nog steeds een privacyrisico.

Gedeelde API-tokens wissen attributie. Als je de server koppelt met één admin-token, lijkt elke actie afkomstig van dezelfde gebruiker. Je kunt niet zien van welk team de agent was die op een ticket reageerde, of de toegang van één team beperken zonder die van iedereen te beperken.

Prompt injection komt binnen via de voordeur. Supporttickets zijn door gebruikers ingezonden teksten van vreemden — een ideaal kanaal voor geüploade instructies. Een agent die triage uitvoert leest content die door een kwaadwillende is geschreven. Als deze agent ook kan schrijven, kunnen die instructies ertoe leiden dat er naar de verkeerde klant wordt geantwoord.

Niets hiervan is een argument om Zendesk niet te verbinden. Het is een argument voor een MCP gateway ervoor: een mens in het schrijfpad, een redactiestap (anonimisering) in het leespad.

Wil je een support agent die je daadwerkelijk veilig kunt inzetten?

Verbind je Zendesk MCP server, houd leesacties open en plaats elke klantgerichte schrijf-actie achter een menselijke controle.

Gratis aan de slag

De Zendesk MCP server verbinden via TrueFoundry

Twee stappen: maak een OAuth-client aan in Zendesk en registreer de server vervolgens in TrueFoundry. Je hebt Zendesk-beheerdersrechten nodig en een TrueFoundry-account dat MCP servers kan toevoegen.

Stap 1 — Maak een Zendesk OAuth-client aan. Open in Zendesk Admin Center https://<subdomain>.zendesk.com/admin/apps-integrations/apis/apis/oauth_clients en voeg een confidential OAuth-client toe. Stel de redirect URL in op:

https://<tfy-control-plane-base-url>/api/svc/v1/llm-gateway/mcp-servers/oauth2/callback

Vervang <tfy-control-plane-base-url> door de URL van jouw control plane. De Unique identifier van de client is de Client ID. Kopieer de Secret zodra Zendesk deze toont — deze wordt slechts één keer weergegeven.

Stap 2 — Open de picker. Ga in TrueFoundry naar MCP Gateway en klik op Add Server.

Kies Connect any Remote MCP Server en vul de Name, Description en URL van je implementatie in.

Stap 3 — Configureer OAuth2. Selecteer OAuth2 als auth-type en kies de Authorization Code grant. Voer je Zendesk Client ID, Client Secret en domein in.

In plaats van de secret als platte tekst te plakken, sla je deze op in de TrueFoundry secrets store en verwijs je naar de FQN ervan.

Stap 4 — Voeg collaborators toe en sla op. Bepaal wie toegang krijgt voordat de server live gaat.

Stap 5 — Verbinden. Elke gebruiker opent het onderdeel Tools van de server en klikt op Connect Now. Nadat de OAuth-authenticatie is geslaagd, verschijnen de Zendesk-tools en kunnen ze worden uitgetest vanuit de Agent Playground.

Hoe authenticatie daadwerkelijk werkt

TrueFoundry scheidt inbound auth — hoe een client zich bewijst tegenover de gateway — van outbound auth, hoe de gateway zich bewijst tegenover Zendesk. De lagen werken onafhankelijk van elkaar.

Inbound heeft vier methoden:

Eén kanttekening: Virtual Account-tokens geven elke aanvraag identieke toegang, dus ze kunnen geen Zendesk-rechten per gebruiker toepassen. Als medewerkers verschillende weergaven hebben en je wilt dat dit ook geldt voor hun agents, gebruik dan inbound een PAT- of IdP-token.

Outbound is OAuth2 Authorization Code tegen de client uit Stap 1. Elke gebruiker autoriseert zijn eigen Zendesk-account; TrueFoundry regelt de toestemming, opslag en verversing, en voegt bij elke aanroep het juiste token per gebruiker in.

Dat is hier belangrijker dan elders. Support-tooling zit vol met rol-grenzen — tiers, merken, afgeschermde groepen. OAuth per gebruiker betekent dat een agent die handelt namens een Tier 1-medewerker precies ziet wat die medewerker ziet. En wanneer iemand Zendesk verlaat, vervalt de toegang van diens agent direct.

Tools scopen voordat je live gaat

Het tabblad Tools toont alles wat je implementatie ontsluit. Dit is de plek waar je bepaalt wat agents mogen doen.

Schakelaars per tool. Schakel een tool uit en deze wordt volledig weggelaten uit tools/list — clients zien deze nooit en de tool kan niet worden aangeroepen. Dit is geen filtering op prompt-niveau. Voor een triage-agent die alleen context nodig heeft, zorgt het uitschakelen van elke schrijf-tool ervoor dat deze structureel niet in staat is om contact op te nemen met een klant, wat er ook in de inhoud van een ticket staat.

Enable new tools by default. Als dit aan staat, worden nieuwe tools automatisch beschikbaar gemaakt. Als dit uit staat, zijn alleen tools beschikbaar die je expliciet hebt ingeschakeld. Voor een server waarvan de schrijf-acties klanten bereiken, is uitgeschakeld de juiste standaardwaarde.

Bulk Action. Verandert elke rij in selectievakjes met Select all, zodat je een lange lijst in één keer kunt aanpassen.

Klik op het potloodpictogram bij een tool om de weergave voor het model aan te passen:

De Description override accepteert tot 20.000 tekens en stelt de toolselectie bij wanneer de formulering van een implementatie vaag is. MCP Tool Annotations markeren een tool als Read-only of Destructive, waarmee readOnlyHint of destructiveHint wordt ingesteld. Markeer elke tool die naar een ticket schrijft als Destructive: die annotatie zorgt ervoor dat het onderstaande goedkeuringsbeleid de hele categorie kan afschermen zonder tools individueel bij naam te noemen.

Wie kan wat doen: collaborator-rollen

Toegangsbeheer heeft betrekking op gebruikers, teams of virtuele accounts op twee dimensies: welke servers een identiteit kan bereiken en welke tools binnen een server deze kan aanroepen.

De Approver-rol verdient hier extra aandacht. Degene die een klantgericht antwoord goedkeurt, moet een support-lead zijn die bekend is met jouw toon en beleid, niet de platform-engineer die de server heeft geregistreerd. Het is hetzelfde MCP access control-model als bij elke andere server, maar met een zwaarder wegende lijst met goedkeurders.

Klaar om een mens in de loop te plaatsen?

Wijs de Approver-rol toe aan je support-leads en koppel elke schrijf-actie op tickets in één sessie aan goedkeuring.

Start gratis op TrueFoundry

Menselijke goedkeuring voor destructieve tools

Voor de meeste servers is het uitschakelen van schrijf-tools de veilige standaardwaarde en is goedkeuring een fijne extra. Zendesk draait dat om. Supportteams willen juist door agents opgestelde antwoorden — bij het opstellen zit immers de tijdwinst. Wat ze niet willen, is dat de agent zelf op verzenden drukt. Goedkeuringsbeleid maakt precies die workflow mogelijk.

Wanneer een beveiligde tool wordt aangeroepen, wordt de aanroep aangehouden in plaats van uitgevoerd, wordt er een verzoek aangemaakt en worden goedkeurders op de hoogte gesteld. Zodra een mens het verzoek goedkeurt, slaagt dezelfde aanroep van dezelfde aanvrager totdat de toestemming verloopt.

Maak een beleid aan onder AI Gateway → Policies → MCP Tool Approval, in de console aangeduid als Beta:

Nieuw Approval Policy-formulier met toolselectie en opties voor Once of Time-based geldigheid

Elk beleid vermeldt de servers die het beveiligt en kiest een approval scope:

Hier werpen de annotaties hun vruchten af. Markeer schrijf-tools voor tickets eenmalig als Destructive, stel approval_scope: destructive in, en elke klantgerichte actie is afgeschermd zonder dat je een lijst met namen hoeft te onderhouden. Wanneer scopes overlappen, wint de meest specifieke: named > destructive > all.

Validity is Once — een enkele uitvoering — of tijdsgebonden, een duur in minuten. Voor klantgerichte schrijf-acties is Once de enig juiste instelling: een venster van 30 minuten betekent dat het goedkeuren van één antwoord stilzwijgend elk antwoord voor het komende halfuur goedkeurt, wat niet is waar een support-lead mee akkoord denkt te gaan. Bij een conflict tussen regels wint de meest restrictieve instelling: Once wint van 10 minuten, wat weer wint van 30 minuten.

Goedkeurders ontvangen een melding via e-mail, Slack, PagerDuty of MS Teams, en beoordelen dit in de console:

Elk verzoek toont de tool, het beleid, wie de aanvraag deed en de werkelijke tool-argumenten — zodat een goedkeurder het conceptantwoord en het ticket-ID leest voordat hij het goedkeurt. Dat is de reden waarom goedkeuring hier beter werkt dan uitschakelen: de agent voert nog steeds het werk uit.

Zolang een verzoek in behandeling is, ontvangt de aanroeper een JSON-RPC-resultaat met _meta.approval_status: "pending" in plaats van een foutmelding, zodat een goed geconfigureerde agent wacht en het opnieuw probeert. Toestemmingen gelden per aanvrager, dus goedkeuren voor één medewerker betekent niet dat het hele team is goedgekeurd. Een weigering blokkeert niemand permanent — de volgende aanroep maakt gewoon een nieuw verzoek aan. Om permanent te blokkeren, schakel je de tool uit of verwijder je de gebruiker.

PII filteren op het leespad

Goedkeuring regelt schrijf-acties. Leesacties vereisen iets anders: het risico is hier geen verkeerde actie, maar klantgegevens die in een model-prompt stromen.

TrueFoundry bevat een ingebouwde PII/PHI Detection guardrail, aangedreven door Azure AI Language PII Detection en draaiend op door TrueFoundry beheerde infrastructuur, waardoor er geen API-keys van derden nodig zijn. Het is van toepassing op vier hooks: LLM Input, LLM Output, MCP Pre Tool en MCP Post Tool.

De hook die hier van belang is, is MCP Post Tool, die PII uit tool-outputs wist voordat deze het model bereiken. Een ticket-inhoud keert terug waarbij het telefoonnummer en e-mailadres zijn vervangen door sterretjes en de rest intact is gebleven — de agent begrijpt het probleem nog steeds zonder de specifieke gegevens in te lezen. Configureer dit onder Guardrails, kies entiteitscategorieën (of selecteer alles, de standaardinstelling) en kies een handhavingsstrategie.

Twee kanttekeningen. De guardrail ondersteunt alleen de modus mutate: deze anonimiseert altijd in plaats van de aanroep te blokkeren. Daarnaast is de detectie contextbewust in plaats van gebaseerd op patroonherkenning, wat zorgt voor minder false positives dan een regex, maar geen absolute garantie biedt.

Testen in de Agent Playground

Test tools eerst handmatig. Klik op Try, vul parameters in en lees de JSON. Try is uitgeschakeld voor uitgeschakelde tools. Controleer twee dingen buiten de verbindingsstatus: of je OAuth-scopes de tickets dekken die je verwacht, en of een beveiligde schrijf-tool het 'pending'-resultaat teruggeeft in plaats van direct uit te voeren.

Het gebruiken vanuit je IDE

Open het tabblad How To Use voor de Gateway-URL van jouw omgeving en kant-en-klare codefragmenten.

Het ondersteunt Claude Code, VS Code, Claude Desktop, Cursor, Windsurf, Codex en de Python en TypeScript MCP SDK's. Add MCP to Cursor schrijft de configuratie voor je; Show API Key toont het token als je client er een nodig heeft in een header. Kopieer de URL van dit tabblad — een handmatig opgebouwd endpoint is de meest voorkomende oorzaak van een client die wel verbindt, maar geen tools toont.

Wat je krijgt zodra het achter de gateway staat

Metrics op tool-niveau. Het MCP Metrics-dashboard geeft inzicht in requests per seconde, latency van P50 tot P99, het foutpercentage per fouttype en het aantal requests per tool.

Op deze manier merk je het op wanneer een triage-agent hetzelfde organisatie-record veertig keer per ticket opvraagt.

Volledige request-observability. Elke aanroep wordt getracet met identiteit van de aanroeper, toolnaam, inputs en latency, geëxporteerd via OpenTelemetry naar Grafana, Datadog of Prometheus. Hier betekent dat een overzicht van welke mens welke klantgerichte schrijf-actie heeft goedgekeurd, en met welke argumenten.

Guardrails. Pre-tool en post-tool hooks voeren beleid uit op MCP tool-aanroepen — waarbij PII-redactie de meest voor de hand liggende toepassing is.

Lage overhead. De gateway voegt ongeveer 3-4 ms aan latency toe en verwerkt 350+ RPS op een enkele vCPU.

Eén register. Een support-agent heeft zelden genoeg aan alleen Zendesk. Bundel een geselecteerde set tools van verschillende servers achter één endpoint met een Virtual MCP Server — de Zendesk-documentatie van TrueFoundry raadt precies dit aan, om schrijf-tools te verbergen wanneer agents alleen support-context mogen lezen.

Toegang intrekken

Tenant-admins kunnen alle opgeslagen authenticatiegegevens wissen via het menu met drie puntjes naast Edit:

Revoke all tokens verwijdert elke auth-override en elk opgeslagen OAuth-token voor alle gebruikers en virtuele accounts op die server. Dit wordt van kracht bij het volgende verzoek en wordt vastgelegd in de Activity Logs. Deze actie kan niet ongedaan worden gemaakt.

Één beperking: dit wist alleen tokens bij de gateway, niet de verleende rechten binnen Zendesk zelf. Trek bij een daadwerkelijk incident ook de rechten van de OAuth-client in via de Zendesk Admin Center. De actie is alleen zichtbaar voor tenant-admins.

Aandachtspunten om te weten

De Zendesk-secret wordt maar één keer getoond. Als je die pagina sluit zonder deze te kopiëren, moet je de client opnieuw genereren.

Jij bent eigenaar van de implementatie. Omdat dit een zelf-geregistreerde remote server is en geen catalogus-entry, is de tool-lijst afhankelijk van wat de door jou gekozen implementatie biedt. Twee verschillende Zendesk MCP-implementaties zullen niet dezelfde tools aanbieden, en het bijhouden van upstream-wijzigingen is jouw verantwoordelijkheid.

Bijlagen vormen een blinde vlek. PII-redactie werkt op tekst die door de guardrail gaat. Klanten voegen screenshots, facturen en logbestanden toe, en een afbeelding is geen tekst. Maak een bewuste keuze of je agent überhaupt bijlagen mag verwerken.

Gerelateerde artikelen

• What Is an MCP Gateway: Architecture and Use Cases — de architectonische introductie
• MCP Access Control: Securing AI Agents with an MCP Gateway — permissies op tool- en serverniveau
• Virtual MCP Server Explained — het patroon dat de Zendesk-documentatie aanbeveelt voor het verbergen van schrijf-tools
• MCP Authentication Explained — inbound en outbound auth in detail
• MCP Server Security Best Practices — de beveiligings-checklist

Conclusie

De meeste MCP servers falen in stilte. Zendesk faalt waar de klant bij staat. Dat zou de manier waarop je het verbindt moeten veranderen: niet door de agent de toegang tot schrijf-acties volledig te ontzeggen — het opstellen van antwoorden levert immers de tijdswinst op — maar door te borgen dat geen enkel bericht de klant bereikt zonder dat een mens het eerst heeft gelezen.

Dat vereist drie instellingen. OAuth per gebruiker zodat elke actie herleidbaar is tot een persoon. Schrijf-tools voor tickets gemarkeerd als Destructive en afgeschermd door een goedkeuringsbeleid met de geldigheid Once, zodat een support-lead het concept controleert voordat het wordt verzonden. PII/PHI Detection op de MCP Post Tool-hook zodat het leespad stopt met het lekken van identificeerbare gegevens naar prompts.

Verbind je Zendesk MCP server op TrueFoundry

Gratis te proberen