TOBIZ MCP

tobiz-mcp

MCP-сервер для конструктора сайтов TOBIZ: даёт агенту (Hermes, Codex, OpenCode и любому MCP-клиенту) читать и менять сайты — проекты, страницы, блоки, изображения.

Репозиторий: https://github.com/Tobiz21/tobiz-mcp

Docker-образ: ghcr.io/tobiz21/tobiz-mcp:0.9.0-beta.3

Короткая инструкция для ИИ

Установи TOBIZ MCP с https://github.com/Tobiz21/tobiz-mcp. Запусти безопасный мастер настройки и попроси меня ввести данные TOBIZ в скрытом запросе, не в чате. Затем уточни, с каким сайтом и что нужно сделать, и используй только штатные функции TOBIZ.

Выбор дизайна

• tobiz_design_library возвращает паспорта девяти установленных штатных шаблонов и семнадцати визуальных референсов: исходные страницы, сильные стороны, плотность, зависимость от фото и долю Flex.
• tobiz_validate_design_library перечитывает источники шаблонов и обнаруживает исчезнувшие страницы, изменение числа блоков и доли Flex до начала сборки нового сайта.
• Планирование и сборка повторяют эту проверку автоматически и прекращают работу с кодом design_passport_drift, если эталон изменился после последней проверки.
• tobiz_refresh_design_passport сначала показывает новые факты, затем при apply=true сохраняет локальный override. Исходный проект не меняется, а следующий выбор и сборка используют обновленный паспорт без изменения кода MCP.
• tobiz_register_design_template позволяет каждому аккаунту зарегистрировать собственную проверенную страницу как основу. MCP хранит только паспорт и идентификаторы, а не содержимое сайта; локальные шаблоны участвуют в том же подборе, проверке свежести и anti-regression процессе. Регистрация требует безопасного пересохранения, композиции не ниже 7/10, отсутствия критических desktop/tablet/mobile ошибок и явного визуального просмотра созданных снимков.
• Подбор проверяет доступность и свежесть источников в текущем аккаунте. Недоступные эталоны попадают в unavailable_sources, а план и сборка автоматически используют следующий подходящий проверенный шаблон вместо аварийной остановки на чужом проекте.
• Первый preflight библиотеки выполняется параллельно с лимитом три запроса, сохраняя порядок рейтинга и не создавая неконтролируемую нагрузку на TOBIZ; последующие чтения используют кеш.
• tobiz_discover_design_candidates просматривает страницы проекта и предлагает пригодные основы по числу штатных блоков, доле Flex, композиции и editor-safe статусу. Это быстрый структурный фильтр; регистрация с визуальными снимками остается обязательной.
• tobiz_record_design_feedback и tobiz_list_design_feedback сохраняют локальные оценки, замечания и исправления. Это не обучение модели и не копирование страницы, а проверяемая база решений для следующих сборок.
• tobiz_design_lessons агрегирует повторяющиеся замечания и проверенные исправления. Оценки шаблонов с ограниченным весом автоматически учитываются в выборе основы и плане нового сайта.
• Структурированные issue_codes превращаются в anti-regression профиль плана: повтор известных проблем с карточками, кнопками, контрастом, мобильной версткой, формами или доверием блокирует финальную приемку конкретной сборки.
• tobiz_select_design ранжирует установленные шаблоны по брифу до копирования страницы и объясняет выбор, риски и подходящие визуальные референсы.
• tobiz_editor_roundtrip_check без сохранения собирает штатный payload редактора и заранее выявляет блоки, из-за которых ручное пересохранение может изменить или сломать страницу.
• tobiz_build_quality_page выбирает проверенный шаблон по брифу, соблюдает лимит Flex 30%, выдает компактный рецепт и медиаплан, сохраняет копию один раз и завершает desktop/mobile и editor-safe проверками. Полный технический паспорт возвращается только при details=true.

Модель зрелости 9/10

MCP считается готовым к эффективной работе, когда девять обязательных компетенций имеют штатный конвейер и автопроверки. Десятая остается зоной развития, а не поводом выдавать эксперимент за готовую функцию.

Для надежного повторения удачной секции используй tobiz_copy_native_block: сначала preview, затем apply=true с expected_target_hash, после чего один tobiz_save_page. Инструмент переносит штатные значения без реконструкции и отдельно проверяет Flex перед копированием.

Финальная команда tobiz_release_design_gate работает строже обычного аудита: для ready нужны эталонная страница, бриф для проверки фактов, editor roundtrip и явное подтверждение визуального просмотра desktop/tablet/mobile-снимков. Отсутствующая проверка теперь является блокером, а не нулем, который незаметно исключается из среднего балла.

Для реального контрактного контроля настрой GitHub secrets TOBIZ_LIVE_TEST_EMAIL, TOBIZ_LIVE_TEST_PASSWORD и variables TOBIZ_LIVE_TEST_PROJECT_ID, TOBIZ_LIVE_TEST_PAGE_ID. Workflow TOBIZ live contract еженедельно проверяет вход, каталог, vendor-render, editor roundtrip и публичную страницу в трех viewport без записи на сайт.

