Привет! Вы знаете как это бывает — начинаешь делать одну штуку, а потом просыпаешься через неделю и понимаешь, что написал четыре 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‑сервер вам зачастую достаточно просто показать вашему кодинг‑агенту ссылку на спеку и сказать «сделай». Серьёзно, попробуйте.

❯ Что я понял про 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 используете вы и каких не хватает — может, мне тоже такой надо. Вообщем в классное время живём, товарищи.

Я рассказываю больше о нейросетях и автоматизации у себя в YouTube, в Телеграме и на Бусти. Всех обнял и удачных автоматизаций.