Slack MCP, asystent w firmowej komunikacji

Slack MCP, czyli asystent czytający firmowe rozmowy

Slack udostępnia oficjalny serwer w protokole opisującym podłączanie narzędzi do modeli językowych. Zapowiedziany jesienią 2025 roku, ogólnie dostępny od lutego 2026, działa jako usługa zdalna pod adresem producenta, więc nie trzeba niczego uruchamiać u siebie.

Po podłączeniu asystent może przeszukiwać wiadomości i pliki, czytać kanały i wątki, wysyłać wiadomości, reagować na nie oraz odnajdywać osoby. Część możliwości, jak praca z dokumentami wspólnymi, wymaga płatnego planu Slacka, natomiast sam serwer nie kosztuje nic ponad to, co już płacisz.

Zanim przejdziemy do konfiguracji, jedna rzecz do zrozumienia najpierw, bo od niej zależy, czy wdrożenie będzie bezpieczne: model uprawnień. To on decyduje, co asystent faktycznie widzi.

Token osoby a token aplikacji

To rozróżnienie jest najważniejsze w całym tekście i najczęściej mylone przy pierwszej konfiguracji.

Token osoby działa w imieniu konkretnego użytkownika i jest ograniczony jego uprawnieniami. Jeśli nie widzisz kanału w Slacku, asystent działający na Twoim tokenie też go nie zobaczy. Dostęp do prywatnych rozmów obejmuje wyłącznie te, w których uczestniczysz.

Token aplikacji działa w imieniu zainstalowanego programu i ma uprawnienia przyznane całej organizacji. Aplikacja z szerokim zakresem widzi kanały prywatne niezależnie od tego, kto ją wywołał.

Konsekwencja jest poważna. Asystent podłączony przez token aplikacji z szerokim dostępem odpowiada tak samo każdemu, kto go zapyta, więc osoba spoza zespołu może dowiedzieć się treści rozmowy, do której nie ma wstępu. Model uprawnień Slacka przestaje wtedy działać, mimo że w samym Slacku nic się nie zmieniło.

Wniosek praktyczny jest jednoznaczny. Do zastosowań, w których asystent odpowiada konkretnej osobie, używaj uwierzytelnienia tej osoby. Token aplikacji zostaw do zadań wykonywanych w imieniu systemu, na wyraźnie ograniczonym zakresie: publikowanie powiadomień na jednym kanale, odczyt jednego kanału publicznego.

Przy serwerze oficjalnym ten wybór jest w praktyce przesądzony. Dokumentacja wymienia zakresy uprawnień dla każdego narzędzia tego serwera wyłącznie na tokenie osoby, a punkty autoryzacji wskazane dla klientów wydają właśnie taki token; token aplikacji pojawia się tam osobno, przy doświadczeniu wewnątrz samego Slacka. Najdobitniejszym przykładem jest przeszukiwanie wiadomości, bo interfejs wyszukiwania Slacka nie działa z tokenem aplikacji. Opisane wyżej ryzyko szerokiego tokenu aplikacji dotyczy więc przede wszystkim serwerów społecznościowych i pisanych samodzielnie, gdzie nic tego wyboru nie zawęża.

Zatwierdzanie i kontrola po stronie organizacji

Podłączenie nie odbywa się po cichu, i to jest dobra wiadomość dla osób odpowiadających za bezpieczeństwo.

Klient łączy się przez standardowy mechanizm autoryzacji, a administrator przestrzeni zatwierdza, które narzędzia mogą się podłączyć. Bez tego zatwierdzenia użytkownik nie doda sobie asystenta samodzielnie, nawet mając konto.

To rozwiązuje problem, który przy narzędziach zewnętrznych bywa realny: sytuację, w której połowa firmy podłącza do rozmów służbowych narzędzia, o których nikt nie wie. Tutaj lista dopuszczonych klientów jest jedna i widoczna.

Przy wdrożeniu warto podejść do tego etapowo. Zacznij od jednego zespołu i jednego klienta, na uprawnieniach ograniczonych do odczytu. Po dwóch tygodniach będziesz wiedział, do czego ludzie tego faktycznie używają, i dopiero wtedy rozstrzygaj o rozszerzeniu zakresu o operacje zmieniające stan.

