slack-mcp-server : accéder à Slack depuis un client MCP, avec ou sans permissions

Le problème : un assistant qui ne voit pas vos conversations

Un client MCP sait lire des fichiers, lancer des commandes, interroger des API. Il ne sait pas ce qui s'est dit dans un canal Slack la semaine dernière. Combler ce trou demande normalement de créer une app Slack, de faire valider des scopes par un administrateur, d'installer un bot dans le workspace, puis de gérer le renouvellement des jetons. Sur un workspace d'entreprise, cette chaîne d'approbations peut prendre des semaines, et elle laisse une trace : l'app apparaît dans la liste des intégrations, ses scopes sont auditables.

korotovsky/slack-mcp-server vise précisément ce point de friction. Le README annonce deux modes : OAuth, avec des jetons « sans avoir à rafraîchir ni à extraire les jetons du navigateur », et un mode qualifié de furtif, « sans permissions ni scopes dans le workspace ». Le public visé est donc l'ingénieur qui veut interroger son historique Slack depuis un assistant sans monter un dossier d'intégration. Le dépôt est publié sous licence MIT, ce qui autorise la réutilisation et la modification du code, y compris dans un contexte commercial, à condition de conserver l'avis de licence. Ce n'est pas un avis juridique : la conformité d'un accès non déclaré à un workspace relève de vos propres règles internes et des conditions d'utilisation de Slack, que ce projet ne traite pas.

Quatre outils, deux modes d'authentification

Le serveur expose quatre outils MCP. conversations_history récupère les messages d'un canal ou d'un DM à partir d'un channel_id, accepté sous forme d'identifiant Cxxxxxxxxxx ou de nom commençant par # ou @. conversations_replies fait de même pour un fil, à partir d'un channel_id et d'un thread_ts au format 1234567890.123456. conversations_add_message publie un message, dans un canal ou dans un fil si thread_ts est fourni. conversations_search_messages interroge les messages avec des filtres facultatifs : filter_in_channel, filter_in_im_or_mpim, et d'autres que le README tronque.

La pagination est uniforme : la dernière ligne et la dernière colonne de la réponse servent de curseur pour l'appel suivant. Le paramètre limit accepte soit une durée (1d, 1w, 30d, 90d) soit un nombre de messages (50). Il doit être vide quand un cursor est fourni. Le README signale que 90d correspond à la limite par défaut de l'historique sur l'offre gratuite, ce qui laisse entendre que des limites de rétention existent côté Slack et que le serveur ne les contourne pas.

Deux fonctions annexes changent l'usage réel. D'abord le cache des utilisateurs et des canaux, qui évite de résoudre les mêmes identifiants à chaque appel. Ensuite l'intégration des informations utilisateur dans les messages, ce qui donne du contexte à un modèle qui ne connaît pas les identifiants de votre organisation. Le projet annonce aussi un accès aux messages non lus, avec un tri par priorité (DM, puis canaux partenaires, puis internes), un filtrage sur les @mentions et la possibilité de marquer comme lu. Cette combinaison ressemble davantage à un outil de veille qu'à un simple lecteur d'historique.

Ce que le mode furtif implique vraiment

C'est la promesse centrale du projet et c'est aussi sa zone la plus floue. Le README affirme qu'on peut exécuter le serveur « sans permissions ni scopes dans le workspace », sans expliquer par quel mécanisme l'accès est obtenu. Aucun détail sur la façon dont les identifiants sont fournis dans ce mode, ni sur ce qui se passe quand la session expire. Le mode OAuth est mieux décrit : des jetons, sans rafraîchissement ni extraction depuis le navigateur.

Cette asymétrie documentaire a une conséquence pratique. Le mode furtif déplace le risque plutôt qu'il ne le supprime. Un bot installé est visible, révocable depuis l'interface d'administration, et ses scopes sont connus. Un accès qui ne déclare rien ne bénéficie d'aucun de ces garde-fous. Pour un administrateur Slack, c'est exactement le type d'accès qu'on cherche à détecter. Pour un développeur qui teste sur son propre workspace, c'est un gain de temps réel. La même fonctionnalité n'a donc pas la même valeur selon qui l'utilise.

Le reste du README suggère que le projet prend au sérieux les environnements contraints : support de GovSlack, des workspaces Enterprise, et configuration d'un proxy pour les requêtes sortantes. Ces éléments indiquent un usage en organisation, pas seulement en bidouille personnelle. Il y a là une tension que la documentation ne résout pas.

Mise en route et variables d'environnement

Le serveur se compile en Go et se lance comme un binaire unique. Il accepte trois transports : Stdio, SSE et HTTP. Le choix conditionne le client MCP que vous pouvez utiliser : Stdio convient à un assistant lancé localement, HTTP et SSE à un service partagé ou distant. Le README ne fournit pas de ligne de commande complète ni d'exemple de configuration de client, il faut donc se référer au dépôt pour les détails d'invocation.

