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

Зрозумійте міст редактора

CoplayDev/unity-mcp підключає клієнт MCP до сервера та пакета на боці редактора. Сервіс моделі є окремою залежністю. Проєкт документує інструменти для роботи зі сценами, скриптами, ресурсами й тестами, але перелічена можливість не доводить, що вона працює у вашому проєкті.

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

Перевірте шлях установлення й політику фіксації версій

Посібник установлення проєкту описує додавання пакета через Unity Package Manager і використання інтерфейсу налаштування сервера та клієнта. Перед установленням перевірте заявлені передумови Unity, Python та uv для вибраної ревізії.

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

https://github.com/CoplayDev/unity-mcp.git?path=/MCPForUnity#main

Узгодьте локальну HTTP-кінцеву точку з клієнтом

Підтримуваний посібник установлення документує наведений нижче локальний приклад HTTP. Він припускає, що сервер уже працює за цією адресою. Перед використанням підтвердьте фактичний транспорт і адресу в інтерфейсі налаштування редактора. URL MCP не є базовою URL API LLM.

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

{
  "mcpServers": {
    "unityMCP": {
      "url": "http://localhost:8080/mcp"
    }
  }
}

Доведіть, який екземпляр редактора отримує роботу

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

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

Зробіть оборотне редагування першим miniflow

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

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

Спочатку усувайте проблеми транспорту, потім гри

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

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

Захистіть проєкт від широкої автоматизації

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

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

Передайте відтворюваний запис з’єднання

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

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

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