Выглядит это так:
Так же можно нажать на смайлик 🤔 и бот объяснит, почему нужно писать именно так.
Попробовать бота – t.me/kmo_ai_english_bot
Мой мини бложик по разработке – t.me/kmo_ai
Я не программист. Работаю в продажах одежды в Москве. Английский у меня B1 — школа, потом сам по приложениям, репетиторы за деньги, которых у меня особо не было.
Я задолбался говорить голосом с ChatGPT. Он перебивает. Делаешь паузу подумать, как составить фразу — он решает, что ты закончил, и начинает свой ответ. Я думаю медленно. Мне нужно 3 секунды, чтобы вспомнить глагол в Past Simple. ChatGPT мне их не даёт.
Месяц назад я решил написать свой бот. На полном вайбкодинге, потому что Python я не знал.
Что в итоге получилось технически.
Локальный Qwen на своём железе для генерации речи. Не API. Свой VPS, потому что Gemini Live API я попробовал — оказалось дорого и зависимо от лимитов Google. Локально надёжнее.
Стек:
— Python 3.11 + FastAPI на бэкенде
— aiogram 3 для Telegram-бота
— React 18 + Vite + TypeScript для Mini App
— MySQL для памяти между сессиями (бот помнит твои слова, ошибки, темы)
— Redis для кэша
— Nginx как обратный прокси
— Docker Compose
— GitHub Actions для автодеплоя.
50 тысяч ушли вот так, навскидку:
— Аренда железа под локальный LLM (~40к)
— Домен + SSL + VPS под фронт и бэк (~5к)
— Остальное на API расширения (TTS, дополнительные сервисы)
Это поверх своего железа, которое у меня уже было дома.
Как я учился.
Я открыл Cursor и начал писать с ИИ-помощником. Первый коммит — это был хеллоуворлд бот на aiogram. Через неделю — у меня уже была MySQL с миграциями. Через две — Mini App на React, который я раньше в глаза не видел.
Самый адовый момент — попытка завести WebSocket для стриминга голоса в реальном времени. Я неделю сидел и не понимал, почему голос приходит обрывками. Оказалось — я неправильно обрабатывал буферизацию аудиочанков на бэкенде. Когда заработало, я заорал так, что соседи постучали в стену.(не иронично)
За месяц вышло 120 коммитов. По 4 в день, после работы.
Дальше я начал думать, где брать пользователей.
Первым выбрал Threads. Логика была такая: там сидят люди, которые обходят блокировки → Telegram у них точно работает → плюс платформа англоязычная → возможно, на English-нишу попаду.
Я начал постить. Каждый день. 14 дней подряд. Изучал, как там устроены рекомендации. Подсматривал у местных коучей по «успешному успеху», которые хвастались количеством подписчиков в своих ТГ.
Результаты в первые дни
Через две недели у меня:
— 600 тысяч просмотров постов
— 100 подписчиков в Threads
— И 11 переходов в бот. Одиннадцать.
Сказать, что у меня опустились руки — не сказать ничего. Я сидел и смотрел на эти цифры, пытаясь понять, где у меня дырка.
Может, я плохо привлекал внимание к боту? Я писал про него прямо.
Может, аудитория была не та? Я попадал в English-нишу.
Может, формат коротких постов не конвертит? Не знаю до сих пор.
Через примерно 10 дней я перестал постить в Threads.
Тогда я пошёл на Pikabu.
Прошла неделя. В боте всего 80+ человек. Несколько дней назад сервер без перерыва работал 1316 минут — кто-то занимался полноценную сессию, потом следующий, потом ещё. Я открыл лог и сидел, смотрел, как он не останавливается. Странное чувство для парня, который пять минут назад продавал джинсы.
Один из пользователей за день занимался почти 10 часов. Десять. Я понятия не имею, кто этот человек, но я его уважаю.
Что я понял за месяц.
Первое: ИИ-инструменты в 2026 году — это уже не «волшебство», это рабочий инструмент. Я, парень без программистского образования, за месяц поднял продакшн-уровневый стек с CI/CD. Не идеальный, с дырами и багами. Но работающий.
Второе: трафик ≠ конверсия. 600 тысяч просмотров на Threads дали мне 11 активаций. Тысячи просмотров на Pikabu дали 80+. Я не понимаю до конца, в чём разница, но цифры говорят сами.
Третье: разработка одна — самое одинокое занятие в мире. Я сижу до часу ночи, чиню баги, никто не пишет в саппорт, никто не благодарит. Кроме случаев, когда кто-то напишет «классный бот, спасибо». От этого реально становится светлее.
Бот живёт тут: t.me/kmo_ai_english_bot
Полностью бесплатный. Без подписки, без лимитов, без капчи. Пока сервер тянет — будет так.
Если у вас был похожий опыт пилить пет-проект параллельно с работой — расскажите, как у вас. Особенно интересно: кто как находил первых пользователей. Threads — это явно не моё. Может, ваши находки помогут мне следующий раз не профукать 14 дней.
Неделю назад на одном из моих первых постов на Пикабу пользователь @Tainana подкинула идею: добавить в бота возможность загружать слова, которые ты сейчас учишь. Чтобы он сам подкидывал их в разговоре, а не ты тупо зубрил карточками.
Идея зашла мне сразу. Учить слова в живом диалоге, когда ты их используешь — это совсем другой опыт, чем заливать их в Anki и ждать, пока мозг сам разберётся.
Сегодня я эту фичу выкатил. Но не в полном виде, и я хочу честно объяснить почему.
Что работает: Заходишь в Mini App, открываешь раздел «мои слова», добавляешь руками те, которые сейчас учишь. Бот начинает естественно вплетать их в свою речь во время сессий. Не каждое второе предложение, а так, чтобы ты не сразу заметил — оп, это слово я добавлял вчера.
Что пока не работает: Загрузка списком из другого приложения. Только ручной ввод по одному. Это не финал, это первый шаг. Доделаю.
И ещё ограничение — максимум 100 слов на пользователя.
Объясню почему:
Причина первая, серверная. Если разрешить неограниченное количество — кто-нибудь обязательно зальёт миллионы слов и положит мне сервер. Я делаю это один, никакой команды по защите от ddos у меня нет. 100 — это компромисс между удобством и тем, чтобы я мог спать ночью.
Причина вторая, техническая. Каждое твоё слово я подмешиваю в контекст ИИ при каждой сессии. Чем больше слов — тем длиннее контекст, тем хуже ИИ соображает. Это известная проблема LLM: после определённого объёма модель начинает галлюцинировать. 100 слов — это безопасный порог, при котором качество разговора не страдает.
То есть это не «премиум-функция за деньги, базовая ограничена». Это физический предел, который я могу обойти только переписав архитектуру. Когда перепишу — расскажу.
Если у вас 100 слов в активной работе одновременно — вы уже неплохо живёте. У меня в работе обычно 20-30. После того, как несколько разговоров со словом проходит — оно уходит, добавляешь следующие.
Заходите проверить: t.me/kmo_ai_english_bot
P.S. @Tainana, отдельное спасибо. Идея реально классная.
А у вас как — учите слова списками, в приложениях, или вообще не паритесь и хватаете из контекста?
В выходные у меня обычно появляется пара свободных часов на фильм. И почти всегда это заканчивается одинаково: я трачу кучу времени на поиск и в итоге ничего не смотрю. Часто случается что нормальные фильмы ещё не вышли в цифре и непонятно когда выйдут. А проверять это руками — отдельный квест.
Я не нашёл ни одного сервиса, который одновременно: – фильтрует нормальные фильмы – и показывает только те, которые уже можно смотреть.
Поэтому сделал свой.
ТГ-канал, который раз в неделю приносит 1–3 фильма, которые уже вышли в цифровом релизе. Просто открываешь и выбираешь.
В детстве у меня уже был похожий сервис: я ходил на рынок к мужичку, который торговал на развале VHS-кассетами. Тогда он был одновременно и Кинопоиском, и Антоном Долиным, и Рутрекером.Ты просто приходил и спрашивал: “что есть нормального?” И он давал тебе выбор. Сейчас такого мужика нет. Значит, надо сделать его самому.
Попробовал по воспоминаниям с помощью Нанабананы восстановить его портрет
Подошёл к проблеме продуктово и чётко сформулировал задачу:
Когда наступает конец недели и у меня появляется редкое свободное время, я хочу получить список из 1–3 новых фильмов, которые уже вышли в цифровом релизе, чтобы хорошо провести время и быть уверенным, что не пропускаю ничего важного.
Сделал условного “нейромужика”. Он каждый день проверяет новые релизы, фильтрует их и, если находит что-то стоящее, выкладывает в Telegram.
Каждый день на GitHub по расписанию запускается скрипт, который обращается к TMDB — это большая база фильмов с бесплатным API для некоммерческих проектов. Скрипт собирает подходящие по фильтрам фильмы, проверяет, появился ли у них цифровой релиз, и отправляет в закрытую Telegram-группу “сырой” вариант карточки.
Дальше данные прогоняются через нейронку: она проверяет сырые данные, дополняет недостающее, еще раз прогоняет через фильтры и если все ок, публикует карточку в публичном канале. Система запоминает обработанные фильмы, чтобы не дублировать их.
Работает уже стабильно. Сейчас играюсь с фильтрами — хочу выйти на 50–70 нормальных фильмов в год. Канал назвал «Цифровой завоз» посмотреть можно тут: https://t.me/digitalzavoz
Анимированная аватарка в нейросети Nano Banana + ПРОМПТ
Привет! Вы знаете как это бывает — начинаешь делать одну штуку, а потом просыпаешься через неделю и понимаешь, что написал четыре MCP‑сервера, подключил к ним шедулер, собрал автоматический конвеер для трёх Telegram‑каналов и изобрёл собственную спецификацию для связывания всего этого добра. Классика.
Для тех кто не в теме: MCP (Model Context Protocol) — это протокол, через который AI‑ассистенты типа Claude подключаются к внешним сервисам и работают с ними напрямую. Грубо говоря — «руки» для нейросетей. Подключил MCP — и ИИ сам ходит в Telegram, ищет лучшие картинки с промптами на Civitai, управляет рекламой в Яндекс.Директе и делает кучу всего полезного. Без костылей, без скриптов‑прослоек, напрямую.
Меня зовут Илья, я блогер, основатель сервиса для генерации изображений ArtGeneration.me и просто фанат нейросетей. Не являюсь программистом в классическом смысле — скорее энтузиаст, предпочитающий генерировать код с помощью нейросетей, а не писать его с нуля. Но за последний месяц я, кажется, немного увлёкся. «Немного» — это 250 инструментов в четырёх серверах, ежедневные автопайплайны и протокол, которого не существовало до того, как я понял что он мне нужен.
А началось всё с того, что мне нужно было регулярно тянуть контент с Civitai для трёх телеграм‑каналов. Руками это стабильные полтора часа в день. Рутина. Я подумал — ну щас подключу готовый MCP‑сервер и всё заработает. Ага, щас.
В этой статье расскажу почему готовые MCP‑серверы меня не устроили, какие задачи я сейчас решаю с помощью своих, и зачем мне пришлось изобрести целый протокол чтобы эти серверы начали видеть друг друга.
Тот MCP‑сервер для Civitai, что лежит на GitHub, был написан 7 месяцев назад. Открываю — и понимаю что он покрывает от силы треть API, поиск моделей работает через стандартный эндпоинт (который, кстати, сломан на Civitai с мая 2025, ага), а половина нужных мне параметров фильтраци просто захардкожена. Час пытался допилить — плюнул.
С Telegram была похожая история. Существующие MCP‑серверы покрывали десяток‑другой методов из 169 доступных в Bot API. Хочешь отправить сообщение — пожалуйста. Хочешь управлять форумами, сторис, подарками, бизнес‑аккаунтами? Удачи, допишите сами.
И вот тут я понял штуку, которая звучит контринтуитивно: в 2026-м проще написать MCP‑сервер с нуля, чем обновить версию API в том, что полгода не обновлялось. Серьёзно. Ты берёшь актуальную спеку с официального сайта, 2–3 чужих репозитория как референс, лучшие практики из MCP SDK — и даёшь всё это своему кодинг‑агенту. За день получаешь сервер, который покрывает 100% API и сделан по твоим правилам. А чужой полугодовалый — там свои архитектурные решения, свои баги, устаревший API, и ты тратишь столько же времени просто чтобы понять что он вообще делает или на обновление версий.
Это не значит что мы делаем велосипед с нуля — мы делаем велосипед по ГОСТ‑чертежам и из правильных запчастей. И это часто быстрее чем чинить чужой и ржавый.
Короче, за месяц я собрал четыре MCP‑сервера. Два опенсорсных, два приватных. Но расскажу про все.
civitai‑mcp‑ultimate (Python + FastMCP, 14 инструментов) — самый полный MCP‑сервер для Civitai API из всех что есть. И я не побоюсь этого слова — я проверял. 100% покрытие публичного API, все 7 эндпоинтов, все параметры. Поиск моделей работает через Meilisearch (потому что родной поиск Civitai сломан с мая 2025), просмотр топовых картинок с промптами, скачивание LoRA и чекпоинтов, анализ трендов. NSFW‑фильтрация, кэш превьюшек, двуязычный вывод EN/RU. Ставится одной командой через pip install civitai-mcp-ultimate.
telegram‑api‑mcp (TypeScript, 169 инструментов) — тут я разошёлся. 169 из 169 методов Bot API 9.6 — полное покрытие. Сообщения, медиа, опросы, форумы, стикеры, платежи, бизнес‑аккаунты, истории, подарки, игры, инлайн, управляемые боты — всё. Есть мета‑режим (подсмотрел идею в одном из существующих серверов) — вместо 169 тулов выставляет всего 2: поиск метода и вызов с JSON‑параметрами. Экономит кучу токенов контекста, что немаловажно. Под капотом — rate limiting, circuit breaker, Zod‑валидация, всего 2 зависимости.
Генерация креативов (приватный, Python + FastMCP, 11 инструментов) — MCP‑сервер для генерации картинок и видео. Текст‑в-картинку, картинка‑в-видео, апскейл, удаление фона, подписи к изображениям. Использую и для генерации креативов к рекламе в Яндекс.Директе, и просто для иллюстраций — вот картинки к этой статье, например, тоже через него сгенерированы. Удобно делать это прямо из Claude не переключаясь никуда, к тому же он сам видит результат и может решить — ок получилось или надо перегенерить. Этот я вам не дам, мои коровки.
Автоматизация одной соцсети (приватный, Python + Playwright, 56 инструментов) — самый необычный из всех. Не все площадки дают нормальный API для публикации — некоторые в принципе предоставляют только веб‑интерфейс. И тут MCP заканчивается, начинается Playwright — движок для браузерной автоматизации. Нейросеть открывает мой браузер с живой сессией и работает с интерфейсом как обычный пользователь. Кликает кнопки, заполняет формы, загружает файлы. Какая конкретно соцсеть — не скажу, а то прочитают и забанят. Но работает отлично.
Итого: 250 инструментов в четырёх серверах. Плюс ещё MCP для Яндекс.Директа, но его я не писал — подключил готовый и он меня вполне устроил. Хотя я был шокирован процедурой получения доступа к API Директа — мало того что надо создать своё приложение, так ещё и подать заявку на подключение, в которой подробно описать что ты делаешь и зачем тебе это. И заявки рассматривают только по будням в рабочее время. В 2026 году. Ну ок.
Ладно, хватит про серверы — давайте про то зачем это всё. У меня сеть телеграм‑каналов про нейросети и каждый день им нужен свежий контент. Раньше я, а потом мой СММщик, тратили на это полтора часа в день: зашёл на Civitai, полистал, нашёл что‑то интересное, скачал, оформил пост, опубликовал, потом то же самое для следующего канала. Конечно, что‑то можно было частями автоматизировать, но на то чтобы эти автоматизации запускать и поддерживать тоже уходило время.
Сейчас у меня крутятся три автоматических пайплайна. Каждый день:
12:06 — Claude Code просыпается по расписанию, идёт в Civitai MCP, находит самую популярную по реакциям на портале картинку за день, забирает промпт и метаданные генерации, оформляет пост и публикует в канал с промптами через Telegram MCP. Потом кросспостит в другие сети.
14:00 — для канала с нейро‑моделями. Находит популярную модель (LoRA или чекпоинт), собирает информацию о ней и 6 примеров картинок, переводит описание на русский и формиурет пост.
14:07 — для канала с AI‑видео. Ищет самое популярное по реакциям видео за день, скачивает несколько кандидатов, получает скриншоты из каждого, сравнивает что интереснее — и лучшее публикует в канал.
Три канала, ежедневный контент, ноль ручной работы. Причём Claude по‑настоящему смотрит на контент. Оценивает качество, проверяет что промпт интересный, при необходимости подредактирует подпись. Если картинка так себе — пропустит и возьмёт следующую.
Отдельная история — Яндекс.Директ. Связка из MCP для генерации креативов + MCP для Директа — это вообще другой уровень. Просто пишу вопрос по метрике — получаю ответ. Пишу что надо поменять ставки в объявлениях — получаю замену. Но вайбкодинг маркетинга — это совсем другая история, и её мы коснёмся как‑нибудь в следующий раз.
Всё работает, контент летит, каналы живут. Красота. А потом ты открываешь один из каналов и видишь что одна и та же картинка опубликована дважды. Потому что вчерашний прогон упал на середине, сегодня перезапустился — и выбрал ту же самую заново. Приятно.
Или вот: утренний прогон нашёл крутую картинку и запостил в канал с промптами. Дневной проснулся, пошёл на Civitai — и нашёл её же, потому что она всё ещё в топе. И запостил в канал с моделями. Потому что откуда ему знать что утром её уже использовали? Это другой запуск Claude, другой промпт, другой контекст.
А теперь давайте разберёмся почему так происходит. MCP‑протокол специально сделан так, чтобы серверы были изолированы друг от друга. Каждый в своём процессе, каждый со своим состоянием. Civitai MCP знает что контент скачали. Telegram MCP знает что что‑то опубликовали. Соцсетный MCP вообще ничего не знает — он живёт в браузере. Между ними — пустота. Никакой общей базы данных, никакой шины сообщений, никакого общего состояния. Так задумано — изоляция серверов делает их надёжными и независимыми.
Но ты стоишь перед простым вопросом: «Это уже постили?» — а ответить нечем.
Можно конечно нагородить свою базу данных, запилить отдельный сервис, который будет принимать вебхуки от каждого сервера и хранить состояние… Но это же тот самый микросервис из задания внизу страницы букваря. Лишняя инфраструктура, лишняя точка отказа, и теперь тебе надо эту базу ещё и поддерживать.
Я перебрал все варианты которые смог найти — и убедился что ничего подходящего нет.
В жизни каждого 40-летнего мальчика наступает такой момент, когда хочется написать свой язык программирования, библиотеку, спецификацию. У меня этот момент наступил.
Но я начал не бездумно. Прежде чем изобретать своё — я провёл нормальное исследование. Потратил вечер чтобы перерыть всё что существует и убедиться что я не пропустил готовое решение.
Вот что я рассмотрел и почему отказался:
OpenTelemetry — первый кандидат, самый очевидный. Индустриальный стандрат трассировки. Проблема в том, что OTel трейсит вызовы — spans, traces, метрики. Он отвечает на вопрос «почему запрос шёл 3 секунды», а не «постили ли мы уже эту картинку». К тому же нужна инфраструктура: коллектор, экспортёр, бэкенд. Для моих трёх пайплайнов это как стрелять из пушки по воробьям.
Google A2A (Agent‑to‑Agent) — протокол коммуникации между агентами. Свежий, модный. Но он про то как агенты общаются друг с другом, а не про логирование того что каждый сервер делал. Другой уровень абстракции.
IETF AAT (Agent Audit Trail) — draft‑спецификация с фокусом на комплаенс. Хэш‑цепочки, ECDSA‑подписи, всё для SOC2 и HIPAA. Я тоже хочу быть enterprise, но мне надо просто узнать постили ли мы уже эту лору или нет.
Langfuse / LangSmith / Arize Phoenix — платформы LLM‑обсервабилити. Трейсят API‑вызовы к нейросетям, стоимость токенов, латенсию. Но не жизненный цикл контента. Плюс требуют облако или self‑host.
На этом моменте я уже начал подозревать что придётся писать своё. Но на всякий случай проверил ещё пару вариантов.
CA‑MCP (arXiv 2601.11595) — shared context для транзиентного стейта между MCP‑серверами. Интересная идея, но это про оперативный контекст, а не про персистентное логирование.
lokryn/mcp‑log — аудит‑лог операций MCP‑сервера. Ближе к теме, но заточен под SOC2/HIPAA аудит, не под трекинг контента.
Agent Protocol — определяет REST API для агентов. Не формат логов.
Итого: на апрель 2026 протокола кросс‑MCP трекинга контента не существует. Ни один из рассмотренных вариантов не совмещает три вещи которые мне нужны: семантику контента (что именно опубликовали), zero shared state (без общей базы) и легковесность (один файл, ноль зависимостей).
Ну раз нет — значит будет. Я изучил лучшие практики из каждого рассмотренного решения, подумал над архитектурой, и написал TRAIL — Tracking Records Across Isolated Logs.
Идея простая до безобразия. Каждый MCP‑сервер ведёт свой лог — обычный JSONL‑файл trail.jsonl. Одна строчка на каждое значимое действие. Никакой общей базы — каждый пишет в свой файл. А нейросеть‑оркестратор читает все логи и связывает записи через универсальный Content ID.
Вот как это выглядит. Civitai MCP выбрал картинку:
{"version":2,"timestamp":"2026-04-05T14:07:00Z","content_id":"civitai:image:12345","action":"selected","requester":"daily-post","trace_id":"run-001"}
Telegram MCP опубликовал ту же картинку:
{"version":2,"timestamp":"2026-04-05T14:07:05Z","content_id":"civitai:image:12345","action":"posted","requester":"daily-post","trace_id":"run-001","details":{"platform":"telegram","platform_id":"42"}}
Один и тот же content_id — civitai:image:12345. Оркестратор видит записи мгновенно и внутри одного контекста автоматически связывает их в единый трейс — эта картинка выбрана и опубликована в Telegram. Повторно постить не нужно. А если бы вторая запись была "action":"failed" — оркестратор понял бы что публикация упала и надо повторить.
trace_id связывает все записи одного прогона пайплайна. Упал пайплайн в 3 ночи? Смотришь записи по trace_id — и видишь на каком шаге сломалось и где продолжить.
TRAIL определяет 15 стандартных действий: fetched, selected, posted, failed, skipped, retrying, transformed, moderated и так далее.
И три уровня совместимости:
Basic — 5 обязательных полей + 2 инструмента (get_trail, mark_trail). Хватит чтобы решить проблему дедупликации.
Standard — добавляет trace_id, автологирование, статистику. Для продакшн‑пайплайнов.
Full — цепочки причинности через caused_by, все 15 действий, экспорт в OpenTelemetry. Для мульти‑агентных систем.
Фишка в том, что нейросеть сама понимает контекст. Поля названы по‑человечески: content_id, action, requester, timestamp. AI сам видит что уже скачано, что опубликовано, а где произошёл сбой. Без единой строчки интеграционного кода между серверами. Ноль общего состояния, ноль зависимостей.
И раз уж всё это сделано агентами и для агентов — для интеграции TRAIL в свой MCP‑сервер вам зачастую достаточно просто показать вашему кодинг‑агенту ссылку на спеку и сказать «сделай». Серьёзно, попробуйте.
За месяц я прогнал каждый из своих серверов через 5–7 раундов code review. Не потому что я перфекционист — просто после каждого ревью вылезало что‑то новое. И постепенно у меня сложился набор правил, которые я теперь считаю обязательными. Все эти правила — как на уроках труда — написаны кровью и на собственных ошибках. До появления TRAIL я пару раз успел запостить свои тестовые посты туда, откуда их нельзя было удалить)))
Rate limiting и circuit breaker — не опционально. Telegram банит ботов которые шлют больше 30 запросов в секунду. Civitai отвечает 429-ми если частишь. Без встроенного rate limiter ваш MCP‑сервер ляжет на первом же реальном пайплайне. Circuit breaker тоже нужен — если API лёг, нет смысла долбить его запросами, лучше подождать и попробовать позже.
Валидация до отправки в API. Проще сделать правильную валидацию сразу, чем дебажить матерясь потом. Большинство существующих серверов этого не делают — отправляют сырые параметры в API и возвращают непонятный 400-й ответ. В telegram‑api‑mcp каждый из 169 методов проходит через Zod‑валидацию — если ты передал строку вместо числа, ты узнаешь об этом с понятным сообщением, а не с «Bad Request» от Telegram.
Минимум зависимостей. Это я усвоил ещё на Civitai‑сервере, когда одна из транзитивных зависимостей сломала билд после обновления. telegram‑api‑mcp — 169 методов, продакшн‑фичи, а зависимостей всего 2: SDK и Zod. Чем меньше зависимостей, тем меньше шансов что что‑то сломается при обновлении. И тем проще разобраться в проекте.
Tool annotations. Каждый инструмент помечен: readOnly, destructive, idempotent, openWorld. AI‑клиент видит эти аннотации и понимает какие тулы безопасно вызывать автоматически, а какие лучше подтвердить у человека. deleteMessage — destructive, getChat — readOnly. Мелочь, а автономные пайплайны работают надёжнее.
Маскирование токенов. Бот‑токен не должен появляться в ответах, логах и сообщениях об ошибках. Никогда. Казалось бы очевидно, но я видел репозитории с кучей звёздочек и форков, которые возвращают полный URL запроса вместе с токеном в тексте ошибки. Прямо в контекст LLM. Понятно что у них такая архитектура и свои причины, но блин — можно же было сделать утилиту и возвращать файл, а не светить токеном в ответе нейросети.
Вот что принципиально изменилось в подходе к автоматизации. Раньше оркестрация выглядела так: написал скрипт, прописал if‑else, запустил по крону. Скрипт тупой — делает ровно то, что написано. Если что‑то пошло не так — падает. Если API поменялся — падает. Если картинка плохая — пофиг, постит.
Сейчас оркестратор — это Claude Code, запущенный по расписанию. Он понимает что делает. Если Civitai API вернул ошибку — подождёт и попробует снова. Если картинка не подходит по качеству — пропустит и возьмёт следующую. Если Telegram вернул rate limit — замедлится. Если что‑то сломалось фундаментально — напишет в TRAIL‑лог "action":"failed" и остановится, вместо того чтобы запостить мусор.
И это не какой‑то сложный код с обработкой исключений на каждый случай. Это один промпт: «найди лучшую картинку за день, проверь что мы её ещё не постили, оформи пост, опубликуй». Всё остальное нейросеть решает сама — потому что она понимает контекст.
Но знаете что ещё круче? Это всё прекрасно работает и до того, как оно превращается в MCP. Потому что до MCP у вас просто есть токен и LLM, которая пишет на лету под него обёртку. Скормили токен от Vercel, Supabase и GitHub в одного агента — и он сам управляет этим как угодно. И скорее всего знает лучше вас, что можно сделать и что нельзя. Вам не надо помнить команды. Не надо помнить спеки. Можно задать вопрос про спеки — узнать отевт. Можно попросить загуглить лучшие практики и после этого настроить сервер. Это совсем другой подход к решению задач и к управлению процессами.
MCP — это уже следующий шаг, когда ты эти обёртки стандартизируешь и делаешь переиспользуемыми. Вместо того чтобы каждый раз объяснять агенту как ходить в Telegram API, ты один раз пишешь MCP‑сервер — и дальше он работает из любого проекта, любого агента, любого контекста.
Дженсен Хуанг сказал недавно, что агентные системы управления — это буквально новый компьютер. Полностью согласен. Это многоуровневые системы, которые корректируют сами себя за счёт умного оркестратора, справляются с ошибками и даже могут дорабатыать себя если внести это в цикл. Хотя хорошо это или плохо — пока не понятно, тут только время покажет.
С этим контент‑заводом из MCP‑серверов я наконец‑то смогу уволить СММщика освободить СММщика для более творческих задач, автоматизировав рутину.
Все публичные проекты — опенсорс, MIT лицензия:
civitai‑mcp‑ultimate — MCP для Civitai. 14 инструментов, 100% API, Python. pip install civitai-mcp-ultimate
telegram‑api‑mcp — MCP для Telegram. 169/169 методов Bot API 9.6, TypeScript
trail‑spec — спецификация TRAIL для связывания MCP‑серверов между собой
Если делаете свой MCP‑сервер и у вас в системе несколько таких серверов — попробуйте TRAIL. Для интеграции достаточно дать кодинг‑агенту ссылку на спеку. А если хотите добавить что‑то своё и улучшить проекты — welcome контрибьютить. Звёздочки на GitHub тоже привествуются, мелочь а приятно.
Пишите в комментариях какие MCP используете вы и каких не хватает — может, мне тоже такой надо. Вообщем в классное время живём, товарищи.
