Переезд сотни страниц через MCP выглядит как реклама агентов, но практический вывод здесь прозаичнее. MCP полезен не потому, что данных много, а потому, что преобразования нельзя заранее свести к одной безошибочной инструкции. Если можно, обычный скрипт по-прежнему будет проще.
В разборе на Habr команда CRM-платформы описывает миграцию документации из GitBook в Diplodoc. Портал несколько месяцев работал нестабильно, а затем обращения пользователей начали приходить напрямую в чаты и на почту. Ждать дальше команда не стала: примерно сотня страниц переехала за четыре дня.
Конвертер для выгрузки не писали и регулярными выражениями её не разбирали. У GitBook уже был MCP-сервер, поэтому агенту дали доступ к содержимому и поручили перенос. После миграции осталось десять типов правок, которые пришлось корректировать вручную.
Почему это не просто ещё один способ запустить скрипт
В этой задаче MCP заменил не код как таковой, а необходимость заранее описать всю миграцию в виде жёсткого алгоритма. Для однообразных файлов это сомнительная сделка: разработчик быстрее задаст правило, прогонит его по репозиторию и проверит diff. Агент добавляет стоимость и неопределённость там, где результат и без него полностью предсказуем.
Но документация редко остаётся однородной после нескольких лет жизни в визуальном редакторе. Страницы различаются структурой, назначением и количеством элементов, которые требуют решения по месту. Именно здесь интерфейс к исходной системе становится полезнее одноразового конвертера: агент может получать нужный материал порциями, применять доступные операции и оставлять человеку пограничные случаи.
Это не означает, что MCP автоматически обеспечивает качество. В кейсе на Habr после переезда всё равно понадобилась ручная корректировка. Скорее наоборот: десять типов исправлений напоминают, что агентная миграция нуждается в ревью так же, как миграция скриптом. Разница в том, что команда не обязана сначала превращать каждое исключение в ветку кода, а затем выбрасывать этот код после единственного запуска.
Выбор целевой платформы усилил этот подход. Diplodoc хранит документацию в Markdown и гите, поэтому изменения можно проводить через PR, смотреть историю, работать с ветками и откатываться. Для команды, которая уже использует git, это превращает проверку миграции в знакомый процесс, а не в обход сотни страниц мышкой.
Альтернатива с Tilda как раз требовала бы ручного переноса через визуальный редактор. По оценке авторов разбора, это заняло бы недели монотонной работы, а последующие правки снова зависели бы от человека и интерфейса. Другой зарубежный SaaS команда отложила после проблем с доступностью GitBook. Собственный портал тоже отвергли: во время глобальной миграции пользователей с MS SQL на PostgreSQL тратить внимание продуктовой команды на новый внутренний инструмент сочли слишком дорогим.
Где проходит граница
Из этого кейса не следует, что следующую массовую правку документации нужно начинать с MCP-сервера. Если задача звучит как «заменить один URL во всех файлах», «переименовать поле» или «добавить одинаковый блок», я бы выбирал скрипт. У него понятный вход, воспроизводимый результат и дешёвая проверка.
MCP имеет смысл, когда операций несколько, страницы заметно различаются, исходную систему нужно читать через её интерфейс, а результат всё равно будет проходить человеческое ревью. Особенно если те же инструменты пригодятся позже для обновлений, аудита или следующего этапа переноса. Тогда команда строит не одноразовый конвертер, а управляемый контур работы с документацией.
Есть и накладные расходы. Нужно подключить сервер, определить доступные агенту действия, контролировать результат и разбирать исключения. В опубликованном кейсе нет сравнения стоимости токенов, времени разработки скрипта и доли автоматически принятых изменений, поэтому объявлять MCP экономически лучшим вариантом рано. Четыре дня на миграцию показывают работоспособность подхода, но не дают универсального тарифа на сотню страниц.
Практический критерий для следующего проекта простой: перед разработкой посчитайте не страницы, а классы преобразований. Один класс с чётким правилом означает скрипт. Много исключений, необходимость читать контекст и регулярное вмешательство редактора делают MCP разумным кандидатом.
А смотреть дальше стоит на повторное использование созданного контура. Если следующая крупная правка пройдёт через те же MCP-инструменты, а число ручных корректировок сократится, инвестиция действительно окупилась. Если сервер понадобился один раз, а почти все изменения пришлось перепроверять и чинить вручную, это был просто более эффектный способ не писать конвертер.