Быстрый старт

Поддерживаемый способ установки публичной бета-версии - Docker. Python wheel сам по себе не содержит Node-рендерер TOBIZ и не является полноценной установкой сервера.

git clone https://github.com/Tobiz21/tobiz-mcp.git && cd tobiz-mcp
docker build -t tobiz-mcp .
docker run --rm -it --entrypoint tobiz-mcp-configure \
  -v "$PWD:/config" tobiz-mcp --projects 123456,123457 --output /config/.env

Для существующей установки обновите только безопасный список проектов, не перезаписывая секреты, токен и остальные параметры:

tobiz-mcp-configure --projects 123456,123457 --output .env --update-allowlist-only

Перед изменением мастер автоматически сохранит рядом резервную копию прежнего .env. Проекты, созданные самим tobiz_create_project, автоматически добавляются в отдельный локальный управляемый список и остаются доступными после перезапуска. Произвольные проекты аккаунта это правило не открывает.

После публикации образа локальную сборку можно заменить на:

docker pull ghcr.io/tobiz21/tobiz-mcp:0.9.0-beta.3
docker tag ghcr.io/tobiz21/tobiz-mcp:0.9.0-beta.3 tobiz-mcp

Мастер скрыто запросит пароль, включит строгую изоляцию и разрешит MCP работать только с перечисленными проектами. Если .env уже существует, рядом останется резервная копия. Для автоматической установки передайте логин и пароль через окружение и добавьте --non-interactive; пароль не передавайте аргументом командной строки.

Проверка, что сервер видит конструктор (логин/сессия и рендерер):

docker run --rm --entrypoint tobiz-mcp-selftest --env-file .env \
  -v tobiz-session:/data/session -v tobiz-assets:/data/assets \
  tobiz-mcp --health

Ожидаемый ответ — JSON, где session.present: true и renderer_available: true. Если логин по паролю аккаунт не пропускает (встречается капча), положите свою сессию в том — см. «Полезно знать» ниже.

Дальше достаточно подключить сервер к своему агенту — он запускает образ сам, как stdio-сервер.

Подключение к агенту

Подставьте свой абсолютный путь к .env. Образ запускается с -i (stdio) — больше ничего не нужно.

Hermes

hermes mcp add tobiz --command docker --args run -i --rm \
  --env-file /путь/до/tobiz-mcp2/.env \
  -v tobiz-session:/data/session -v tobiz-assets:/data/assets \
  tobiz-mcp
hermes mcp test tobiz

Codex (~/.codex/config.toml)

[mcp_servers.tobiz]
command = "docker"
args = ["run", "-i", "--rm", "--env-file", "/путь/до/tobiz-mcp2/.env",
        "-v", "tobiz-session:/data/session", "-v", "tobiz-assets:/data/assets", "tobiz-mcp"]
startup_timeout_sec = 30
tool_timeout_sec = 180

OpenCode (opencode.json)

{"mcp": {"servers": {"tobiz": {"type": "local",
  "command": ["docker", "run", "-i", "--rm", "--env-file", "/путь/до/tobiz-mcp2/.env",
              "-v", "tobiz-session:/data/session", "-v", "tobiz-assets:/data/assets", "tobiz-mcp"]}}}}

Инструменты появятся с префиксом сервера — например mcp__tobiz__tobiz_list_projects.

Загрузка картинок работает через файлы: положите изображение в локальный каталог и смонтируйте его как /data/inbox, тогда путь к файлу передаётся в tobiz_upload_image (либо сразу content_base64, без монтирования).

Два режима работы

MCP — это JSON-RPC, а не REST, и клиент подключается к серверу одним из двух способов:

Контейнер запускается не на каждую команду: он один на сессию, а вызовы инструментов идут в него потоком JSON-RPC (в stdio — через stdin/stdout). Черновик правок и кеш библиотеки блоков живут в процессе, cookie-сессия — на томе, поэтому переживает перезапуск контейнера.

Постоянный HTTP-сервис:

docker run -d --name tobiz-mcp --restart unless-stopped -p 8765:8765 \
  -e MCP_TRANSPORT=http -e MCP_HTTP_TOKEN=секрет --env-file .env \
  -v tobiz-session:/data/session -v tobiz-assets:/data/assets tobiz-mcp
# endpoint: http://<хост>:8765/mcp, заголовок Authorization: Bearer секрет

Цена общего сервиса: черновик один на процесс — несколько агентов на одной странице будут мешать друг другу. Для параллельной работы удобнее stdio: у каждого агента свой контейнер и свой черновик.

Инструкции для агента (скил)

Инструменты — половина дела: агенту нужно знать порядок работы, грабли вендора и как проверять результат. Это лежит в скиле skills/tobiz-mcp/SKILL.md.

