Konfiguracja Unity MCP

Zrozum most edytora

CoplayDev/unity-mcp łączy klienta MCP z serwerem i pakietem po stronie edytora. Usługa modelu jest osobną zależnością. Projekt dokumentuje narzędzia do pracy ze scenami, skryptami, zasobami i testami, ale wymieniona możliwość nie dowodzi działania w twoim projekcie.

Zapisz, który proces posiada każdą część połączenia. Ma to znaczenie przy diagnozowaniu klienta, który dociera do serwera, lecz nie może obsługiwać edytora. Utrzymuj osobne kontrole danych konta, licencji edytora, zgodności pakietów i dostępności modelu. Zmiana modelu nie naprawi rozbieżności instancji edytora.

Sprawdź ścieżkę instalacji i politykę przypinania

Przewodnik instalacji projektu opisuje dodanie pakietu przez Unity Package Manager oraz użycie interfejsu konfiguracji do ustawienia serwera i klienta. Przed instalacją czegokolwiek sprawdź wymagania Unity, Python i uv podanej rewizji.

Dla odtwarzalności po konfiguracji zachowaj rozstrzygniętą rewizję pakietu, wersję edytora, wersję serwera i rekordy zależności. Ruchomy URL gałęzi służy do odkrywania, a nie jako niezmienna tożsamość eksperymentu. Przejrzyj pobieranie i zmiany pakietów przed zastosowaniem ich w istniejącej grze oraz zachowaj poprzedni działający stan projektu, aby eksperyment połączenia można było odwrócić.

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

Dopasuj lokalny endpoint HTTP do klienta

Utrzymywany przewodnik instalacji dokumentuje poniższy lokalny przykład HTTP. Zakłada on, że serwer już działa pod tym adresem. Przed użyciem potwierdź faktyczny transport i adres w interfejsie konfiguracji edytora. URL MCP nie jest bazowym URL API LLM.

Użyj formatu konfiguracji udokumentowanego przez klienta. Niektórzy klienci używają innych kluczy głównych lub deklaracji transportu, dlatego ogólny przykład mcpServers nie jest uniwersalnym plikiem do wklejenia do każdego agenta. Zostaw serwer lokalny, chyba że osobno sprawdzona konfiguracja zdalna jest wymagana, i nie dodawaj danych modelu do niepowiązanego połączenia edytora.

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

Potwierdź, która instancja edytora otrzymuje pracę

Otwórz zamierzony projekt i sprawdź stan połączenia przez interfejs pakietu. Następnie użyj wykrytych operacji odczytu klienta, aby pobrać kontekst projektu i sceny. Dopasuj te dane do lokalnego projektu przed zatwierdzeniem edycji. Wiele otwartych projektów czyni tę bramkę szczególnie ważną.

Zapisuj rzeczywiste zasoby i schematy narzędzi z zainstalowanej wersji. Nie wymyślaj wywołania narzędzia na podstawie nazwy zapamiętanej z innego wydania. Dobry pierwszy wynik identyfikuje oczekiwaną scenę i istniejące obiekty bez ich zmiany. Jeśli zwrócony stan jest nieaktualny lub niejednoznaczny, zatrzymaj się i rozwiąż routing zamiast wykonywać widoczną mutację w celu odkrycia celu.

Użyj odwracalnej edycji jako pierwszego miniprzebiegu

Wybierz własną, tymczasową scenę, zapisz jej stan początkowy i poproś o jedną prostą zmianę z widocznym skutkiem. Sprawdź zapisaną scenę i diff pliku, poczekaj na gotowość edytora i uruchom scenę. Zachowaj obserwowane zachowanie i wszystkie błędy konsoli.

Następnie ponownie otwórz scenę, aby potwierdzić trwałość zmiany. Odróżnia to efekt edytora w pamięci od zapisanego projektu. Proces powinien być na tyle mały, by awarię można było przypisać jednej granicy: routingowi, mutacji, kompilacji, wykonaniu albo trwałości. Po przeglądzie przywróć scenę tymczasową i użyj zarejestrowanej działającej konfiguracji do kolejnego zadania.

Najpierw rozwiązuj problemy transportu, potem gry

Gdy klient nie może się połączyć, sprawdź skonfigurowany URL i działanie lokalnego serwera. Gdy serwer startuje, ale brakuje edytora, przejrzyj połączenie pakietu i logi edytora. Gdy właściwy edytor jest połączony, ale brakuje narzędzia, sprawdź grupy narzędzi udostępniane przez zainstalowaną wersję.

Dopiero po rozwiązaniu tej granicy diagnozuj kompilację lub rozgrywkę. Trzymaj osobne fragmenty logów startu klienta, routingu serwera, gotowości edytora i nieudanej akcji sceny. Dzięki temu raport wyjaśnia, gdzie zatrzymało się wykonanie, zamiast przypisywać każdy błąd modelowi lub wielokrotnie reinstalować komponenty bez dowodów.

Chroń projekt przed szeroką automatyzacją

Połączenie z edytorem może zmieniać sceny, skrypty i zasoby. Ogranicz pierwszy eksperyment do znanego katalogu i wymagaj przeglądu operacji usuwających zasoby, zmieniających zależności lub dotykających niezwiązanych scen. Przed pierwszą zmianą zachowaj możliwy do odzyskania stan pracy.

Nie wystawiaj publicznie lokalnej usługi developerskiej tylko po to, by rozwiązać problem konfiguracji klienta. Treści zasobów zewnętrznych i wyniki narzędzi traktuj jako niezaufane dane, a dane uwierzytelniające trzymaj poza współdzielonymi logami. Udane połączenie nie jest zgodą na przesyłanie kompilacji ani modyfikację rekordów sklepu. Publikacja pozostaje osobnym procesem i granicą autoryzacji.

Przekaż odtwarzalny zapis połączenia

Zapisz rewizje edytora, projektu, pakietu i serwera, wersję klienta, transport, obserwowaną powierzchnię narzędzi i ukończony miniprzebieg. Zachowaj dokładny diff sceny i wynik runtime. Określ, czy sprawdzono kompilację, zachowanie PlayMode, testy i eksport docelowy, czy nadal czekają.

Ta konfiguracja podąża za utrzymywaną dokumentacją projektu; zweryfikuj ją z zainstalowanym pakietem i klientem. W produkcji gry przejdź do przewodnika Unity i przetestuj pełną pętlę. Ograniczenia znane zachowaj w przekazaniu, aby inny deweloper mógł odróżnić problem połączenia od problemu projektu i odtworzyć tę samą działającą konfigurację.

Częste pytania