Изначально задача звучала довольно бытово: я хотел спросить ChatGPT, что мне писал конкретный человек в Telegram, и получить ответ.
Не копировать переписку руками.
Не экспортировать сообщения.
Не открывать второй клиент рядом.
Просто написать:
Что Лена писала мне последним в Telegram?
И чтобы модель действительно сходила в мой Telegram и посмотрела.
Оказалось, между этими двумя действиями почему-то до сих пор лежит довольно большая техническая дыра.
Так появился telegram-business-mcp.
Я хотел не Telegram-бота
Telegram хорошо интегрируется с ботами.
Но бот — это отдельный собеседник.
Мне хотелось другого.
У меня уже есть ChatGPT. Есть Claude. Там находится модель, контекст текущего разговора, инструменты и всё остальное.
Я не хотел переносить ИИ в Telegram.
Я хотел сделать наоборот:
принести Telegram в интерфейс, где я уже разговариваю с ИИ.
Чтобы можно было спросить:
— о чём мы разговаривали с Пашей неделю назад;
— найди сообщение, где обсуждали мониторинг;
— покажи последние сообщения от Лены;
— что мне присылали вчера;
— ответь человеку вот этим текстом.
И всё это — прямо из ChatGPT Web или Claude Web.
В какой-то момент разница показалась мне важной.
Это не ещё один AI-бот внутри мессенджера.
Мессенджер сам становится источником данных и инструментом для модели.
Самый очевидный путь мне не понравился
Для работы с личным Telegram обычно хочется взять MTProto и авторизоваться как пользователь.
Технически это мощный вариант. Можно получить историю аккаунта и работать почти как полноценный клиент.
Но вместе с этим появляется user session.
И вот здесь меня конструкция перестала радовать.
Файл с такой сессией фактически представляет доступ к аккаунту. Если он оказывается не там, где нужно, проблема уже не ограничивается каким-нибудь локальным архивом сообщений.
Поэтому я посмотрел в другую сторону — Telegram Business.
У Telegram есть официальный механизм подключения Business-бота к личному аккаунту.
Бот получает сообщения из подключённых диалогов и может отвечать от имени владельца аккаунта.
То есть вместо:
LLM → MTProto → мой Telegram-аккаунт
можно собрать:
LLM → MCP → Telegram Business Bot API
Без user-session.
С обычным bot token, который можно отозвать через BotFather.
Компромисс у этого решения тоже настоящий: Telegram не отдаёт Business-боту переписку задним числом.
Подключил сегодня — история начинает собираться сегодня.
Год старых сообщений magically не появится.
И мне это даже нравится как инженерное ограничение: система не притворяется полноценным Telegram-клиентом там, где им не является.
Потом появился архив
Если просто проксировать текущие апдейты Telegram в модель, получается довольно бесполезная штука.
Самое интересное начинается, когда сообщения накапливаются.
Поэтому между Telegram и MCP появился SQLite.
Схема стала такой:
Telegram → collector → SQLite → MCP → ChatGPT / Claude
Collector постоянно забирает новые сообщения и складывает их локально.
MCP-сервер уже работает не непосредственно с Telegram, а с этим архивом.
Получилось несколько полезных вещей сразу.
Можно получать последние сообщения.
Можно открыть конкретный диалог.
Можно искать по всей накопленной истории.
Можно искать даже по расшифровкам голосовых, если включена локальная транскрибация.
И главное — история находится на моём сервере и постепенно растёт сама.
Я один раз подключил Telegram и дальше почти перестал думать о том, как данные туда попадают.
Клиентская часть оказалась одной ссылкой
Это, пожалуй, моя любимая часть всей конструкции.
На компьютере с ChatGPT ничего устанавливать не нужно.
Нет browser extension.
Нет локального proxy.
Нет отдельного stdio-процесса рядом с браузером.
MCP работает удалённо по HTTPS.
Поэтому со стороны клиента вся интеграция сводится практически к одному URL.
В ChatGPT Web добавляется remote MCP.
В Claude Web — тот же сервер как custom connector.
И после этого два совершенно разных AI-интерфейса получают одинаковый набор Telegram-инструментов.
С этого момента я понял, что делаю уже не интеграцию «Telegram с ChatGPT».
ChatGPT здесь вообще перестал быть обязательной частью архитектуры.
Получилось:
любой MCP-клиент → один интерфейс → мой Telegram
Сегодня это ChatGPT и Claude.
Завтра это может быть другой клиент, который понимает MCP.
Модель получила не только память
Сначала я сделал чтение.
Это безопасная и понятная часть.
Модель умеет:
telegram_list_chats
telegram_recent_messages
telegram_get_messages
telegram_search_messages
telegram_find_chat
Можно сказать:
«Найди последние сообщения Паши».
И получить реальные сообщения.
Можно спросить:
«Что мы обсуждали про мониторинг n8n?»
И модель сама ищет по архиву.
Но потом возник совершенно логичный следующий вопрос.
Если модель уже понимает, кому я хочу ответить и о чём идёт разговор, почему я после этого должен открывать Telegram и отправлять сообщение руками?
Так появился telegram_send_message.
И вот здесь система слегка поменяла смысл.
Я могу находиться в ChatGPT, обсуждать с моделью переписку, сформулировать ответ и после подтверждения отправить его туда же.
Получатель увидит сообщение от меня.
Не от отдельного Telegram-бота.
То есть цепочка теперь выглядит примерно так:
человек → Telegram → архив → LLM → решение → Telegram → человек
ИИ оказался не рядом с мессенджером.
Он оказался поверх него.
Запись я специально выключил по умолчанию
Чтение архива и отправка сообщения — два совершенно разных уровня риска.
Поэтому свежая установка работает read-only.
Отправку нужно включать отдельно.
Есть ещё несколько ограничений.
Нельзя придумать случайный chat_id и заставить сервер написать незнакомому человеку. Отправка разрешена только в диалоги, которые уже существуют в архиве.
Каждое отправленное сообщение логируется и возвращается обратно в архив.
Сам MCP tool помечен как изменяющий состояние.
Но главный предохранитель пока остаётся модельным: перед отправкой модель должна подтвердить получателя и текст.
Это не идеальный hard gate.
Если когда-нибудь захочу сделать режим с более жёстким контролем, очевидная архитектура здесь двухфазная:
prepare_send → confirm_send
Пока я сознательно этого не сделал.
Мне нужен был инструмент «ответь за меня после подтверждения», а не отдельная система согласования сообщений.
Самое странное произошло уже после того, как всё заработало
Я несколько дней думал, что пишу Telegram-коннектор.
Потом начал им пользоваться.
И формулировка перестала сходиться.
Потому что Telegram в этой системе уже не интерфейс.
Интерфейсом стал ChatGPT.
Или Claude.
Telegram остался транспортом, историей переписки и местом, где находятся другие люди.
Раньше я делал примерно так:
вспомнить → открыть Telegram → найти чат → найти сообщение → прочитать → подумать → написать
Теперь иногда получается:
спросить
Вся середина выполняется инструментами.
Самый показательный момент был совершенно идиотским.
Я спросил ChatGPT, что мне написал человек.
Он нашёл переписку.
Мы сформулировали ответ.
Я сказал отправить.
Сообщение появилось в Telegram.
Никакой отдельной магии на экране не произошло.
И именно поэтому эффект оказался странным.
Граница между «поговорить с моделью о моей жизни» и «дать модели посмотреть в реальную систему» внезапно стала очень тонкой.
MCP здесь оказался важнее конкретной модели
Можно было написать отдельную интеграцию под ChatGPT.
Потом отдельную под Claude.
Потом ещё одну под следующий интерфейс.
Но тогда Telegram был бы интегрирован с продуктами.
MCP позволяет интегрировать его с классом продуктов.
Один сервер описывает инструменты.
Клиент решает, как ими пользоваться.
Поэтому сейчас один и тот же backend работает из ChatGPT Web и Claude Web.
И это, наверное, главный вывод всего эксперимента.
Мне всё меньше интересно писать «AI-функцию для продукта X».
Гораздо интереснее сделать источник данных или действие доступным модели через общий протокол — а дальше посмотреть, какие интерфейсы вокруг него появятся.
Что здесь не идеально
Истории до момента подключения нет.
Если collector долго не работает, Telegram тоже не будет бесконечно держать апдейты.
Поэтому нормальный вариант — сервер, работающий постоянно.
Remote MCP требует доступный HTTPS endpoint.
Если включена отправка, секрет MCP становится сильно ценнее, чем в read-only режиме.
SQLite — отличный вариант для персонального архива, но я бы не стал автоматически превращать эту архитектуру в корпоративный multi-tenant продукт.
И вообще Telegram Business API накладывает свои ограничения.
Это не новый Telegram-клиент.
Это конкретный мост с конкретными границами.
Но именно эта ограниченность и позволила мне собрать систему достаточно простой, чтобы реально использовать её самому.
Выложил всё это в open source
Обычно мои такие штуки остаются жить где-нибудь на сервере в состоянии:
«работает — не трогай».
В этот раз решил сделать иначе.
Привёл проект в состояние, которое можно поднять отдельно, написал README, SETUP, Docker-конфигурацию, systemd units, переменные окружения и выложил код.
Репозиторий называется:
OlegNickeshin/telegram-business-mcp
Лицензия — Apache 2.0.
Поднять можно на своём сервере.
И, кажется, для меня это тоже небольшое изменение.
Я довольно долго собирал интеграции как конечные решения под конкретную задачу.
Здесь получилось сделать не конечную систему, а кусок инфраструктуры.
Он ничего особенно интересного не делает сам.
Он просто даёт ИИ доступ туда, куда раньше ему было неудобно дотянуться.
А потом интересное начинается уже сверху.
Кажется, я наконец понял, что собрал
Не Telegram-бота.
Не архив сообщений.
Не плагин для ChatGPT.
И даже не совсем MCP-сервер.
Скорее небольшой слой между моей коммуникацией и моделями.
Снизу Telegram.
Сверху любой ИИ, который умеет работать с MCP.
Посередине несколько довольно скучных инструментов: найти, прочитать, посмотреть фотографию, отправить сообщение.
Но иногда именно скучные инструменты сильнее всего меняют интерфейс.
Потому что после них появляется возможность написать модели:
«Посмотри, что там было, и ответь».
И больше никуда не идти.