Налаштування Godot MCP

Зрозумійте, яке з’єднання надає MCP

Coding-Solo/godot-mcp документує інструменти для запуску проєктів Godot, отримання налагоджувального виводу та роботи зі сценами. Це міст, який підтримує проєкт, а не сервіс моделі чи офіційний дистрибутив Godot. Агенту все одно потрібні власний доступ до моделі та відповідні локальні дозволи.

Зберігайте в записі налаштування три ідентичності: клієнта, ревізію сервера MCP і виконуваний файл Godot. Збій одного не є доказом недоступності інших. Використовуйте схему з’єднання, щоб вирішити, де перевіряти проблему: автентифікація провайдера, конфігурація клієнта, локальний процес інструмента чи проєкт рушія.

Складіть інвентар передумов, не змінюючи їх мовчки

До встановлення перевірте вимоги висхідного проєкту та виберіть конкретну версію або ревізію сервера для перевірки. Підтвердьте, що наявний рушій і середовище виконання знаходяться з процесу клієнта, а не лише з інтерактивної оболонки. Запишіть операційну систему та передбачений каталог проєкту.

Перегляньте процедуру встановлення висхідного проєкту до дозволу змін залежностей. Назвіть середовище виконання, ревізію сервера й місце встановлення та збережіть спосіб відновити попереднє середовище. Після налаштування запишіть розв’язані версії, а не лише рухомий URL джерела. Це допоможе відтворити робоче з’єднання після подальшого оновлення клієнта або рушія.

Використовуйте документовану локальну точку збірки

README висхідного проєкту підтримує збірку з джерела з build/index.js як точкою входу клієнта та GODOT_PATH як явним перевизначенням виконуваного файла. Наведений нижче JSON ілюструє вже зібраний маршрут із заповнювачами. Замініть кожен шлях перевіреною локальною інсталяцією та переконайтеся, що процес клієнта може його прочитати.

Використовуйте схему, яку фактично підтримує ваш клієнт. Загальний об’єкт mcpServers автоматично не є файлом конфігурації Codex. Перекладайте лише через документовані налаштування цього клієнта й тримайте облікові дані моделі поза блоком інструментів рушія. Абсолютний шлях Node може бути корисним, коли середовище графічного клієнта відрізняється від термінала.

{
  "mcpServers": {
    "godot": {
      "command": "/absolute/path/to/node",
      "args": ["/absolute/path/to/reviewed-godot-mcp/build/index.js"],
      "env": {
        "GODOT_PATH": "/absolute/path/to/godot"
      }
    }
  }
}

Спочатку перевірте шлях інструментів лише для читання

Перевірте інструменти, повернуті налаштованим сервером, замість довіри до списку з пам’яті. README називає get_godot_version і get_project_info корисними операціями перевірки. Перегляньте знайдену схему параметрів, а потім націльтеся лише на схвалений каталог проєкту.

Порівняйте повернені дані про рушій і проєкт із записом налаштування. Зберігайте структуровані результати й помилки. Не схвалюйте створення сцени, доки спостереження не визначить потрібний робочий простір. Якщо клієнт показує значок підключення, але не може завершити це читання, з’єднання не готове до експерименту з ігровим процесом. Сам значок не показує, до якого процесу чи проєкту дійшли.

Авторизуйте один оборотний мініпроцес сцени

Після перевірки доступу на читання використайте для першого запису одноразову власну сцену. Запишіть її початковий стан, попросіть одну видиму зміну, перевірте збережену сцену, запустіть її, отримайте вивід і зупиніть проєкт. Зберігайте отриманий diff файла та спостереження разом.

Умова прийняття — це ланцюжок від запитаної зміни до збереженого ресурсу та видимої поведінки під час виконання. Коли інструмент повідомляє про успіх, але сцена не змінюється, перевірте націлювання проєкту й шляхи збереження до другої мутації. Після збереження знову відкрийте сцену, щоб перевірка охоплювала і сталість, і поточний стан у пам’яті.

Діагностуйте збої на правильній межі

Якщо запуск процесу не вдається, перевірте шляхи середовища виконання й точки входу. Якщо Godot не знаходиться, перевірте перевизначення виконуваного файла із середовища клієнта. Якщо проєкт не можна перевірити, переконайтеся, що шлях указує на каталог із project.godot і доступний процесу.

Коли проєкт запускається, розглядайте помилки сцени або ігрового процесу як проблеми рушія з контекстом відтворення. Не змінюйте облікові дані провайдера для виправлення локальних проблем шляхів. Обережно фіксуйте журнали сервера: перед поширенням очищайте чутливі деталі файлової системи та робіть детальне налагодження тимчасовим, а не безрозбірно записуйте кожну операцію проєкту.

Зберігайте межі схвалення та мережі вузькими

Інструмент рушія може змінити робочий проєкт або запустити код. Надайте доступ до найменшого відповідного каталогу та перевіряйте запити мутації, доки поведінка не стане зрозумілою. Не копіюйте широкі списки автоматичного схвалення лише тому, що вони є у прикладі конфігурації.

Розглядайте імпортовані скрипти, плагіни та вивід інструментів як матеріал для перевірки, а не інструкції, що можуть розширити повноваження. Завантаження пакетів, видалення файлів поза власною сценою, зміни облікових даних і публікація потребують явних рішень. Перша успішна мініперевірка є основою перегляду політики, а не причиною дозволити кожну майбутню дію інструмента.

Запишіть межі перевіреного налаштування

Завершений запис налаштування має називати ревізію сервера, клієнта, версію рушія, шлях проєкту, знайдені інструменти, виконане читання, оборотну зміну та результат виконання. Укажіть, які дії залишилися неперевіреними. Зберігайте запис разом із доказами гри, а не подавайте універсальну гарантію сумісності.

Наступний шар — виробничий цикл: реалізувати функцію, відтворити її поведінку, експортувати та перевірити на цільовій платформі. Наведена конфігурація відповідає документації висхідного проєкту й має бути перевірена для вибраного клієнта та версій. Збережіть цей обмежений результат у проєкті та повторюйте ту саму контрольну точку перевірки щоразу, коли змінюється сервер, рушій або клієнт.

Поширені запитання