Slack MCP Server: Tools, Scopes en Hoe Deze Veilig te Verbinden
.png)
Gebouwd voor snelheid: ~10ms latentie, zelfs onder belasting
De razendsnelle manier om je modellen te bouwen, volgen en implementeren!
- Verwerkt 350+ RPS op slechts 1 vCPU — geen tuning nodig
- Productieklaar met volledige enterprise-ondersteuning
Wat de Slack MCP server is
De Slack MCP server is een remote Model Context Protocol server die onderhouden wordt door Slack, beschikbaar op https://mcp.slack.com/mcp. Model Context Protocol is de open standaard waarmee een AI agent tools op een extern systeem kan ontdekken en aanroepen; Slack's implementatie transformeert de gespreksgeschiedenis van een workspace in iets dat een agent kan bevragen en beschrijven. Omdat het een remote server is, hoef je geen container te draaien en is er geen proces op elke laptop nodig — je verwijst een MCP client naar een URL en authenticeert.
Wat het kan bereiken, wordt vrijwel volledig bepaald door de OAuth scopes die je aan de Slack-app verleent:
Dat model heeft remote MCP servers de standaardmanier gemaakt waarop teams SaaS-tools verbinden met agents. Eén verschil met de meeste beheerde integraties: je maakt de Slack-app zelf aan, en de scopes vormen de buitenste grens van alles wat een agent ooit kan doen — je eerste en goedkoopste beheersmaatregel.
Wat agents er daadwerkelijk mee doen
De nuttige toepassingen combineren zoeken, geschiedenis en andere servers met elkaar:
- Incident retro. Een agent zoekt het incidentkanaal, haalt de threadgeschiedenis op en stelt een postmortem-tijdlijn op op basis van de werkelijke berichten in plaats van iemands herinnering.
- Support triage. Een vraag komt binnen in een gedeeld kanaal; de agent zoekt in eerdere gesprekken naar hetzelfde symptoom en haalt de thread naar boven waarin het werd opgelost.
- Statusoverzicht. Over verschillende projectkanalen leest de agent de berichten van de afgelopen week, identificeert beslissingen en obstakels, en schrijft een samenvatting in een canvas.
- Cross-tool context. Een coding agent met Slack en een bronbeheerserver leest de discussie over een issue alvorens code te schrijven.
Het cruciale onderscheid is lezen versus schrijven, en in Slack zijn beide kanten gevoeliger dan ze lijken.
Lezen is niet onschuldig. Een workspace bevat HR-gesprekken, salarisdiscussies en privé DM's, zonder dat er een equivalent bestaat van een "publieke repo" voor het grootste deel ervan — en een agent die search:read.im is verleend, kan elke directe chat lezen waar zijn gebruiker toegang toe heeft.
Schrijven is geen codewijziging; het is communicatie. Een bericht dat is geplaatst met chat:write wordt toegeschreven aan de geautoriseerde gebruiker, en collega's die erop reageren kunnen niet zien dat een agent het heeft geschreven. Dat is de reden waarom zowel de documentatie van Slack als die van TrueFoundry aanbeveelt om chat:write uit te schakelen bij brede uitrollen.
Waarom een rechtstreekse verbinding op teamschaal misgaat
Eén persoon die Slack verbindt met Claude Desktop is prima. Een heel team dat dit doet is een ander probleem, en de faalmodi zijn niet de modi die je zou verwachten van een ontwikkeltool.
Eén gedeeld token leest de hele workspace. Regel dit goed voordat je iets anders doet. Verbind Slack met één enkel servicetoken — een bot-token, een gedeelde app-credential, een virtueel account — en elke agent-aanroep krijgt identieke toegang, zonder enige inperking per aanroeper achteraf. De agent van een stagiair en de agent van de CFO krijgen hetzelfde overzicht, en de 'blast radius' bij een datalek is de volledige gespreksgeschiedenis van de workspace. Slack-toegang moet de mens volgen, wat autorisatie per gebruiker vereist.
Een agent die als een gebruiker plaatst, is niet te onderscheiden van de gebruiker. Berichten die worden verzonden onder de OAuth-autorisatie van een gebruiker dragen de naam en avatar van die gebruiker, zonder een "verzonden door een agent"-markering die een lezer opmerkt. Een agent die een verkeerd getal plaatst, of reageert in een klantkanaal met iets dat niet is goedgekeurd, veroorzaakt een probleem dat wordt toegeschreven aan iemand die het niet heeft geschreven.
Scopes breiden zich ongemerkt uit, en niemand verkleint ze. Het setup-manifest verleent elke functionaliteit die de server ondersteunt, inclusief het zoeken in DM's en DM-geschiedenis. Teams kopiëren dit rechtstreeks, waardoor een agent die slechts drie projectkanalen nodig had, uiteindelijk elke privéconversatie van zijn gebruiker kan doorzoeken.
Prompt injection komt binnen via de inhoud zelf. Slack is een omgeving waar andere mensen — inclusief, via gedeelde kanalen en Slack Connect, mensen van buiten je bedrijf — tekst schrijven die je agent zal lezen. Als een samenvattende agent ook chat:write en zoekrechten over meerdere kanalen heeft, is de weg van "iemand plaatst een specifiek geformuleerd bericht" naar "agent plaatst privé-inhoud op een leesbare plek" erg kort.
Dit is allemaal geen reden om Slack te vermijden. Het is een reden om er een 'control plane' voor te plaatsen — en dat is precies waar een MCP gateway voor bedoeld is.
De Slack MCP server verbinden via TrueFoundry
Slack wordt geregistreerd als een remote MCP server met OAuth2. Twee stappen: maak de Slack-app aan en registreer deze vervolgens op de gateway.
Stap 1 — Maak de Slack-app aan. Ga naar api.slack.com/apps, kies Create New App → From an app manifest, selecteer de workspace, zet de editor op JSON en plak het manifest uit de handleiding van TrueFoundry. De redirect-URL moet https://<tfy-control-plane-base-url>/api/svc/v1/llm-gateway/mcp-servers/oauth2/callback zijn, waarbij je jouw eigen control plane URL invult.
Stap 2 — Verklein de scopes voordat je de app aanmaakt. Dit is de stap waar je even de tijd voor moet nemen. Verwijder chat:write als agents niet mogen plaatsen; verwijder search:read.im en im:history als ze niets te zoeken hebben in DM's.
Stap 3 — Schakel MCP in op de app. Open in de app-zijbalk Features → Agents & AI Apps en schakel Model Context Protocol in. Zonder dit zal de server niet reageren.
Stap 4 — Kopieer de OAuth credentials van Settings → Basic Information.
Stap 5 — Voeg de server toe in TrueFoundry. Open MCP Gateway, klik op Add MCP Server en selecteer Connect any Remote MCP Server.