Osobno rozważ, co się dzieje z treścią rozmów po stronie klienta. Serwer udostępnia dane, a to, gdzie trafiają dalej i jak długo są przechowywane, zależy od narzędzia, które je pobiera. To pytanie warto zadać przed zatwierdzeniem, a nie po.

Co asystent potrafi z tym zrobić

Warto opisać zastosowania konkretnie, bo od nich zależy, czy zakres uprawnień jest uzasadniony.

Najbardziej użyteczne jest odnajdywanie kontekstu. Pytanie o to, kiedy zapadła decyzja o zmianie terminu i kto ją podjął, prowadzi asystenta do wątku sprzed trzech miesięcy, którego nikt by nie znalazł ręcznie. To jest zastosowanie wymagające wyłącznie odczytu i dające największą wartość przy najmniejszym ryzyku.

Drugie to streszczanie. Kanał z czterystoma wiadomościami z tygodnia sprowadzony do listy ustaleń oszczędza czas osobie wracającej z urlopu, a przy okazji pokazuje, czego nie ustalono.

Trzecie to łączenie z innymi źródłami. Asystent mający dostęp jednocześnie do rozmów i do repozytorium kodu, opisanego w tekście o serwerze GitHuba, potrafi powiązać zgłoszenie z dyskusją, która do niego doprowadziła.

Czwarte to działanie: wysłanie podsumowania na kanał, przypomnienie o nierozstrzygniętym wątku, oznaczenie wiadomości. Tu zaczyna się obszar wymagający ostrożności, bo wiadomość wysłana przez pomyłkę w imieniu użytkownika jest widoczna dla wszystkich i trudna do wycofania.

Praktyczna zasada: operacje zmieniające stan powinny wymagać potwierdzenia, a nie dziać się samodzielnie. Model wywołuje narzędzia na podstawie tego, co przeczytał, a w firmowej komunikacji przeczytał również cudze wiadomości.

Limity, o których warto wiedzieć

Trzy ograniczenia decydują o tym, ile asystent faktycznie zdziała, a w opisach integracji zwykle ich brakuje.

Pierwsze to limity częstotliwości. Każde narzędzie ma własny próg, a co istotniejsze, jest to ten sam budżet, z którego korzystają Twoje pozostałe integracje, bo limity obowiązują tak samo niezależnie od tego, czy wywołanie idzie przez ten serwer, czy przez zwykłe metody interfejsu Slacka.

Drugie to plan Slacka. Na planie darmowym historia sięga dziewięćdziesięciu dni, więc asystent szukający ustalenia sprzed pół roku nie znajdzie go nie dlatego, że źle pyta, tylko dlatego, że tej wiadomości już nie widać. Na tym samym planie liczba integracji zatrzymuje się na dziesięciu aplikacjach, a dokumenty wspólne są funkcją planów płatnych.

Trzecie to katalog dopuszczonych aplikacji. Z serwera mogą korzystać wyłącznie aplikacje opublikowane w katalogu Slacka oraz aplikacje wewnętrzne organizacji, a aplikacja niepubliczna po prostu się nie podłączy. Klient musi przy tym być oparty o zarejestrowaną aplikację Slacka o stałym identyfikatorze i to on pozwala administracji zatwierdzać ruch oraz odnaleźć go później w dziennikach zdarzeń.

Ryzyka, które trzeba nazwać

Ta sekcja jest najważniejsza przy wdrożeniu i rzadko pojawia się w materiałach o integracjach.

Pierwsze ryzyko to treść wracająca z narzędzia. Wiadomości pobrane ze Slacka trafiają wprost do kontekstu modelu, a model traktuje je jako informację. Wiadomość zawierająca zdanie sformułowane jak polecenie potrafi więc wpłynąć na to, co asystent zrobi dalej, łącznie z wywołaniem innego narzędzia. W firmowej komunikacji treść pochodzi od wielu osób, w tym z kanałów, do których pisze ktoś spoza organizacji.

Drugie to zakres wynikający z tokenu aplikacji. Opisane wyżej, i to jest najczęstszy poważny błąd konfiguracji.

Trzecie to gromadzenie kontekstu. Asystent czytający rozmowy przez miesiąc buduje obraz organizacji szerszy niż ktokolwiek pojedynczy, a ten obraz trafia tam, gdzie działa klient.

