Wybór narzędzia
Spośród kilku serwerów MCP do poczty wybrałem mcp-server-email — napisany w Go, działa po IMAP/SMTP, otwarty kod. Argument rozstrzygający: można w nim wpisać wprost host i port serwera pocztowego, a nie tylko wybrać z listy „Gmail/Outlook/Yahoo". Dla poczty firmowej stojącej na własnym hostingu, a nie w Google Workspace, to jedyny wariant, który nie wymaga obejść.
Instalacja
Kompilować ze źródeł nie trzeba — na stronie wydań leży gotowy plik wykonywalny dla Windows. Pobrałem archiwum, sprawdziłem sumę kontrolną (to dosłownie jedno polecenie, ale właśnie ono odróżnia „zainstalowałem" od „zainstalowałem i wpuściłem sobie trojana pod postacią narzędzia") i rozpakowałem. Całego środowiska Go instalować nie było trzeba — wystarczył sam plik.
Dalej konfiguracja z danymi konta pocztowego w formacie JSON i rejestracja serwera w ustawieniach Claude Code (zwykły wpis w konfiguracji serwerów MCP, komenda to ścieżka do pliku exe). Potem trzeba zrestartować samą aplikację: lista narzędzi serwera wczytuje się wyłącznie przy starcie, w locie się nie odświeża.
Dane dostępowe: nie zgadywać, tylko sprawdzić DNS
Najczęstszy błąd na tym etapie to próba odgadnięcia nazwy serwera pocztowego albo szukanie jej w panelu hostingu. Krótsza droga: rekord MX domeny od razu pokazuje, jaka platforma obsługuje pocztę, a jej własne hosty IMAP/SMTP zwykle leżą pod przewidywalnymi subdomenami. Przy okazji warto sprawdzić same porty zwykłym połączeniem TCP, a nie wierzyć dokumentacji na słowo — u mnie 993 i 587 były otwarte, 25 zamknięty, i to od razu powiedziało, który tryb TLS wybrać.
Osobno wyszedł ciekawy wątek bezpieczeństwa: skrypt, który miał sam podstawić hasło do poczty (biorąc je z już skonfigurowanego klienta pocztowego innego systemu) i zapisać w konfiguracji, zablokował wewnętrzny mechanizm ochronny samego Claude Code — samodzielny zapis hasła do pliku uznał za działanie zbyt wrażliwe. I słusznie: hasło ostatecznie wpisał człowiek, a nie skrypt. Dobra ilustracja tego, że takie zabezpieczenia to nie błąd, tylko dokładnie to, po co istnieją.
Pierwszy test — nie z dokumentacji, tylko żywym uściskiem dłoni
Zanim zaufa się narzędziu, warto się upewnić, że naprawdę działa, a nie tylko się uruchamia. Wysłałem ręcznie handshake MCP (initialize → tools/list) wprost po stdio, bez warstwy klienta — serwer odpowiedział poprawnie i oddał dokładnie 22 narzędzia, tak jak obiecuje opis: lista folderów, odczyt, wyszukiwanie, wysyłka, odpowiedzi, przekazywanie, wersje robocze, operacje wsadowe. Potem prawdziwe wywołanie z rzeczywistymi danymi logowania: połączenie z IMAP przeszło, serwer zwrócił realną strukturę skrzynki.
Struktura zaskoczyła: setki osobnych folderów w rodzaju Archives.<nadawca> — okazało się, że panel pocztowy sam rozkłada każdego nowego nadawcę do jego własnego folderu. Porządek owszem, ale ten mechanizm ma, jak się później okazało, nieprzyjemny efekt uboczny.
Znalezisko pierwszego dnia
Wśród dziesiątek wiadomości w folderze SPAM — sama zimna wysyłka od agencji SEO i firm reklamowych — agent wyłowił jedną, która trafiła tam przez pomyłkę: odpowiedź na ogłoszenie o pracę, z portfolio na prywatnej stronie. Nic szkodliwego, zwykła korespondencja, po prostu zagubiona wśród spamu, do której przez najbliższy tydzień ręce mogły nie dojść. Jedno polecenie i wiadomość wróciła do „Odebranych". Właściwie po to cały ten eksperyment miał sens: nie „mądry czatbot", tylko narzędzie, które realnie oszczędza uwagę.
Druga runda: „dlaczego spam i tak przychodzi"
Dzień później przyszła informacja zwrotna: spam nadal się sypie, mimo wszystkiego. Analiza pokazała, że rzecz nie w samym filtrze antyspamowym — działał normalnie, świeże wiadomości lądowały właśnie w SPAM. Problem tkwił w tej automatycznej segregacji do folderów Archives.*: przechwytywała pocztę wcześniej niż filtr antyspamowy i rozkładała do osobistych folderów nawet jawny spam — w tym kampanię handlującą fałszywymi opiniami w Google, z nowej jednorazowej domeny pod każdą wiadomość.
Tu serwer MCP był już bez winy — z filtrami serwera pocztowego nie pracuje, tylko z samymi wiadomościami. Trzeba było wejść wprost do panelu poczty i poszukać prawdziwego mechanizmu blokowania. Znalazł się w dwóch miejscach: zwykły filtr Sieve (przenoszenie po warunku „nadawca zawiera domenę") oraz, co ważniejsze, wbudowana czarna lista z odrzucaniem przy doręczeniu — wiadomości z wpisanych tam domen w ogóle nie trafiają do skrzynki. Wpisałem tam kilka domen, które przysyłały to samo pismo ponownie co 2–4 tygodnie; rekordzista wysłał siedem wiadomości w trzy tygodnie, za każdym razem pod innym pretekstem.
Co z tego eksperymentu zabrałem ze sobą
- Serwery MCP do poczty to nie sama „czytanka". Pełny zakres operacji: odczyt, wysyłka, przenoszenie, oznaczanie, wersje robocze. Jeśli narzędzie wygląda, jakby „umiało tylko patrzeć" — najpewniej po prostu nie doszło do wypróbowania reszty funkcji.
- Prawdziwych danych połączenia się szuka, a nie zgaduje. DNS i zwykłe połączenie TCP są pewniejsze niż jakakolwiek dokumentacja hostingu.
- Gotowa platforma często ma już potrzebny mechanizm. Zanim napiszesz własny filtr, warto sprawdzić, czy sprawy nie załatwia wbudowana funkcja panelu — tutaj tak właśnie było.
- Zabezpieczenia wokół haseł i ustawień systemowych to ochrona, nie przeszkoda. Moment, w którym automat odmówił samodzielnego dopisania danych wrażliwych do pliku konfiguracyjnego, nie był błędem, tylko dokładnie tym zachowaniem, jakiego oczekuje się po narzędziu z dostępem do prawdziwej infrastruktury.
Jeśli chcesz tego samego dla swojej poczty — bez samodzielnego rozgryzania serwerów MCP i filtrów Sieve, a od razu z gotowym, skonfigurowanym efektem — studio ma na to osobną usługę: agent AI do poczty firmowej.