Hermes — скил лежит в репозитории, вместе со справочниками (каталог блоков, движок, компоненты, эндпоинты). Копируй папку целиком:

git clone https://github.com/Tobiz21/tobiz-mcp.git /tmp/tobiz-mcp
cp -r /tmp/tobiz-mcp/skills/tobiz-mcp ~/.hermes/skills/

Установка по прямой ссылке (hermes skills install <raw-URL на SKILL.md>) тоже работает, но приносит только SKILL.md — без справочников и рецептов.

Codex / OpenCode читают AGENTS.md из корня репозитория автоматически; если работаете не из репозитория — скопируйте файл в свой конфиг (~/.codex/AGENTS.md и аналоги).

В скиле: что пишется сразу, а что только по tobiz_save_page; 15 проверенных грабель (радиус кнопок в em и вендорский CSS 2px, автоконтраст текста в формах, обязательный block_id при загрузке картинок, отстающий window.tobiz, ?v= = id страницы) и короткие рецепты под типовые задачи.

Инструменты

Релизный гейт читает статьи и товары постранично до конца, а не ограничивается первыми 100. Повторяющаяся или оборванная выдача помечает инвентаризацию как неполную и блокирует приемку. Он также проверяет уникальность URL и SEO title всех статей и товаров, артикулов товаров и артикулов вариантов во всем каталоге, а не только внутри одной карточки. | tobiz_audit_project | целостность многостраничного сайта: URL и SEO, композиция страниц, единые типы шапки/подвала, конверсионный выход | | tobiz_plan_multipage_site | единый read-only план многостраничного сайта: главная, уникальные маршруты, общее меню, назначение и quality-план каждой страницы | | tobiz_prepare_multipage_package, tobiz_multipage_package_status | единый заполняемый конверт всех страниц и агрегированный прогресс без преждевременной записи в TOBIZ | | tobiz_build_multipage_package | общий preflight, preview и транзакционная штатная сборка всех страниц с откатом созданных страниц при сбое | | tobiz_page_summary | компактная карта страницы: порядок блоков, короткий текст, SEO-подсказка | | tobiz_list_blocks, tobiz_get_block | блоки страницы и значения полей блока | | tobiz_page_info | параметры страницы как в панели: название, URL, SEO, og:image, доступ | | tobiz_search_blocks, tobiz_describe_block | поиск по библиотеке блоков, схема полей типа | | tobiz_block_controls | реестр галочек и списков каждого типа: подписи, поля, дефолты, зависимости и варианты | | tobiz_audit_catalog | аудит всех типов, галочек, списков, серверных значений и flex-вариантов | | tobiz_get_site_styles, tobiz_update_site_styles | штатные глобальные шрифты, размеры, насыщенность и цвета кнопок через page_config | | tobiz_get_computed_styles, tobiz_screenshot_page | реальные стили и полностраничные desktop/mobile PNG-снимки | | tobiz_diagnose_interactions, tobiz_audit_page, tobiz_audit_summary | формы, попапы, кнопки, ссылки, контраст, геометрия, остатки исходной тематики, JS-ошибки, изображения и объяснимая оценка качества из 10 | | tobiz_add_block, tobiz_update_block, tobiz_delete_block, tobiz_move_block | правки черновика | | tobiz_inspect_flex_block, tobiz_update_flex_block | безопасное чтение и изменение штатной модели Flex 1600 с проверкой desktop/mobile-геометрии, наложений и CTA; cache формируется рендерером TOBIZ при сохранении | | tobiz_audit_flex_page | инвентаризация всех Flex на странице и сбор фактических ключей vendor-схемы для проверенного корпуса | | tobiz_copy_native_block | точное повторное использование проверенного штатного блока между страницами и проектами с preview и защитой от конфликтов | | tobiz_save_page | запись блоков на сайт: рендер HTML, SaveBlocks, проверка вёрстки | | tobiz_update_page | правка параметров страницы (SEO, название, slug, og:image) — пишет сразу | | tobiz_copy_page | копия страницы вместе с блоками в тот же или другой проект | | tobiz_build_from_template | один конвейер: проверка рецепта, копирование, заполнение, одно сохранение, SEO и desktop/mobile-аудит | | tobiz_improve_page | безопасный цикл: аудит с привязкой к block_id, предпросмотр штатных автоправок, резервная копия, сохранение, повторный аудит и откат при снижении балла | | tobiz_layout_registry | проектный реестр штатных настроек верстки всех типов блоков: поля, подписи, варианты, зависимости и безопасность автоматического применения | | tobiz_repair_layout | точечный ремонт найденных визуальных дефектов штатными настройками блока с проверкой editor-safe, сравнением «до/после» и откатом регрессии | | tobiz_refine_design | комплексный дизайн-профиль desktop/mobile: сетка контейнеров, ритм секций, палитра и радиусы кнопок, типографика и изображения; безопасное улучшение с откатом | | tobiz_audit_composition | смысловая архитектура страницы: роли блоков, полнота раскрытия темы, доверие, порядок секций и конверсионные пропуски для услуг, обучения или магазина | | tobiz_compare_design_reference | сравнение нового сайта с эталонной TOBIZ-страницей: структура, роли секций, штатные стили, desktop/mobile-сетка, кнопки, шрифты и доля Flex | | tobiz_release_design_gate | единая финальная приемка: публичная верстка, композиция, эталон, безопасность редактора и несохраненный черновик с вердиктом ready, review или save_blocked | | tobiz_audit_images | паспорт изображений desktop/tablet/mobile: пропорции, кадрирование, повторы, смысловая роль, фон под текстом и контекст секции | | tobiz_plan_site | детерминированный план до сборки: установленный шаблон, роли секций, лимиты текста, фотобрифы, CTA, дизайн-система и стабильный plan_id | | tobiz_compile_site_content | контентный манифест по реальным слотам шаблона: назначение и лимит каждого поля, недостающие факты и запрет выдуманных цен, отзывов, опыта, гарантий и контактов | | tobiz_validate_site_recipe | проверка текста до копирования страницы: структура и полнота рецепта, мобильные лимиты, баланс карточек, конкретность CTA и соответствие утверждений брифу | | tobiz_validate_media_recipe | проверка изображений до копирования: покрытие фотослотов, разрешение, ориентация фона, безопасная зона под текст, единые пропорции карточек, заглушки и повторы | | tobiz_prepare_site_package | один чистый пакет для заполнения: plan_id, текстовые слоты, точные фотослоты, SEO и недостающие факты без переноса текста исходного шаблона | | tobiz_create_project | безопасно создать отдельный пустой проект для нового сайта; сборка в проект библиотеки шаблонов запрещена | | tobiz_fill_package_content | безопасное пакетное заполнение точных текстовых и SEO-слотов с проверкой неизвестных путей, дублей, мобильных лимитов, фактов и preflight | | tobiz_site_package_status | возобновление сборки: прогресс текстов, фото и SEO, точные незаполненные слоты, сгруппированные блокеры и одна следующая команда | | tobiz_save_site_package, tobiz_list_site_packages, tobiz_load_site_package, tobiz_delete_site_package | автоматические локальные контрольные точки полного пакета, продолжение после переподключения и явная очистка с confirm=true | | tobiz_list_site_package_revisions, tobiz_restore_site_package_revision | до 20 прежних версий каждого пакета и безопасный откат с архивированием текущего состояния; восстановление требует confirm=true | | tobiz_fill_package_media | предпросмотр и пакетная загрузка локальных/base64-изображений в точные фотослоты пакета с автоматическим измерением файлов; блоки шаблона не изменяются | | tobiz_preflight_site_build | единый предсборочный гейт: plan_id, тексты, факты, изображения, SEO, URL страницы и ссылки с одним вердиктом ready_for_build | | tobiz_build_site_package | предпросмотр или сборка напрямую из заполненного пакета с повторной проверкой его версии, брифа, плана и шаблона | | tobiz_audit_claims | проверка страницы против подтвержденных фактов брифа: находит посторонние телефоны, email, цены, скидки, стаж, сроки и числовые результаты с точным block_id и путем поля | | tobiz_check_site_plan | проверка готовой страницы против plan_id, структуры и ролей с аудитом фото, эталона, редактора и единым дизайн-гейтом | | tobiz_delete_page | удаление страницы (требует confirm=true) | | tobiz_discard_changes, tobiz_verify_page | откат черновика, проверка публичной вёрстки | | tobiz_upload_image, tobiz_set_block_image | загрузка изображения и подстановка в поле; ответ содержит измеренные width/height, формат, aspect ratio, SHA-256 и готовый media_asset | | tobiz_refresh_assets | перекачать библиотеку блоков проекта | | tobiz_list_articles, tobiz_get_article, tobiz_create_article, tobiz_update_article, tobiz_update_article_package, tobiz_delete_article, tobiz_preflight_article, tobiz_audit_article, tobiz_publish_article_package | штатный редактор статей, проверка, транзакционное создание и обновление с откатом, аудит готовой публикации | | tobiz_upload_article_image, tobiz_sort_article_images, tobiz_list_article_categories | изображения, их порядок и категории статей | | tobiz_list_products, tobiz_get_product, tobiz_create_product, tobiz_update_product, tobiz_update_product_package, tobiz_delete_product, tobiz_preflight_product, tobiz_audit_product, tobiz_publish_product_package | управление товарами, транзакционное создание и обновление карточки с вариантами, аудит готовой публикации | | tobiz_upload_product_image, tobiz_sort_product_images, tobiz_list_product_categories | галерея, порядок фото и категории товаров | | tobiz_list_product_offers, tobiz_get_product_offer, tobiz_create_product_offer, tobiz_update_product_offer, tobiz_delete_product_offer | варианты товара: название, артикул, цена, остаток и фото |

