Konfiguracja Godot MCP

Zrozum, jakie połączenie zapewnia MCP

Coding-Solo/godot-mcp dokumentuje narzędzia do uruchamiania projektów Godot, pobierania danych debugowania i pracy na scenach. To most utrzymywany przez projekt, a nie usługa modelu ani oficjalna dystrybucja Godot. Agent nadal potrzebuje własnego dostępu do modelu i odpowiednich lokalnych uprawnień.

W rejestrze konfiguracji zachowaj trzy tożsamości: klienta, rewizję serwera MCP i plik wykonywalny Godot. Awaria jednego nie jest dowodem niedostępności pozostałych. Użyj diagramu połączenia, aby zdecydować, gdzie zbadać problem: uwierzytelnianie dostawcy, konfiguracja klienta, lokalny proces narzędzia czy projekt silnika.

Zrób inwentaryzację wymagań bez cichego ich zmieniania

Przed instalacją sprawdź wymagania service i wybierz konkretną wersję lub rewizję serwera do przeglądu. Potwierdź, że silnik i runtime można znaleźć z procesu klienta, a nie tylko z interaktywnego shella. Zapisz system operacyjny i zamierzony katalog projektu.

Przejrzyj procedurę instalacji service przed zezwoleniem na zmiany zależności. Nazwij runtime, rewizję serwera i miejsce instalacji oraz zachowaj możliwość odtworzenia poprzedniego środowiska. Po konfiguracji zapisz rozstrzygnięte wersje, a nie tylko ruchomy URL źródła. Ułatwia to odtworzenie działającego połączenia po późniejszej aktualizacji klienta lub silnika.

Użyj udokumentowanego lokalnego punktu wejścia budowania

README service obsługuje budowanie ze źródeł z build/index.js jako punktem wejścia klienta i GODOT_PATH jako jawnym nadpisaniem pliku wykonywalnego. Poniższy JSON ilustruje tę już zbudowaną ścieżkę z placeholderami. Zastąp każdą ścieżkę sprawdzoną instalacją lokalną i upewnij się, że proces klienta może ją odczytać.

Używaj schematu faktycznie obsługiwanego przez klienta. Ogólny obiekt mcpServers nie jest automatycznie plikiem konfiguracji Codex. Tłumacz ustawienia tylko zgodnie z dokumentacją klienta i trzymaj dane modelu poza tym blokiem narzędzi silnika. Absolutna ścieżka Node może pomóc, gdy środowisko klienta GUI różni się od terminala.

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

Najpierw zweryfikuj ścieżkę narzędzi tylko do odczytu

Sprawdź narzędzia zwrócone przez skonfigurowany serwer zamiast polegać na zapamiętanej liście. README wymienia get_godot_version i get_project_info jako przydatne operacje inspekcji. Sprawdź wykryty schemat parametrów, a następnie wskaż tylko zatwierdzony katalog projektu.

Porównaj zwrócone informacje o silniku i projekcie z rejestrem konfiguracji. Zachowaj strukturalne wyniki i błędy. Nie zatwierdzaj tworzenia sceny, dopóki obserwacja nie wskaże zamierzonego obszaru roboczego. Jeśli klient pokazuje odznakę połączenia, ale nie może wykonać odczytu, połączenie nie jest gotowe do eksperymentu rozgrywki. Sama odznaka nie pokazuje, do jakiego procesu lub projektu dotarto.

Zatwierdź jeden odwracalny miniprzebieg sceny

Po sprawdzeniu dostępu do odczytu użyj własnej, tymczasowej sceny do pierwszego zapisu. Zapisz stan początkowy, poproś o jedną widoczną zmianę, sprawdź zapisaną scenę, uruchom ją, pobierz wyjście i zatrzymaj projekt. Wynikowy diff pliku i obserwacje trzymaj razem.

Warunkiem akceptacji jest łańcuch od żądanej zmiany przez zapisany zasób do widocznego zachowania runtime. Jeśli narzędzie zgłosi sukces, ale scena się nie zmieni, przed drugą mutacją sprawdź kierowanie projektem i zapisane ścieżki. Po zapisie ponownie otwórz scenę, aby kontrola obejmowała trwałość, a nie tylko stan w pamięci.

Diagnozuj awarie na właściwej granicy

Jeśli start procesu zawiedzie, sprawdź ścieżki runtime i punktu wejścia. Jeśli Godot nie zostanie znaleziony, zweryfikuj nadpisanie pliku wykonywalnego w środowisku klienta. Jeśli nie można sprawdzić projektu, upewnij się, że ścieżka wskazuje katalog z project.godot i że proces ma prawo go odczytać.

Gdy projekt już działa, traktuj błędy sceny lub rozgrywki jako problemy silnika z kontekstem reprodukcji. Nie zmieniaj danych dostawcy, aby naprawić lokalne problemy ścieżek. Logi serwera przechwytuj ostrożnie: przed udostępnieniem oczyść wrażliwe szczegóły systemu plików i trzymaj szczegółowe debugowanie tymczasowo, zamiast bezmyślnie rejestrować każdą operację projektu.

Utrzymuj wąskie granice zgód i sieci

Narzędzie silnika może zmienić działający projekt lub uruchomić kod. Przyznaj dostęp do najmniejszego odpowiedniego katalogu i przeglądaj żądania mutacji, dopóki nie zrozumiesz zachowania. Nie kopiuj szerokich list automatycznych zgód tylko dlatego, że pojawiają się w przykładowej konfiguracji.

Importowane skrypty, pluginy i wyjście narzędzi traktuj jako materiał do inspekcji, a nie instrukcje mogące rozszerzać uprawnienia. Pobieranie pakietów, usuwanie plików poza własną sceną, zmiany danych uwierzytelniających i publikowanie wymagają jawnych decyzji. Pierwszy udany miniprzebieg jest podstawą przeglądu polityki, a nie powodem do zezwolenia na każdą przyszłą akcję narzędzia.

Zapisz ograniczenia zweryfikowanej konfiguracji

Ukończony zapis konfiguracji powinien wskazywać rewizję serwera, klienta, wersję silnika, ścieżkę projektu, wykryte narzędzia, wykonany odczyt, odwracalną zmianę i wynik runtime. Określ, które działania nadal nie zostały sprawdzone. Trzymaj zapis przy dowodach gry, zamiast przedstawiać go jako uniwersalną gwarancję zgodności.

Następną warstwą jest proces produkcyjny: implementacja funkcji, odtworzenie zachowania, eksport i test na platformie docelowej. Konfiguracja tutaj podąża za dokumentacją service i musi zostać zweryfikowana dla wybranego klienta i wersji. Zachowaj ograniczony wynik przy projekcie i powtarzaj tę samą bramkę inspekcji po każdej zmianie serwera, silnika lub klienta.

Częste pytania