Stap 6 — Vul de configuratie in.
Als jouw TrueFoundry-versie automatisch OAuth-metadata ontdekt, gebruik dan de ontdekte waarden en voer alleen de Slack client credentials in. Voeg vervolgens medewerkers toe en sla op.
Hoe authenticatie daadwerkelijk werkt
TrueFoundry maakt onderscheid tussen inbound authenticatie — hoe een client zichzelf bewijst aan de gateway — en outbound, hoe de gateway zichzelf bewijst aan Slack. De outbound kant is waar het hele beveiligingsverhaal om draait.

Inbound — vier ondersteunde methoden:
Lees de rij over Virtual Accounts zorgvuldig door voordat je er een kiest voor Slack: die tokens geven elke aanvraag dezelfde toegang — precies het probleem met het gedeelde token dat hierboven is beschreven. Gebruik inbound een PAT of een IdP-token, zodat de gateway weet welke mens de aanroep doet.
Outbound — voor Slack is dit OAuth2 Authorization Code, en dit is de reden waarom de integratie überhaupt veilig kan worden uitgevoerd. Elke werknemer autoriseert zijn eigen Slack-account bij het eerste gebruik. TrueFoundry slaat het OAuth refresh-token van die gebruiker op, roteert het automatisch en injecteert het alleen wanneer die gebruiker een Slack-tool aanroept. Elke gebruiker heeft dus alleen toegang tot zijn eigen berichten en kanalen — een agent die optreedt voor een support engineer ziet de kanalen van die engineer en niets anders.
Om te autoriseren, open je de Tools-sectie van de server, klik je op Connect Now en keur je de aanvraag goed. Je wordt omgeleid naar Slack; TrueFoundry ziet jouw Slack-wachtwoord nooit.