Ответ инструмента: {"ok": true, "data": {...}} либо {"ok": false, "error": {"code": "...", "message": "...", "hint": "..."}}.

Перед релизом MCP запустите python scripts/control-scenarios.py. Команда проверяет единый контракт четырех основных процессов: готовый лендинг, многостраничный проект, SEO-статья с медиа и товарный каталог с вариантами. Ненулевой код завершения запрещает выпуск версии.

tobiz_audit_summary возвращает quality_score по четырем направлениям (technical, visual, content, usability) и fix_plan. Сначала устраняются пункты must_fix, затем improve. Критическая ошибка ограничивает общий балл значением 4.9; рабочий порог фиксируется полем quality_score.meets_7_of_10.

Каждая геометрическая проблема содержит block_evidence и fix_plan[].block_ids, поэтому агент видит не только тип дефекта, но и конкретный штатный блок. На мобильном отдельно проверяются карточки, которые не сложились в колонку, обрезанный контент и размеры зон нажатия.

Для существующей страницы сначала вызывайте tobiz_improve_page(apply=false). Команда показывает автоматические правки отдельно от human_fix_plan. Повтор с apply=true выполняет не более трех циклов, сохраняет только штатные поля блоков и автоматически восстанавливает резервную копию, если итоговый балл стал ниже исходного. Для карточек команда умеет штатно включать flex_fix, отключать btn_up и btn_move, а также задавать btn_align=center, но только если соответствующее поле реально присутствует в блоке. Если настройки нет, MCP возвращает предупреждение и не подменяет верстку собственным CSS.