Czwarte to dane osobowe. Rozmowy zawierają treści dotyczące konkretnych osób, więc ich przetwarzanie podlega tym samym regułom co inne dane pracownicze, niezależnie od tego, że siedzą w komunikatorze.

Ograniczenie tych ryzyk sprowadza się do trzech rzeczy: uwierzytelnienie na poziomie osoby zamiast aplikacji, potwierdzanie operacji zmieniających stan oraz świadomość, gdzie trafia treść po stronie klienta.

Warto dołożyć czwartą, prostą i skuteczną: ograniczenie zakresu kanałów. Asystent potrzebujący dostępu do trzech kanałów projektowych nie musi widzieć całej przestrzeni, a zawężenie zakresu przy zatwierdzaniu zmniejsza wszystkie cztery ryzyka naraz. To jest jedyne ograniczenie działające niezależnie od tego, co model przeczyta i jak zareaguje.

Konfiguracja krok po kroku

Podłączenie zajmuje kwadrans, o ile administrator zatwierdził wcześniej wybranego klienta.

Pierwszy krok należy do administracji: dopuszczenie narzędzia na liście zatwierdzonych. Bez tego kolejne kroki po prostu nie przejdą, a komunikat bywa mylący i sugeruje problem z uwierzytelnieniem.

Drugi to dodanie serwera w konfiguracji Twojego klienta. Ponieważ serwer działa zdalnie, wpis wskazuje adres usługi, a nie polecenie uruchamiające program lokalnie. Adresem jest https://mcp.slack.com/mcp, a rozmowa idzie protokołem JSON-RPC 2.0 po strumieniowanym HTTP. Starszy tryb ze zdarzeniami wysyłanymi przez serwer oraz automatyczna rejestracja klienta nie są obsługiwane, więc narzędzie, które umie tylko to, po prostu się nie połączy.

Trzeci to autoryzacja w przeglądarce. Otwiera się strona Slacka z listą uprawnień, których żąda klient, i to jest moment na ich przeczytanie. Lista mówi wprost, czy narzędzie chce wyłącznie czytać, czy również pisać i przeszukiwać rozmowy prywatne.

Czwarty to sprawdzenie, co faktycznie działa. Zapytanie o coś z kanału, do którego masz dostęp, i o coś z kanału, do którego nie masz, w kilka minut pokazuje, czy uprawnienia zachowują się tak, jak zakładałeś.

Piąty, przy pracy zespołowej, to opisanie tego w dokumentacji projektu: który klient został zatwierdzony, na jakim zakresie i do czego ma służyć. Bez tej notatki po kwartale nikt nie wie, dlaczego asystent widzi to, co widzi.

Sygnały, że coś poszło nie tak

Kilka objawów, które warto rozpoznawać, bo wskazują na konkretną przyczynę.

Asystent nie znajduje wiadomości, mimo że istnieją. Najczęściej brakuje uwierzytelnienia na poziomie osoby, bo przeszukiwanie nie działa z uprawnieniami przyznanymi aplikacji.

Asystent zna treść rozmów, do których nie masz dostępu. To sygnał, że działa na tokenie aplikacji o szerokim zakresie, i wymaga natychmiastowej zmiany konfiguracji, a nie dopisania ostrzeżenia w instrukcji.

Asystent wysyła wiadomości, o które nikt nie prosił. Zwykle oznacza, że operacje zmieniające stan nie wymagają potwierdzenia, a model uznał wysłanie za sensowny kolejny krok po przeczytaniu wątku.

Asystent odpowiada na podstawie starych informacji. Wyszukiwanie zwraca to, co pasuje znaczeniowo, a nie to, co najnowsze, więc przy pytaniach o stan bieżący warto wskazać zakres czasowy wprost.

Odpowiedzi zawierają treści, których nie było w pytaniu ani w kanale. To najpoważniejszy sygnał, bo może oznaczać, że model wykonał instrukcję znalezioną w cudzej wiadomości. Warto wtedy sprawdzić zapis przebiegu, jeśli klient go prowadzi.

Serwer oficjalny kontra alternatywy