Het praktische effect is dat het eigen permissiemodel van Slack het zware werk doet. Verwijder iemand uit een besloten kanaal en zijn agent verliest ook de toegang daartoe; deactiveer zijn account en de toegang van de agent vervalt direct — een eigenschap die niet mogelijk is met een gedeeld credential. Gebruikers authenticeren hier twee keer: één keer bij de gateway en één keer bij Slack, wat toewijzing per gebruiker mogelijk maakt. Zie MCP authenticatie voor de opbouw van deze flows.
Tools afbakenen voordat je ze uitrolt
Scopes bepalen de buitenste grens; het tabblad Tools bepaalt wat daarbinnen bereikbaar is. Zodra een gebruiker heeft geautoriseerd, verschijnt elke tool die de server aanbiedt op die plek.

Schakelaars per tool. Schakel een tool uit en deze wordt volledig weggelaten uit de tools/list-antwoorden — clients zien de tool nooit en deze kan niet worden aangeroepen. Voor Slack is het uitschakelen van alles wat schrijft de meest waardevolle toepassing: een agent die geen berichtverzendende tool kan aanroepen, kan niet worden overgehaald om een bericht te plaatsen, ongeacht wat er in een opgesteld kanaalbericht staat. Doe beide — verwijder chat:write in het manifest en schakel de schrijf-tools hier uit — zodat een toekomstige scopewijziging het plaatsen van berichten niet stilzwijgend opnieuw inschakelt.
Enable new tools by default. Als dit aan staat, verschijnen nieuwe upstream tools automatisch en groeit het functionaliteitsbereik van je agent zonder dat je iets hoeft te doen. Als dit uit staat, zijn alleen de tools beschikbaar die je expliciet hebt ingeschakeld. Schakel dit uit voor een server met zoveel toegang tot privéconversaties.
Bulk Action. Verandert elke rij in selectievakjes, zodat je in één keer een gecureerde toegestane lijst kunt instellen.

Je kunt ook op het potloodje bij een tool klikken om te wijzigen hoe deze aan het model wordt gepresenteerd:

De Description override (tot 20.000 tekens) stuurt de toolselectie — nuttig om het model te vertellen welke kanalen binnen de scope vallen. MCP Tool Annotations markeren een tool als Read-only of Destructive, waarbij readOnlyHint of destructiveHint wordt ingesteld voor clients die dit ondersteunen. Markeer elke tool voor het verzenden van berichten en het schrijven van canvases als Destructive; het onderstaande goedkeuringsbeleid haakt precies daarop aan.
Wie wat mag doen: medewerkersrollen
Toegangsbeheer wordt gekoppeld aan gebruikers, teams of virtuele accounts, op twee dimensies: welke servers een identiteit kan bereiken, en welke tools binnen een server aangeroepen kunnen worden.

Medewerkerslidmaatschap is de grove toegangspoort — het bepaalt wie de server überhaupt kan bereiken voordat OAuth de informatie inperkt die ze zien. Het gebruikt hetzelfde MCP toegangsbeheer model als elke andere server in je register.
Menselijke goedkeuring voor schadelijke (destructive) tools
Het volledig uitschakelen van schrijfrechten is een bot middel. Soms wil je wel dat een agent berichten plaatst — een aankondiging van een release, een overdracht van een storingsdienst — maar alleen niet onbeheerd. Daar is het goedkeuringsbeleid voor bedoeld: een bewaakte aanroep wordt vastgehouden in plaats van uitgevoerd, er wordt een goedkeuringsaanvraag aangemaakt en de goedkeurders worden op de hoogte gesteld. Zodra een mens de aanvraag goedkeurt, slagen aanroepen gedurende een instelbaar tijdsbestek, waarna er opnieuw goedkeuring nodig is.
Maak een beleid aan onder AI Gateway → Policies → MCP Tool Approval (momenteel gemarkeerd als Beta in de console):

Elk beleid vermeldt de servers die het bewaakt en kiest een approval scope:
Dit is waar de annotaties hun nut bewijzen: markeer de tools voor het plaatsen van berichten en het schrijven van canvases één keer als Destructive, bewaak deze klasse met approval_scope: destructive, en je hoeft nooit meer afzonderlijke toolnamen op te sommen. Wanneer scopes elkaar overlappen, wint de meest specifieke: named > destructive > all.
Validity is ofwel Once (één enkele uitvoering, de volgende aanroep heeft opnieuw goedkeuring nodig) of tijdsgebaseerd (een duur in minuten). Wanneer regels conflicteren, wint de meest restrictieve — Once wint van een venster van 10 minuten, wat weer wint van een venster van 30 minuten. Voor alles wat in een kanaal spreekt, is Once de verstandige instelling.
Goedkeurders ontvangen een melding via e-mail, Slack, PagerDuty of MS Teams, en beoordelen aanvragen in de console:

Elke aanvraag toont de tool, het beleid, wie de aanvraag heeft gedaan en de daadwerkelijke argumenten — zo kan een goedkeurder de exacte berichttekst en het bestemmingskanaal lezen alvorens akkoord te geven. Die preview is het belangrijkste onderdeel bij een communicatieserver: je keurt een specifieke zin goed, niet een hele categorie van acties. Zolang de aanvraag in behandeling is, ontvangt de aanroeper een JSON-RPC resultaat met _meta.approval_status: "pending" in plaats van een foutmelding, zodat een goed functionerende agent kan wachten en het opnieuw kan proberen.
Twee details die handig zijn om te weten: goedkeuringen zijn afgebakend per aanvrager, dus goedkeuren voor één persoon betekent niet dat het voor het hele team is goedgekeurd; en een weigering blokkeert niemand permanent — de volgende aanroep genereert een nieuwe aanvraag. Om iemand duurzaam te blokkeren, schakel je de tool uit of verwijder je de gebruiker.
Testen in de Tool Playground
Test handmatig voordat je er een agent naar verwijst. Klik op de detailpagina van de server op Try naast een willekeurige tool, vul de argumenten in en klik op Execute Tool om de ruwe JSON te lezen. Try is uitgeschakeld voor tools die je hebt uitgeschakeld.
Test lees-tools gerust; test schrijf-tools alleen als je chat:write bewust hebt behouden, en gebruik een besloten testkanaal — een testbericht in een live kanaal blijft een echt bericht. Dit ondervangt de voor de hand liggende problemen vroegtijdig: een verwijderde scope die je toch nodig had, of een kanaal waar de gebruiker geen lid van is.
Het gebruiken vanuit je IDE
Open het tabblad How To Use voor je tenant-specifieke Gateway URL en kant-en-klare codefragmenten.

Het bevat ondersteuning voor Claude Code, VS Code, Claude Web, 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. Gebruik de URL van dit tabblad in plaats van deze zelf samen te stellen — de URL is tenant-specifiek, en een handmatig gebouwd eindpunt 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 een overzicht van requests per seconde, latency op P50/P75/P90/P99, foutpercentages per fouttype en het aantal aanvragen gerangschikt per tool.

Voor Slack is dit de manier waarop je opmerkt dat een agent bij elke stap de hele workspace doorzoekt.
Observability van de volledige aanvraag. Elke tool-aanroep wordt getracet met de identiteit van de aanroeper, toolnaam, invoer en latency, en via OpenTelemetry geëxporteerd naar Grafana, Datadog of Prometheus. De identiteit van de aanroeper is hierbij het cruciale onderdeel — wanneer er een bericht verschijnt dat niemand zich herinnert te hebben goedgekeurd, toont de trace van welke gebruiker de agent afkomstig was.
Guardrails. Guardrails voor en na de tool-uitvoering passen beleid toe op MCP tool-aanroepen — in dit geval het scannen van Slack-zoekresultaten op geheimen voordat ze het model bereiken, aangezien mensen voortdurend credentials in kanalen plakken.
Lage overhead. De gateway voegt ongeveer 3–4 ms aan latency toe en verwerkt 350+ RPS op een enkele vCPU, waardoor het zich in het kritieke pad bevindt zonder de bottleneck te worden.
Één register. Bundel een gecureerde selectie van tools van verschillende servers achter één eindpunt met een Virtual MCP Server — zodat een incident-response agent Slack-zoekrechten krijgt plus je observability-tools, en verder niets. Het is ook de schoonste manier om schrijftoegang te publiceren: houd de primaire Slack-server read-only en bied de mogelijkheid om berichten te plaatsen aan via een afgebakende virtuele server.
Toegang intrekken
Tenant-beheerders kunnen alle opgeslagen credentials op de server wissen via het menu met de drie puntjes naast Edit:

Revoke all tokens verwijdert elke auth override en opgeslagen OAuth token voor alle gebruikers en virtuele accounts op die server, treedt in werking bij het volgende verzoek en wordt vastgelegd in Activity Logs. Het is onomkeerbaar — iedereen moet daarna opnieuw OAuth-toestemming geven.
Eén belangrijke beperking: dit verwijdert alleen tokens uit de gateway en trekt de toestemming bij Slack niet in. Verwijder of herinstalleer bij een echt incident de app ook in de workspace-instellingen van Slack en roteer de client secret. De actie is alleen zichtbaar voor tenant admins.
Valkuilen die goed zijn om te weten
Model Context Protocol staat standaard uit op de Slack-app. De meest voorkomende configuratiefout is een correct geconfigureerde server die niets retourneert, omdat Features → Agents & AI Apps → Model Context Protocol nooit is ingeschakeld. Controleer dat eerst.
Het manifest is een menu, geen standaard. Zie het als een superset waar je in moet snijden — scopes die je nooit verleent, kunnen later ook niet verkeerd worden geconfigureerd.
OAuth per gebruiker betekent intrekking per gebruiker. De toestemming van elke persoon staat op zichzelf. Iemand verwijderen uit collaborators ontneemt direct hun gateway-toegang; het intrekken van de toestemming aan de Slack-zijde is een afzonderlijke actie.
Gerelateerde artikelen
- What Is an MCP Gateway: Architecture and Use Cases — de architecturale introductie
- MCP Authentication Explained — inbound en outbound auth-stromen
- MCP Access Control: Securing AI Agents with an MCP Gateway — permissies op tool- en serverniveau
- Virtual MCP Server Explained — tools bundelen in één endpoint
- MCP Server Security Best Practices — de bredere beveiligingschecklist
Conclusie
De Slack MCP server is een van de meest waardevolle integraties die je aan een agent kunt geven, omdat het meeste van wat een bedrijf weet zich bevindt in de gesprekken in plaats van in de documenten. Het is ook de plek waar een onzorgvuldige verbinding de meeste schade aanricht — niet omdat een tool call de productie kan verstoren, maar omdat de data privé is en het schrijfpad communicatie betreft.
De maatregelen zijn specifiek: verklein de OAuth-scopes, gebruik OAuth per gebruiker zodat elke agent precies het zicht van één mens op de workspace erft, schakel de schrijf-tools uit op de gateway, plaats alles wat overblijft achter een mens die het bericht eerst leest, en houd een getracete log bij. Het draaien van Slack als een remote MCP server op TrueFoundry geeft je dat allemaal zonder dat je iets hoeft te bouwen.
TrueFoundry AI Gateway levert een latentie van ~3–4 ms, verwerkt 350+ RPS op 1 vCPU, schaalt moeiteloos horizontaal en is klaar voor productie, terwijl LiteLLM last heeft van hoge latentie, moeite heeft boven een gemiddeld aantal RPS, geen ingebouwde schaling heeft en het meest geschikt is voor lichte workloads of prototypes.



Eén gateway voor elk LLM, elke agent en elke MCP-server
Recente blogs
Veelgestelde vragen
What is the Slack MCP server?
It’s Slack’s official remote Model Context Protocol server, hosted at https://mcp.slack.com/mcp. It exposes Slack as tools an AI agent can call — searching messages and files, reading channel and thread history, posting messages, working with canvases, and looking up users. Agents connect over a URL and authenticate with OAuth rather than running anything locally.
What tools does the Slack MCP server expose?
Search across channels, group DMs, DMs, files, and users; conversation history for channels, groups, and DMs; message sending; canvas read and write; and user profile lookup. Which are available depends on the OAuth scopes you grant the Slack app, and on TrueFoundry each tool can be individually enabled, disabled, re-described, or annotated.
Is the Slack MCP server safe to use in an enterprise?
Yes, with scoping — but the bar is higher than for a code-oriented server, because Slack holds private conversations. Three things do most of the work: per-user OAuth so each agent sees only its user’s channels, trimmed scopes so DM access and posting are never granted unless needed, and human approval on anything that writes.
Can I deploy TrueFoundry in my own VPC or on-prem?
Yes. TrueFoundry runs in your VPC, on-prem, air-gapped, or hybrid, so prompts and responses never leave your domain even as you route across many providers.
Ondersteunt TrueFoundry MCP en AI-agents in het algemeen?
Ja. Het omvat een MCP Gateway, een Agent Gateway, en een MCP & Agents Register met toegangscontrole op toolniveau. Agents op LangGraph, CrewAI, AutoGen, of een aangepast framework kunnen allemaal centraal worden gereguleerd.
Integreert het met mijn bestaande observability-stack?
Ja. De gateway is OpenTelemetry-compliant en sluit aan op Grafana, Datadog, Prometheus, of uw gewenste stack. Het traceert elk verzoek van prompt tot tool- en modeluitvoering, zodat u uniforme logging krijgt zonder wat u al draait te hoeven vervangen.












.png)

.webp)



.webp)








.webp)