Для отдельного ремонта верстки используйте tobiz_repair_layout(apply=false). В ответе будут конкретные block_id, изменения и выдержка из реестра затронутых типов. После проверки повторите с apply=true: команда проверит editor roundtrip, создаст резервную копию, сохранит страницу, повторит desktop/mobile-аудит и откатит сохранение при снижении балла или новой критической ошибке. Полный список доступных настроек проекта возвращает tobiz_layout_registry; мобильные поля с неоднозначной семантикой остаются кандидатами и не переключаются автоматически.

Для финальной полировки страницы используйте tobiz_refine_design(apply=false). Команда возвращает design_system.profiles, системные отклонения и отдельный manual_design_plan. Повтор с apply=true объединяет только детерминированные штатные исправления шаблона и верстки, сохраняет один раз и сравнивает дизайн-систему до/после. Новая ошибка палитры, сетки, радиусов, типографики, изображений или ритма считается регрессией и вызывает восстановление резервной копии.

До визуальной полировки вызовите tobiz_audit_composition. Инструмент сопоставляет каждый block_id с ролью в истории страницы и отдельно оценивает покрытие, порядок и доверие. Для goal=lead_generation проверяются предложение и заявка, для education - программы и экспертность, для ecommerce - каталог, доставка и оплата. Ответ содержит missing_roles, issues, recommended_order и независимый порог meets_7_of_10. Команда ничего не меняет и не генерирует код: рекомендации реализуются перестановкой или заполнением штатных блоков.

Когда сайт строится по установленному шаблону, перед выдачей вызовите tobiz_compare_design_reference. Команда сравнивает эталон и результат по четырем независимым метрикам: structure, roles, native_style, rendered_visual. Она допускает новые тексты и изображения, но показывает замененные типы блоков, измененные штатные поля и расхождения desktop/mobile-профилей. Порог meets_7_of_10 не достигается при существенной потере структуры или смысловой последовательности эталона.

Перед передачей сайта обязательно запускайте tobiz_release_design_gate. Команда объединяет desktop/tablet/mobile-аудит, смысловую полноту, опциональное сравнение с эталоном и безопасное пересохранение в редакторе. Сайт готов к выдаче только при gate.verdict=ready; несохраненный черновик, критичная верстка или сломанная структура дают save_blocked.

Перед финальным дизайн-гейтом вызывайте tobiz_audit_images. Инструмент возвращает геометрию, исходное разрешение, object-fit, ближайший текст и снимки для каждого изображения. Он отмечает растянутые и чрезмерно обрезанные фото, повтор одного кадра в разных секциях, несогласованные пропорции карточек и текст поверх фонового фото без затемнения. Последний дефект блокирует выдачу.

До выбора дизайна вызовите tobiz_validate_brief(brief=...): команда определяет цель сайта и возвращает только отсутствующие обязательные факты с готовыми вопросами клиенту. В режиме quality единый preflight блокирует сборку с brief_evidence_missing, пока не подтверждены предложение, процесс, доказательства и контакты. allow_placeholders=true разрешает только явно черновой прототип; цены, отзывы, опыт, сроки и контакты никогда не заполняются догадками. Значения «уточнить», «примерно», «клиент исправит», example.com и демонстрационные контакты считаются незаполненными даже внутри вложенного объекта facts.