Pierwszy wiersz jest właściwym domyślnym wyborem, bo zdejmuje utrzymanie i daje kontrolę administratorowi. Sięgaj po pozostałe wtedy, gdy zakres oficjalny nie wystarcza albo gdy polityka wymaga, żeby ruch nie opuszczał Twojej sieci.

Ostatni wiersz warto rozważyć uczciwie. Jeśli zadanie sprowadza się do wysyłania powiadomienia po zdarzeniu, zwykły mechanizm przychodzący zrobi to taniej, szybciej i bez ryzyka, że model wymyśli coś, czego nie planowałeś.

Typowe błędy

Pierwszy to podłączenie asystenta przez token aplikacji o szerokim zakresie, co przy serwerze społecznościowym albo własnym nic nie blokuje. Model uprawnień Slacka przestaje wtedy działać, a osoba spoza zespołu może poznać treść rozmowy, do której nie ma wstępu.

Drugi to przyznanie uprawnień do przeszukiwania prywatnych rozmów na poziomie aplikacji. To uprawnienie ma sens wyłącznie przy tokenie osoby, bo tylko wtedy zachowuje podział na to, kto co widzi.

Trzeci to pozwalanie modelowi na wysyłanie wiadomości bez potwierdzenia. Wiadomość wysłana przez pomyłkę w imieniu użytkownika jest widoczna dla wszystkich i trudna do wycofania.

Czwarty to traktowanie treści z kanałów jako danych bezpiecznych. Wiadomość zawierająca polecenie trafia do kontekstu modelu tak samo jak każda inna.

Piąty to zatwierdzenie klienta bez sprawdzenia, gdzie trafia pobrana treść i jak długo jest przechowywana. Serwer udostępnia dane, a resztę robi narzędzie po drugiej stronie.

Szósty to wdrożenie od razu w całej organizacji. Jeden zespół, jeden klient i uprawnienia ograniczone do odczytu przez dwa tygodnie mówią o rzeczywistym użyciu więcej niż jakikolwiek plan przygotowany z góry.

Siódmy to udostępnienie asystentowi całej przestrzeni, gdy potrzebuje trzech kanałów. Zawężenie zakresu przy zatwierdzaniu jest najprostszym zabezpieczeniem i działa niezależnie od zachowania modelu.

FAQ

Czy oficjalny serwer Slacka kosztuje?

Sam serwer nie kosztuje nic ponad to, co płacisz za Slacka, a dostęp odpowiada Twojemu planowi. Część możliwości, jak praca z dokumentami wspólnymi, wymaga planu płatnego, więc na darmowym zakres jest węższy.

Czym różni się token osoby od tokenu aplikacji?

Token osoby działa w granicach uprawnień konkretnego użytkownika, więc asystent widzi dokładnie to, co ta osoba. Token aplikacji ma uprawnienia przyznane organizacji i widzi więcej, niezależnie od tego, kto zadał pytanie. Do asystentów odpowiadających ludziom właściwy jest ten pierwszy.

Czy asystent może przeszukać moje prywatne rozmowy?

Przy uwierzytelnieniu na poziomie osoby wyłącznie te, w których uczestniczysz, bo obowiązują Twoje uprawnienia. Przy tokenie aplikacji z szerokim zakresem to ograniczenie znika, i właśnie dlatego takiego układu należy unikać przy asystentach odpowiadających użytkownikom.

Kto decyduje, jakie narzędzia można podłączyć?

Administrator przestrzeni. Klient łączy się przez standardowy mechanizm autoryzacji i wymaga zatwierdzenia, więc użytkownik nie doda sobie asystenta samodzielnie. Lista dopuszczonych klientów jest jedna i widoczna dla administracji.

Czy warto napisać własny serwer zamiast używać oficjalnego?

Zwykle nie, bo oficjalny zdejmuje utrzymanie i daje kontrolę administratorowi. Własny serwer, budowany narzędziami opisanymi w tekście o zestawie narzędzi protokołu, ma sens przy wąskim zastosowaniu z własną logiką albo przy wymogu, żeby ruch nie opuszczał Twojej sieci.

Dokumentacja stoi na stronie Slacka dla programistów, opis dla administratorów w centrum pomocy, a inne serwery znajdziesz przez rejestr protokołu.