slack-mcp-server: Slack-Zugriff ohne Bot-Berechtigungen, aber mit Nebenwirkungen

Welches Problem der Stealth-Modus löst

Slack-Integrationen laufen üblicherweise über eine App, die im Workspace installiert wird, mit Scopes, Admin-Freigabe und einem Bot-Token. Genau diese Kette umgeht das Projekt im sogenannten Stealth-Modus: laut README läuft der Server dort ohne zusätzliche Berechtigungen und ohne Bot-Installation. Das ist der eigentliche Verkaufsgrund. Die Zielgruppe sind nicht Plattform-Teams, die eine dauerhafte Integration bauen, sondern einzelne Entwickler, die einem MCP-fähigen Assistenten Zugriff auf ihre eigenen Channels, DMs und Group DMs geben wollen, ohne vorher einen Installationsprozess im Workspace anzustoßen.

Der zweite Modus heißt OAuth. Der README beschreibt ihn als Zugriff über OAuth-Tokens, ohne Token aus dem Browser extrahieren oder manuell erneuern zu müssen. Damit existieren zwei klar getrennte Betriebsarten mit unterschiedlichem Risikoprofil: Stealth arbeitet mit vorhandenen Zugangsdaten, OAuth mit einem regulären Autorisierungsfluss. Wer den Unterschied nicht beachtet, wählt am Ende den falschen Modus für seine Umgebung.

Vier Tools, ein Cursor-Muster

Der Server stellt vier Tools bereit. `conversations_history` liest Nachrichten aus einem Channel oder einer DM, `conversations_replies` liest einen Thread über `channel_id` und `thread_ts`, `conversations_add_message` schreibt Nachrichten, und `conversations_search_messages` sucht mit Filtern. Channel-Angaben akzeptieren laut README sowohl IDs im Format `Cxxxxxxxxxx` als auch Namen mit `#` oder `@`, also `#general` oder `@username_dm`.

Das Paginierungsmuster ist bei History und Replies identisch: Die letzte Zeile der Antwort enthält den `next_cursor`, der beim nächsten Aufruf als `cursor` übergeben wird. Wichtig ist die Einschränkung, die der README explizit nennt: `limit` muss leer bleiben, sobald ein Cursor mitgeschickt wird. Wer beides setzt, arbeitet gegen die dokumentierte Schnittstelle. Das `limit`-Feld ist zudem doppelt belegt. Es nimmt entweder ein Zeitfenster (`1d`, `1w`, `30d`, `90d`) oder eine Nachrichtenzahl (`50`). Der Standardwert ist `1d`, und der README weist darauf hin, dass `90d` das Standardlimit für die History im Free-Tarif ist. Diese Grenze stammt von Slack, nicht vom Server, und sie bestimmt, wie weit zurück ein Aufruf überhaupt reichen kann.

Für Aktivitätsmeldungen wie `channel_join` oder `channel_leave` gibt es den Schalter `include_activity_messages`, standardmäßig `false`. Ohne ihn bleiben diese Einträge aus der Antwort heraus, was die Kontextgröße für ein Modell spürbar senkt.

Lesen ist erlaubt, Schreiben nicht

Der auffälligste Entwurf ist die Abschaltung des Schreibpfads. `conversations_add_message` ist standardmäßig deaktiviert und wird erst über die Umgebungsvariable `SLACK_MCP_ADD_MESSAGE_TOOL` aktiviert. Wird die Variable auf eine kommagetrennte Liste von Channel-IDs gesetzt, ist das Posten nur in genau diesen Channels möglich. Das ist eine Whitelist auf Tool-Ebene, nicht auf Token-Ebene. Der Server entscheidet also selbst, wohin geschrieben werden darf, unabhängig davon, was das Token technisch könnte.

Das ist die richtige Voreinstellung für ein Werkzeug, das ein Sprachmodell steuert. Ein Modell, das eine Nachricht in den falschen Channel schreibt, ist ein Vorfall, kein Tippfehler. Die Einschränkung auf Channel-IDs kostet Konfigurationsaufwand, weil man die IDs kennen muss, aber sie ist der einzige Mechanismus im Projekt, der den Schreibpfad begrenzt. Wer die Variable auf einen pauschalen Wahrheitswert setzt, verliert diese Begrenzung bewusst.

Inhaltlich erwartet das Tool `payload` und `content_type`, wobei `text/markdown` der Standard ist und `text/plain` als Alternative dokumentiert wird. Ein optionales `thread_ts` entscheidet, ob die Nachricht in den Thread oder in den Channel selbst geht.

Wo die Suche ausfällt

`conversations_search_messages` hat eine harte Einschränkung, die im README als Hinweis steht: Das Tool ist nicht verfügbar, wenn Bot-Tokens vom Typ `xoxb-*` verwendet werden, weil diese die `search.messages`-API nicht nutzen können. Das ist keine konfigurierbare Schwäche, sondern eine Vorgabe der Slack-API, die das Projekt nur weitergibt.

Für die Praxis heißt das: Wer den OAuth-Modus mit einem Bot-Token fährt, verliert die Suche und behält History, Replies und Posting. Wer suchen will, braucht einen anderen Tokentyp. Die Entscheidung für ein Token ist damit gleichzeitig eine Entscheidung über den Funktionsumfang, und das sollte man treffen, bevor man den Server aufsetzt.

Die Filter des Tools sind alle optional, mit einer Ausnahme: Wenn kein Filter gesetzt ist, wird `search_query` verlangt. Ein Sonderfall ist dokumentiert. Übergibt man eine vollständige Slack-Nachrichten-URL im Format `https://slack.com/archives/C1234567890/p1234567890123456`, liefert das Tool genau diese eine Nachricht zurück, und alle anderen Parameter werden ignoriert. Weitere Filter sind `filter_in_channel` (ID oder Name) und `filter_in_im_or_mpim` für DMs.