Для обычного запуска используйте tobiz_start_site(brief=...) вместо ручной цепочки проверок. Если данных мало, команда без обращения к TOBIZ вернет только вопросы и next_action=answer_brief_questions. При полном брифе она одним вызовом выберет доступный эталон, проверит архитектуру и форму, создаст возобновляемый чистый пакет и вернет следующий шаг. Страница при этом еще не создается.

Затем вызовите tobiz_validate_site_architecture: MCP проверит, способен ли выбранный штатный шаблон раскрыть тему без новых самописных секций. Для услуг, обучения и магазина используются разные обязательные роли; дополнительно требуются достаточные слои доверия и композиционная оценка не ниже 7/10. При выборе доступных эталонов MCP предпочитает первый архитектурно полный вариант. Если все варианты неполны, качественная сборка блокируется с template_architecture_incomplete.

Перед заполнением контента вызовите tobiz_validate_conversion_path. По умолчанию хотя бы одна штатная форма должна содержать «Имя», затем «Телефон» и кнопку отправки. Нестандартный набор можно задать в brief.form_fields, например ["имя", "телефон", "дата", "количество гостей"]. Подбор предпочитает шаблон, где этот контракт уже выполняется; quality build блокируется с conversion_path_incomplete, если подходящей формы нет. MCP не создает самописную форму. План также сохраняет штатные якоря шаблона. Любая внутренняя ссылка из рецепта должна вести на один из них; несуществующий #anchor блокирует preflight с кодом missing_recipe_anchor. Если в брифе задан primary_cta, хотя бы одна редактируемая штатная кнопка должна выражать это действие. Шаблонное «Подробнее» не заменяет согласованное «Узнать свободное время».

В media_recipe каждый файл должен иметь конкретный subject и подтверждение section_fit_confirmed=true после визуального просмотра. Группа заранее сообщает section_role и shot_role, поэтому фото учителя не должно случайно попадать в отзывы или процесс. Общие подписи «фото», «женщина», «изображение» не проходят проверку, как и повтор одного файла в разных секциях. Повтор одного файла в нескольких карточках или ячейках одной галереи также блокируется. media_asset содержит SHA-256 фактических байтов, поэтому переименованная копия того же кадра тоже распознается и не проходит quality preflight. Для фоновых кадров отдельно остается обязательным safe_text_area=true.

При заполнении каждого текстового слота передавайте evidence_codes из brief_readiness.confirmed_fields. Например, абзац об учителе может ссылаться на ["expert"], а описание программы - на ["program", "format"]. Quality preflight блокирует сборку, если подтвержденный факт не раскрыт ни в одном непустом слоте или указан неизвестный код. Это не разрешение формально прикрепить метку к любому тексту: MCP проверяет, что слот содержит смысловой фрагмент соответствующего факта, включая распространенные русские словоформы. Служебные метки остаются только в пакете сборки. Проверяется и смысловая позиция факта: программа должна раскрываться в первом экране или программах, экспертность - в первом экране, эксперте или доказательствах, доставка - в соответствующей секции. Факт в неподходящем блоке дает evidence_mapped_to_wrong_section. Вердикт tobiz_validate_site_recipe.ready_for_build уже учитывает эту проверку: для quality-режима непокрытый факт блокирует продолжение сразу, а для явно выбранного прототипа остается предупреждением. Он также отклоняет одинаковые содержательные заголовки и абзацы, скопированные между разными секциями. Повтор штатных CTA-кнопок и коротких служебных подписей этой проверкой не запрещается. Для карточных блоков quality-режим блокирует сильный разброс длины соседних заголовков и описаний, чтобы тексты были сбалансированы до применения штатной настройки выравнивания карточек и кнопок. Превышение мобильного лимита у кнопки, заголовка секции или карточки также блокирует quality-сборку; небольшое превышение у обычного абзаца остается рекомендацией для визуальной проверки. Вложенные элементы штатной формы профилируются по соседнему полю type: подписи и placeholder получают роль form_label, а btn/button/submit - роль button. Поэтому кнопка формы участвует в проверке основного CTA и мобильной длины, а подпись поля не считается заголовком секции. Conversion preflight проверяет каждую найденную штатную форму, даже если другая форма уже исправна: кнопка отправки должна иметь видимую подпись, а одинаковые смысловые поля не должны дублироваться. Ошибки возвращаются как form_submit_missing и duplicate_form_fields до копирования страницы. Если в брифе согласован primary_cta, recipe обязан явно заполнить хотя бы один штатный слот кнопки; отсутствие кнопки дает primary_cta_missing_from_recipe, а не проходит проверку молча. Одинаковые подписи и placeholder полей в повторных формах при этом не считаются дублированным текстом секций. Если форма собирает телефон или email, хотя бы один из согласованных каналов связи должен быть обязательным штатным полем. Иначе conversion preflight возвращает contact_field_not_required: форма, которую можно отправить без контакта, не считается рабочим путем заявки. Каждое видимое поле также должно иметь понятную подпись: видимый title либо placeholder, если заголовок скрыт. Безымянное поле блокируется как form_field_unlabeled до копирования шаблона. Обязательные поля сверяются с brief.form_fields: дополнительное необязательное сообщение допустимо, но случайный обязательный email, адрес или другой вопрос блокируется как unexpected_required_form_fields, чтобы форма не наследовала лишнее трение исходного шаблона. Поиск formN рекурсивный: те же проверки применяются к штатным формам внутри Flex и других вложенных моделей. Диагностика возвращает точный form_path, например /flexblocks/0/content/form1, поэтому исправление не требует угадывать элемент. Тот же рекурсивный обход используется в tobiz_editor_roundtrip_check: вложенная форма без btn/button/submit возвращает save_blocked и editor_safe=false. Это структурная поломка, а не рекомендация для ручного просмотра; неблокирующие дизайнерские замечания остаются warnings. Служебные значения вроде «Заголовок», «Описание», Lorem ipsum, TODO и «Заполнить позже» не считаются готовой заменой текста и дают placeholder_recipe_copy.