Le point à retenir côté configuration est la variable SLACK_MCP_ADD_MESSAGE_TOOL. L'outil conversations_add_message est désactivé par défaut, volontairement. Pour l'activer, on définit cette variable. Si on lui donne une liste d'identifiants de canaux séparés par des virgules, l'écriture n'est autorisée que dans ces canaux précis. Ce réglage est le garde-fou principal du projet : un assistant qui peut publier dans n'importe quel canal est un assistant qui peut divulguer une information interne au mauvais endroit. Restreindre la liste est la première chose à faire après l'installation.

Le README mentionne une section Environment Variables pour les autres réglages, mais le contenu fourni s'arrête avant. Les clés liées au choix du transport, aux jetons OAuth et au proxy ne sont donc pas vérifiables ici. Si vous prévoyez un déploiement, c'est cette section qu'il faut lire en premier dans le dépôt.

La recherche, angle mort des jetons de bot

Le README est explicite : conversations_search_messages n'est pas disponible avec les jetons de bot, ceux qui commencent par xoxb-. La raison donnée est que ces jetons ne peuvent pas appeler l'API search.messages. Ce n'est pas une limite du projet, c'est une contrainte de la plateforme Slack, et elle est correctement documentée.

L'effet est néanmoins structurant. Un déploiement classique, avec une app installée et un jeton de bot, perd l'outil de recherche et ne conserve que la lecture d'historique, la lecture de fils et la publication. Or la recherche est souvent ce qu'on demande en premier à un assistant : retrouver une décision, un lien, une phrase. Selon le mode d'authentification choisi, le même serveur n'offre donc pas les mêmes capacités. C'est un critère de choix à traiter avant l'installation, pas après.

Autre détail à connaître : search_query accepte une URL complète de message Slack, du type https://slack.com/archives/C1234567890/p1234567890123456. Dans ce cas, le serveur renvoie le message correspondant et ignore tous les autres paramètres. C'est pratique pour retrouver un message dont on a le lien, moins pour explorer.

Face à un bot Slack classique

L'alternative directe n'est pas un autre serveur MCP, c'est l'API Web Slack appelée depuis votre propre code, avec un jeton de bot et les scopes correspondants. La différence porte sur trois points concrets.

Le premier est la surface d'exposition. Une intégration maison expose exactement les appels que vous écrivez. Ici, quatre outils sont exposés d'un bloc à un client MCP, et c'est le modèle qui décide quand les appeler. La granularité du contrôle n'est pas la même.

Le deuxième est la pagination. Le modèle par curseur du serveur (dernière ligne, dernière colonne) est simple à implémenter, mais il faut que le client MCP sache le suivre. Une intégration maison peut choisir une autre stratégie, par exemple un parcours complet côté serveur avec stockage intermédiaire.

Le troisième est le coût d'entrée. Une app Slack demande une création, une validation de scopes et une installation. Le mode furtif annoncé ici supprime ces étapes. C'est un vrai avantage pour un prototype, et un vrai problème de gouvernance en production. Si vous avez déjà une app Slack approuvée et des scopes adaptés, l'intérêt du mode furtif disparaît largement, et l'appel direct à l'API redevient le chemin le plus prévisible.

Maintenance et coût de mise à jour

Le dépôt n'est pas archivé et le dernier push indiqué est le 16 juillet 2026. Trois versions récentes sont listées : v1.3.0 le 14 mai 2026, v1.2.3 le 3 mars 2026, v1.2.2 le 25 février 2026. Le rythme suggère un projet actif, avec des correctifs rapprochés en début d'année puis une version mineure au printemps. Le langage est Go, ce qui donne un binaire autonome, sans runtime à installer sur la machine cible. C'est un avantage de déploiement réel.

La contrepartie est que ce type de projet dépend d'une API tierce qu'il ne contrôle pas. Slack fait évoluer ses méthodes et ses règles d'accès. Un serveur qui repose sur un mode non documenté publiquement est exposé au premier changement de comportement côté plateforme. Le mode OAuth est structurellement plus stable, parce qu'il s'appuie sur un mécanisme prévu pour cet usage.

Côté licence, MIT est permissive : usage commercial, modification et redistribution sont autorisés, avec conservation de l'avis de copyright et de licence. Aucune clause de copyleft, donc pas d'obligation de publier vos modifications. Cela ne dit rien de la conformité de l'accès lui-même, qui dépend des règles de votre organisation et des conditions de Slack. Deux points restent invérifiables à partir du matériel fourni : la politique de compatibilité ascendante entre versions mineures, et la prise en charge des versions de Go. Si vous épinglez une version, prévoyez de tester chaque montée de version sur un workspace de recette avant de la pousser.

Conclusion éditoriale

À adopter si vous voulez brancher un client MCP sur un workspace Slack sans passer par une installation d'app validée par l'administrateur, et si vous acceptez de dépendre d'un jeton de session plutôt que d'un bot. À éviter si votre usage repose sur la recherche : conversations_search_messages est indisponible avec les jetons xoxb-*. Avant tout déploiement, vérifiez deux choses concrètement : la valeur exacte de SLACK_MCP_ADD_MESSAGE_TOOL, qui conditionne l'écriture, et le comportement du mode furtif sur votre workspace, puisque la documentation ne détaille pas sa mécanique.

Sources officielles

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