Godot MCP 설정

MCP가 제공하는 연결을 이해하세요

Coding-Solo/godot-mcp는 Godot 프로젝트 실행, 디버그 출력 가져오기, 씬 조작을 위한 도구를 문서화합니다. 프로젝트가 유지보수하는 브리지이며 모델 서비스나 Godot 공식 배포판이 아닙니다. 에이전트에는 자체 모델 접근 권한과 적절한 로컬 권한이 여전히 필요합니다.

설정 기록에 클라이언트, MCP 서버 리비전, Godot 실행 파일이라는 세 가지 식별자를 남기세요. 하나의 실패가 다른 요소를 사용할 수 없다는 근거는 아닙니다. 문제를 어디서 검사할지 연결 다이어그램으로 판단하세요. 제공업체 인증, 클라이언트 구성, 로컬 도구 프로세스, 엔진 프로젝트 중 하나입니다.

조용히 변경하지 말고 전제조건을 목록화하세요

설치하기 전에 업스트림 요구사항을 검사하고 검토할 특정 서버 버전 또는 리비전을 선택하세요. 대화형 셸에서만이 아니라 클라이언트 프로세스에서도 기존 엔진과 런타임을 찾을 수 있는지 확인하세요. 운영체제와 의도한 프로젝트 디렉터리를 기록합니다.

의존성 변경을 허용하기 전에 업스트림 설치 절차를 검토하세요. 런타임, 서버 리비전, 설치 위치를 명시하고 이전 환경을 복원할 방법을 유지하세요. 설정 후에는 계속 바뀌는 소스 URL만 기록하지 말고 실제로 확인된 버전을 기록합니다. 클라이언트나 엔진을 나중에 업그레이드해도 작동하는 연결을 재현하기가 쉬워집니다.

문서화된 로컬 빌드 진입점을 사용하세요

업스트림 README는 build/index.js를 클라이언트 진입점으로 사용하고 GODOT_PATH를 명시적인 실행 파일 재정의로 사용하는 소스 빌드를 지원합니다. 아래 JSON은 플레이스홀더를 사용해 이미 빌드된 경로를 보여줍니다. 각 경로를 검토된 로컬 설치로 바꾸고 클라이언트 프로세스가 이를 읽을 수 있는지 확인하세요.

클라이언트가 실제로 지원하는 스키마를 사용하세요. 일반적인 mcpServers 객체가 자동으로 Codex 구성 파일이 되는 것은 아닙니다. 해당 클라이언트의 문서화된 설정을 통해서만 변환하고 모델 자격 증명은 이 엔진 도구 블록에서 제외하세요. GUI 클라이언트의 환경이 터미널과 다를 때 절대 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를 포함한 디렉터리를 식별하고 프로세스가 읽을 수 있는지 확인하세요.

프로젝트가 실행되면 씬 또는 게임플레이 오류를 재현 컨텍스트가 있는 엔진 문제로 처리하세요. 로컬 경로 문제를 해결하려고 제공업체 자격 증명을 바꾸지 마세요. 서버 로그는 신중하게 캡처하세요. 공유하기 전에 민감한 파일 시스템 세부사항을 정제하고 모든 프로젝트 작업을 무차별적으로 기록하기보다 상세한 디버깅은 임시로 유지합니다.

승인과 네트워크 경계를 좁게 유지하세요

엔진 도구는 작동 중인 프로젝트를 변경하거나 코드를 실행할 수 있습니다. 가장 작은 적절한 디렉터리에 접근 권한을 주고 동작을 이해할 때까지 변경 요청을 검토하세요. 예시 구성에 보인다는 이유만으로 광범위한 자동 승인 목록을 복사하지 마세요.

가져온 스크립트, 플러그인, 도구 출력을 권한을 확장할 수 있는 지시가 아니라 검사할 자료로 취급하세요. 패키지 다운로드, 소유 씬 외부 파일 삭제, 자격 증명 변경, 게시에는 명시적인 결정이 필요합니다. 첫 번째 성공적인 미니플로는 정책을 검토하는 근거이지 이후 모든 도구 작업을 허용할 이유가 아닙니다.

검증된 설정의 한계를 기록하세요

완료된 설정 기록에는 서버 리비전, 클라이언트, 엔진 버전, 프로젝트 경로, 검색된 도구, 완료된 읽기, 되돌릴 수 있는 변경, 런타임 결과가 식별되어야 합니다. 아직 테스트하지 않은 작업을 밝히세요. 보편적인 호환성 보장처럼 제시하지 말고 게임 근거와 함께 보존하세요.

다음 단계는 제작 루프입니다. 기능 구현, 동작 재현, 내보내기, 대상 플랫폼 테스트로 이어집니다. 여기의 구성은 업스트림 문서를 따르며 선택한 클라이언트와 버전에서 검증해야 합니다. 범위가 정해진 결과를 프로젝트와 함께 보존하고 서버, 엔진, 클라이언트가 바뀔 때마다 같은 검사 기준을 다시 사용하세요.

자주 묻는 질문