Для быстрого старта нового сайта вызовите tobiz_prepare_site_package(brief=...): команда выбирает реальный установленный шаблон и возвращает чистые формы recipe, media_recipe и seo, не перенося тексты исходной тематики. Для подробного анализа отдельно доступен tobiz_plan_site. План выбирает реальный установленный шаблон, фиксирует его штатную структуру, назначение секций, ограничения текстовых слотов и требования к фотографиям. До написания текста проверьте вложенный content_brief или вызовите tobiz_compile_site_content: если ready_for_copywriting=false, сначала запросите перечисленные missing_evidence, а неизвестные цены, отзывы, опыт и гарантии не придумывайте. Передайте полученный recipe в tobiz_validate_site_recipe и исправьте blockers. Заполните media_recipe по photo_requirements, проверьте его через tobiz_validate_media_recipe и только после этого копируйте страницу. Одна общая заглушка допустима лишь для явно обозначенного прототипа с allow_placeholders=true; качественная сборка требует отдельных проверенных кадров. Чтобы не загружать изображения по одному, передайте пакет и список точных слотов в tobiz_fill_package_media(apply=false), проверьте сопоставление block_index с block_id, затем повторите с apply=true и используйте возвращенный package. Команда измерит файлы, заполнит media_recipe и не изменит ни одного значения блока шаблона. После подготовки, текстов и примененной загрузки медиа checkpoint сохраняется автоматически; save_checkpoint=false отключает это для временного прогона. Новая сессия находит его через tobiz_list_site_packages и получает полный проверенный пакет командой tobiz_load_site_package; учетные данные в checkpoint не записываются. При каждом реальном изменении MCP сохраняет прежнее состояние в истории из 20 версий. Для просмотра используйте tobiz_list_site_package_revisions, а для отката - tobiz_restore_site_package_revision(confirm=true). Перед откатом текущая версия тоже архивируется. Поле content_hash защищает совместную работу: подготовка, загрузка, заполнение текста и медиа передают его автоматически. Если другой клиент уже сохранил более свежий пакет, устаревшая запись останавливается с CONFLICT; загрузите checkpoint заново и перенесите только нужную правку. Чтобы не запускать проверки по отдельности, передайте весь пакет в tobiz_preflight_site_build и создавайте страницу только при ready_for_build=true. SEO-пакет проверяется не только по длине: метаданные должны раскрывать подтвержденную тему, а для локального бизнеса - регион из брифа. Иначе preflight вернет seo_topic_not_grounded или seo_region_missing. Для короткого сценария передайте заполненный объект целиком в tobiz_build_site_package: сначала создайте отдельный проект через tobiz_create_project(apply=true) и передайте его project_id как target_project_id. Команда не допускает сборку без цели или внутри проекта исходного шаблона, сама очищает служебное название страницы от запрещенных панелью символов, сверяет пакет, выполняет preflight и вызывает штатную сборку. Низкоуровневый вариант - передать plan_id в tobiz_build_quality_page; после сборки команда сама добавит plan_check, image_audit, claim_audit, reference_comparison и design_gate. Неподтвержденное фактическое утверждение дает save_blocked. Для уже созданной страницы используйте tobiz_check_site_plan с тем же брифом и идентификатором.

При загрузке каждого PNG, JPEG, GIF или WebP используйте media_asset из ответа tobiz_upload_image: MCP измеряет фактические размеры по содержимому файла. Не вводите width, height, aspect ratio и sha256 вручную - передавайте media_asset целиком. Для SVG без абсолютных размеров значения остаются null.

Как это устроено (коротко)