Transport, Proxy und der Rest der Konfiguration

Der Server spricht Stdio, SSE und HTTP, sodass jeder MCP-Client mit einem dieser Transportwege angebunden werden kann. Ausgehende Anfragen lassen sich laut README über einen Proxy leiten. Für Umgebungen mit Enterprise-Slack nennt das Projekt Unterstützung für Enterprise-Setups, ohne im vorliegenden Material zu beschreiben, welche Konfiguration dafür konkret nötig ist. Das ist eine Lücke: Der Begriff Enterprise Workspaces Support bleibt in der Beschreibung stehen, ohne dass ein Parameter oder eine Einschränkung genannt wird.

Zwei weitere Punkte aus der Funktionsliste sind konkret genug, um sie einzuordnen. Es gibt einen Cache für Nutzer und Channels, der wiederholte Zugriffe beschleunigen soll, und es gibt eingebettete Nutzerinformationen in Nachrichten. Beides verändert die Antwortgröße in entgegengesetzte Richtungen: Der Cache spart Aufrufe, die eingebetteten Nutzerdaten kosten Tokens im Modellkontext. Wer mit knappem Kontextfenster arbeitet, sollte diesen Punkt beim Testen beobachten.

Für ungelesene Nachrichten nennt der README eine eigene Funktion mit Prioritätssortierung (DMs vor Partner-Channels vor internen Channels), Filterung auf @mentions und Unterstützung für Mark-as-read. Die genauen Tool-Namen und Parameter dazu stehen im vorliegenden Auszug nicht, sodass hier nur die beschriebene Wirkung festgehalten werden kann.

Wann ein Bot-Token die bessere Wahl ist

Die Alternative zu diesem Projekt ist der klassische Weg: eine Slack-App mit definierten Scopes installieren und über das offizielle SDK oder die Web-API arbeiten. Der Unterschied liegt nicht in den Fähigkeiten, sondern in der Kontrolle. Eine installierte App hat einen sichtbaren Eintrag im Workspace, einen Admin, der die Scopes freigibt, und einen Widerruf, der zentral funktioniert. Der Stealth-Modus dieses Servers verzichtet genau darauf, und das ist sein Zweck wie sein Risiko.

Für ein Team, das eine Integration dauerhaft betreibt, ist die App der bessere Weg. Rechte lassen sich dort auditieren, und die Entfernung des Zugangs ist ein administrativer Vorgang statt einer lokalen Dateioperation. Für einen einzelnen Entwickler, der schnell einem Assistenten Lesezugriff geben will, ist der Stealth-Modus deutlich weniger Aufwand. Die Wahl hängt also daran, ob jemand anders als man selbst den Zugang widerrufen können muss.

Der zweite Unterschied betrifft die Suche. Eine App mit passenden Scopes kann `search.messages` nutzen, sofern der Tokentyp stimmt. Die Einschränkung auf `xoxb-*` aus dem README gilt dort genauso, weil sie von Slack kommt. Wer Suchfunktion braucht, muss in beiden Ansätzen denselben Tokentyp vermeiden.

Wartung, Lizenz und was das Projekt nicht zeigt

Das Repository steht unter MIT-Lizenz. Das erlaubt kommerzielle Nutzung und Änderungen, solange Lizenz- und Copyright-Hinweis erhalten bleiben. Für den Betrieb relevant ist das nicht wegen der Haftungsfrage, sondern wegen der Weitergabe: Wer den Server in ein eigenes Produkt einbettet, muss den Hinweis mitführen. Das ist eine technische Feststellung, keine Rechtsberatung.

Die Release-Historie im vorliegenden Material zeigt drei Versionen zwischen Februar und Mai 2026, mit einem letzten Push im Juli 2026. Das Muster deutet auf regelmäßige Pflege hin, ohne dass sich daraus ein Versprechen für die Zukunft ableiten lässt. Der Server hängt an Slack-API-Verhalten, das sich ändern kann. Die Token-Einschränkung bei `search.messages` ist ein Beispiel dafür, wie eine externe Vorgabe den Funktionsumfang bestimmt. Ein Upgrade kann daher nicht nur neue Parameter bringen, sondern auch Funktionen abschneiden, wenn Slack nachzieht.

Was das Material nicht hergibt: keine Angaben zu Rate Limits, keinen Hinweis auf Testabdeckung, keine Beschreibung, wie der Stealth-Modus technisch an die Zugangsdaten kommt. Der README bewirbt die Funktion, erklärt sie aber nicht. Wer den Server produktiv einsetzen will, muss diesen Punkt selbst klären, bevor er ihn in eine Umgebung mit echten Nachrichten lässt.

Redaktionelles Fazit

Wer einem LLM-Client lesenden Zugriff auf Slack geben will, ohne eine App im Workspace zu installieren, findet hier den passenden Weg; der Stealth-Modus ist genau dafür gebaut. Wer die Suche über `conversations_search_messages` braucht, darf kein Bot-Token verwenden, denn dieses Tool steht laut README mit `xoxb-*` nicht zur Verfügung. Vor dem Produktiveinsatz sollte man prüfen, ob das eigene Workspace die History-Grenzen des Free-Tarifs (laut README 90 Tage Standardlimit) überschreitet und ob `SLACK_MCP_ADD_MESSAGE_TOOL` überhaupt gesetzt werden muss.

Offizielle Quellen

1. Issues
2. korotovsky/slack-mcp-server on GitHub
3. License: MIT
4. README
5. Releases