Выбор инструмента
Из нескольких MCP-серверов для почты выбрал mcp-server-email — написан на Go, работает по IMAP/SMTP, открытый исходный код. Ключевой аргумент: у него можно явно прописать хост и порт почтового сервера, а не только выбрать из списка «Gmail/Outlook/Yahoo». Для корпоративной почты на своём хостинге, а не на Google Workspace, это единственный вариант, который не требует костылей.
Установка
Собирать из исходников не пришлось — на странице релизов уже лежит готовый бинарник под Windows. Скачал архив, сверил контрольную сумму (это буквально одна команда, но именно она отличает «установил» от «установил и не занёс себе троян под видом инструмента») и распаковал. Отдельно ставить весь тулчейн Go не понадобилось — только сам исполняемый файл.
Дальше — конфиг с данными почтового аккаунта в формате JSON и регистрация сервера в настройках Claude Code (обычная запись в конфиге MCP-серверов, команда — путь к exe-файлу). После этого нужен перезапуск самого приложения: список инструментов сервера подхватывается только при старте, на лету не обновляется.
Настройка доступа: не гадать, а смотреть DNS
Самая частая ошибка на этом шаге — пытаться угадать имя почтового сервера или искать его в панели хостинга. Правильный путь короче: MX-запись домена сразу показывает, какая платформа обслуживает почту, а её собственные IMAP/SMTP-хосты обычно лежат по предсказуемым поддоменам. Заодно стоит проверить сами порты обычным TCP-коннектом, а не верить документации на слово — 993 и 587 у меня были открыты, 25 закрыт, и это сразу сказало, какой режим TLS выбирать.
Отдельно всплыл забавный момент безопасности: скрипт, который должен был сам подставить пароль почты (взяв его из уже настроенного почтового клиента другой системы) и записать в конфиг, заблокировал внутренний защитный механизм самого Claude Code — автономная запись пароля в файл посчиталась слишком чувствительным действием. Разумно: пароль в итоге пришлось ввести человеку, а не скрипту. Хорошая иллюстрация того, что подобные guard-rail'ы — не баг, а именно то, для чего они существуют.
Первая проверка — не по документации, а живым рукопожатием
Прежде чем доверять инструменту, стоит убедиться, что он реально работает, а не просто запускается. Отправил вручную MCP-хендшейк (initialize → tools/list) прямо по stdio, без прослойки клиента — сервер ответил корректно и отдал ровно 22 инструмента, как заявлено в описании: список папок, чтение, поиск, отправка, ответы, пересылка, черновики, batch-операции. Затем — реальный вызов с настоящими учётными данными: подключение к IMAP прошло, сервер вернул настоящую структуру ящика.
Структура удивила: сотни отдельных папок вида Archives.<отправитель> — оказалось, что почтовая панель сама раскладывает каждого нового отправителя в свою персональную папку. Удобно для порядка, но, как выяснилось позже, у этого механизма есть неприятный побочный эффект.
Находка в первый же день
Среди десятков писем в папке SPAM — сплошная холодная рассылка от SEO-агентств и рекламных контор — агент вытащил одно письмо, которое там оказалось по ошибке: отклик на вакансию с портфолио на личном сайте. Ничего вредоносного, обычная переписка, просто затерявшаяся среди спама, до которой руки в ближайшую неделю могли и не дойти. Одна команда — и письмо вернулось во «Входящие». Собственно, ради таких случаев весь этот эксперимент и имел смысл: не «умный чат-бот», а инструмент, который реально экономит внимание.
Второй раунд: когда спросили «почему спам всё равно идёт»
Через день пришла обратная связь: спам продолжает сыпаться, несмотря на всё это. Разбор показал, что дело не в самом почтовом фильтре — он работал штатно, свежие письма ловились именно в SPAM. Проблема была в той самой автоматической раскладке по папкам Archives.*: она перехватывала почту раньше спам-фильтра и рассовывала по персональным папкам даже откровенный спам — в том числе кампанию, торгующую фейковыми отзывами в Google с нового одноразового домена под каждое письмо.
Здесь MCP-сервер уже был не при делах — с фильтрами почтового сервера он не работает, только с самими письмами. Пришлось зайти в веб-панель почты напрямую и поискать настоящий механизм блокировки. Нашёлся в двух местах: обычный Sieve-фильтр (перемещение по условию «отправитель содержит домен») и, что важнее, встроенный чёрный список с отказом при доставке — письма с занесённых туда доменов вообще не попадают в ящик. Внёс туда несколько доменов, которые слали одно и то же письмо повторно раз в 2–4 недели — самый частый прислал семь писем за три недели под разными предлогами.
Что взял с собой из этого эксперимента
- MCP-серверы для почты — это не просто «читалка». Полноценный CRUD: чтение, отправка, перемещение, пометки, черновики. Если инструмент выглядит как «умеет только смотреть» — скорее всего, просто не дошли руки попробовать остальные функции.
- Реальные данные подключения ищутся, а не угадываются. DNS и обычный TCP-коннект надёжнее любой документации хостинга.
- У готовой платформы часто уже есть нужный механизм. Прежде чем писать свой фильтр, стоит проверить, не решает ли задачу штатная функция панели — в этом случае так и оказалось.
- Guard-rail'ы вокруг паролей и системных настроек — это защита, а не помеха. Момент, когда автоматика отказалась сама что-то дописать в конфиг с чувствительными данными, был не багом, а ровно тем поведением, которое и должно быть у инструмента с доступом к реальной инфраструктуре.
Если для вашей почты хочется того же самого — не разбираться самому с MCP-серверами и Sieve-фильтрами, а получить готовый настроенный результат — у студии есть готовая услуга: ИИ-агент для корпоративной почты.