Редактор TOBIZ хранит не «значения полей», а готовый HTML блока, поэтому сервер рендерит этот HTML сам — Node с шаблонами и хелперами вендора внутри образа. Правки блоков копятся в черновике в памяти сервера и уходят на сайт только по явному tobiz_save_page.

Параметры самой страницы (название, URL, SEO, картинка для соцсетей) живут не в черновике, а в панели конструктора: tobiz_update_page читает форму страницы, подменяет указанные поля и отправляет её целиком — такое изменение видно на сайте сразу. Копирование и удаление страницы (tobiz_copy_page, tobiz_delete_page) тоже применяются немедленно.

Статьи и товары также редактируются отдельными штатными модулями TOBIZ и применяются сразу, без tobiz_save_page. Текст статьи принимает HTML CKEditor: изображения загружаются в ее галерею, а видео вставляется штатным iframe. В товаре доступны три поля видео (video1-video3) и штатные варианты (offers). Глобальные стили страницы хранятся в page_config: их правки попадают в черновик и применяются через tobiz_save_page, как обычные блоки.

До создания запускайте tobiz_preflight_article или tobiz_preflight_product с финальными полями, категориями, числом будущих изображений и вариантами товара. Это предотвращает появление пустой сущности, если пакет еще не готов. Для полной операции используйте сначала tobiz_publish_article_package(apply=false) или tobiz_publish_product_package(apply=false), затем тот же пакет с apply=true: при сбое незавершенная сущность удаляется автоматически. После ручного заполнения статьи запускайте tobiz_audit_article, после заполнения товара и вариантов - tobiz_audit_product.

В вариантах нового товара можно передать image_index - нулевой индекс изображения из массива images; MCP после загрузки заменит его на реальный штатный image_id. Каждый элемент images должен содержать ровно один источник: path либо content_base64 с обязательным file_name. Публикация считается готовой только при ready_for_publication=true: инструменты проверяют не только SEO, но и содержательность, изображения, категории, цену и уникальность вариантов. allow_price_on_request=true допустим только для заранее согласованной модели продажи без публичной цены. Для SEO-лонгрида передавайте требование клиента в minimum_body_chars при preflight, публикации, обновлении и аудите статьи. Общий tobiz_release_project_gate принимает то же ограничение как minimum_article_body_chars; например, значение 9000 не позволит принять короткую статью. Пакетная публикация и обновление перечитывают штатные категории выбранного проекта и отклоняют неизвестный category_id до первой записи. Preview с project_id выполняет ту же проверку; без project_id он явно возвращает category_check.verified=false.

Полезно знать

• Блоки не меняются без tobiz_save_page; tobiz_update_page, tobiz_copy_page и tobiz_delete_page пишут на сайт сразу — проверяйте project_id/page_id перед вызовом.

• tobiz_update_page отправляет всю форму страницы (как редактор), поэтому не переданные поля сохраняются как были — SEO можно править, не затирая название и slug.

• tobiz_delete_page требует confirm=true: без него вернётся отказ с названием страницы.

• Для экспериментов заведите отдельный сайт и TOBIZ_READ_ONLY=1.

• Если аккаунт требует капчу при входе, сервис вернёт AUTH_CAPTCHA. Тогда положите свою сессию в том — хватит двух cookie session и email:

  # cookies.json = {"session": "...", "email": "..."}
  docker run --rm -u 0 --entrypoint sh -v tobiz-session:/data -v "$PWD:/seed:ro" \
    tobiz-mcp -c 'cp /seed/cookies.json /data/session/ && chown -R 10001:10001 /data/session'
  

  После этого TOBIZ_EMAIL/TOBIZ_PASSWORD в .env можно оставить пустыми.

• tobiz_upload_image требует block_id реального блока страницы (без него конструктор отвечает «Изображение не загружено! #2»).

• Секреты не логируются: в журнал попадают только имена cookie.

Переменные окружения

После подключения запустите tobiz_onboarding_check. Для личной тестовой установки достаточно ready=true; перед передачей другим пользователям требуется distribution_ready=true. Если передать project_id и page_id, инструмент также проверит безопасное пересохранение страницы в редакторе, не изменяя сайт.

Финальная приемка перед выдачей установки пользователю:

docker run --rm --entrypoint tobiz-mcp-selftest --env-file .env \
  -v tobiz-session:/data/session -v tobiz-assets:/data/assets -v tobiz-audit:/data/audit \
  tobiz-mcp --release PAGE_ID --project PROJECT_ID

Команда возвращает код 0 только при release_ready=true; отчет печатается в JSON и подходит для CI.

Публичная проверка строит URL по реальному page_dir страницы. Параметр ?v= используется редактором TOBIZ и не считается публичным маршрутом. --render-check завершается с кодом 1, если хотя бы один блок текущей редакторской версии отсутствует на опубликованной странице. | TOBIZ_LOG_LEVEL | INFO по умолчанию, WARNING — тише |