Godot MCP — это связка редактора Godot с ИИ-клиентом через плагин и MCP-сервер, в которой агент читает дерево сцены, предлагает узлы и скрипты, а разработчик проверяет результат запуском и просмотром изменений в Git. Официального сервера на сайте движка в проверенных источниках нет: на GitHub лежат проекты сообщества. Разбор относится к Godot 4; мост для Unity устроен иначе и описан в соседней статье.
Проекты сообщества
Официального MCP-сервера для Godot в проверенных источниках нет; пользуются проектами сообщества, которые ставят плагин в редактор и соединяют его с отдельным сервером.
На GitHub лежит заметное число репозиториев независимых авторов с разным набором инструментов: узлы и сцены, скрипты, скриншоты, консоль, запуск проекта. Типовая архитектура у них похожа. Клиент говорит с MCP-сервером, сервер соединяется с плагином внутри открытого редактора по WebSocket, и плагин выполняет команды. Так устроены, например, godot-ai и godot-mcp от mkdevkit.
О защите авторы пишут по-разному. README godot-ai сообщает, что WebSocket редактора слушает только локальный адрес, а обе локальные связи закрыты ротируемыми ключами.
Там же есть честная оговорка: эти меры бессильны против скомпрометированного процесса того же пользователя.
Практический вывод: рабочую машину с открытым редактором считают доверенной зоной, а посторонние программы на ней, расширения и скрипты из случайных источников держат на другой машине. Для выбора проекта сверяют минимальную версию редактора (README godot-ai на 5 октября 2026 года называет Godot 4.7 и новее), лицензию, поддержку языка скриптов и набор инструментов записи. У C# в этом проекте возможности ограничены текстовой правкой, а сборка выполняется в самом редакторе. Если проект командный, выбор фиксируют в README репозитория, чтобы у всех разработчиков стоял один и тот же плагин одной версии. Параллельный материал про Unity MCP показывает, чем отличается мост у другого движка.
Сцена как текст
Сцены и скрипты Godot хранятся в текстовых файлах, поэтому изменения агента видны в обычном diff Git. Поэтому любую правку можно прочитать, откатить и обсудить построчно. Сцена в Godot — дерево узлов, где у каждого есть тип, свойства, прикреплённый скрипт и подключённые сигналы.
- дерево узлов открытой сцены с типами и путями;
- свойства выбранного узла и подключённые к нему сигналы;
- прикреплённые скрипты и их текст;
- сообщения консоли редактора и ошибки разбора скриптов.
Условный пример: на уровне стоит дверь, и разработчик хочет, чтобы она открывалась, когда игрок входит в зону рядом. Первым запросом агент описывает существующую структуру: какие узлы входят в сцену двери, есть ли область-триггер, какие сигналы уже подключены. Разработчик сверяет описание с панелью сцены в редакторе. Такая сверка сразу показывает, видит ли агент ту же сцену, что и вы. Расхождение означает, что агент смотрит в другое место: например, в редакторе открыта другая сцена.
Чтение идёт по текстовым данным проекта и данным открытого редактора, а решение о том, как должна выглядеть игра, остаётся у дизайнера и разработчика. Агент объясняет, как устроено дерево, и предлагает варианты, но вкус и баланс остаются за людьми.
Скрипт и сигнал
- Создайте ветку Git и копию проекта, а в редакторе откройте только эту копию.
- Попросите агента составить план без записи: какие узлы добавить, какой сигнал подключить, какой скрипт GDScript написать.
- Разрешите запись в пределах плана: один узел-триггер и один скрипт в папке сцены двери.
- Дождитесь, пока редактор разберёт скрипт, и прочитайте сообщения консоли.
- Откройте diff и проверьте, что затронуты только файлы сцены двери и новый скрипт.
Файлы настроек проекта, карту ввода и сцены других уровней агенту трогать запрещают списком разрешённых путей. Такое ограничение держит клиент или обёртка над сервером: словесная просьба в инструкции защитой служить способна лишь условно, поэтому ограничение закрепляют настройками. По описанию godot-ai, скрипты GDScript проходят разбор, перезагрузку и привязку к узлу, так что синтаксическая ошибка видна сразу, задолго до релизной сборки.
Если агент предложил подключить сигнал другим способом, чем принято в вашем проекте, поправьте инструкцию и повторите шаг. Единый стиль подключения сигналов и именования узлов записывают в короткий документ, который агент читает перед работой: так новые узлы получают привычные названия, а скрипты ложатся в те же папки, где команда ищет их привычно. Такой документ растёт по мере работы и заодно служит памяткой для новых разработчиков.
Тест запуска
Скрипт без ошибок разбора о поведении сцены пока молчит. Проверка поведения идёт отдельно, и результат фиксирует человек либо автоматический тест.
| Проверка | Как выполняется | Признак успеха |
|---|---|---|
| Разбор скрипта | Редактор разбирает файл при сохранении | В консоли нет ошибок и предупреждений по новому файлу |
| Запуск сцены | Разработчик запускает сцену двери вручную | Дверь открывается, когда игрок входит в зону |
| Автотест | Тестовый каркас проекта вроде GUT, если он подключён | Прежние тесты проходят, новый сценарий добавлен |
| Скриншот сцены | Инструмент сервера или ручной снимок | Раскладка узлов совпадает с ожидаемой |
Ручной запуск остаётся главным способом увидеть игру глазами игрока. Тест на закрытие двери, повторный вход и выход из зоны записывают заранее, иначе проверяется только удачный путь. Скриншот полезен как вспомогательный сигнал о раскладке, зато физику и тайминг он скрывает целиком.
Автоматические тесты в небольших проектах встречаются редко, и это нормально: тогда ручной сценарий записывают в описание изменения и повторяют перед слиянием. Каждая новая правка агента добавляет строку в этот список проверок, и со временем он превращается в набор регрессионных сценариев, которые можно автоматизировать, когда проект подрастёт.
Какую часть уровня ваша команда готова поручить агенту первой?
Review разработчика
Review начинается с чтения diff. В текстовой сцене нужно искать лишние строки: изменённые свойства узлов, о которых агент молчал, переставленные идентификаторы ресурсов, новые внешние ресурсы. Крупный diff по сцене там, где просили добавить один скрипт, повод вернуть работу и уточнить границы задачи. Полезно также открыть сцену в редакторе и убедиться, что внешне всё осталось на местах: размеры, позиции и порядок отрисовки узлов остаются прежними.
Решение о слиянии принимает разработчик после ручного запуска, а сообщение к изменению описывает, что поручали агенту и что проверили руками. Рекомендации агента по структуре сцены воспринимаются как предложения, а выбор архитектуры игры остаётся за командой. Право записи в основную ветку регулируется настройками репозитория, а обещание модели «трогать только нужное» защитой служить неспособно.
Отдельно проверяют ресурсы: новые изображения, звуки и сцены, которые агент мог добавить в проект. Каждый внешний ресурс должен иметь понятное происхождение и лицензию, иначе его удаляют из изменения. Эта проверка избавляет от неприятных сюрпризов при публикации игры.
Журнал работы ведут в описании изменения: что поручали, какие инструменты разрешали, что запускали и что нашли при проверке. Через несколько правок такие записи показывают, где агент надёжен, например в типовых скриптах для триггеров, а где требует особо внимательного чтения, например в изменениях сложных сцен с вложенными узлами.
Откройте пустой тестовый проект и поставьте плагин одного выбранного сообщества. Попросите агента описать дерево сцены, затем добавьте одну дверь и один скрипт, сравнив результат с diff. Для проектного подхода с правами, ветками и приёмкой посмотрите, как мы консультируем команды по Claude Code.