Install
"command": "npx",
"args": ["-y", "ue-mcp@latest", "C:/path/to/MyGame.uproject"]누구에게 맞나
Windows(UE 5.4-5.8) 또는 Linux/macOS(UE 5.6+)에서 Unreal Engine 프로젝트를 개발하며 MCP 클라이언트에서 자연어로 에디터를 다루고 싶은 개발자와 테크니컬 아티스트. 공식 설명에 따르면 블루프린트, 머티리얼, 레벨, 액터, 애니메이션, VFX, 랜드스케이프, PCG, 폴리지, 오디오, UI, 물리, 내비게이션, AI, 네트워킹, 시퀀서, 빌드 파이프라인 등을 아우르는 29개 도구 카테고리와 2040개 이상의 액션, 그리고 여러 단계 워크플로용 YAML 플로 엔진을 제공한다. 에디터 안에서 반복적인 씬 구성과 에셋 조정을 자주 하거나 AI에게 에디터 작업 일부를 맡기고 싶을 때 가장 잘 맞는다. 에디터를 열지 않는 오프라인 파이프라인에는 쓸모가 없다. 판단 기준은 간단하다. 일상 작업의 대부분이 에디터 안에서 이루어지는지, 모델이 프로젝트 에셋을 직접 바꾸도록 맡겨도 되는지. 둘 다 예일 때만 읽어 내려가라.
사용 전제는 로컬 툴체인이 갖춰져 있다는 것이다. Node.js 18 이상. 엔진에 포함된 PythonScriptPlugin(엔진에 함께 제공되며 init가 나머지 필요한 플러그인을 활성화해 준다). 그리고 필수인 C++ 툴체인 — Windows는 C++ 워크로드가 포함된 Visual Studio, macOS는 Xcode 명령줄 도구. 브리지 플러그인이 에디터 첫 시작 때 컴파일되기 때문이다. C++ 툴체인이 없거나 프로젝트에 C++ 플러그인을 배포하고 싶지 않은 머신에는 맞지 않는다. epic 카테고리 기능에는 UE 5.8+이 필요하다. 한 가지 더, 플러그인 배포는 프로젝트 단위로 일어난다. 프로젝트를 바꿀 때는 새 프로젝트에서 대화형 init를 다시 실행해 브리지 플러그인을 배포하고, 그 프로젝트의 에디터 첫 시작 때 컴파일이 끝나기를 기다려야 한다. 프로젝트 전환의 전체 절차는 근거에 나와 있지 않아 확인되지 않았다. 라이선스, 비용, 프로젝트 규모에 대한 추가 요구사항도 근거에 언급이 없으므로 직접 확인하라.
3분 만에 첫 시도
권장 경로는 MCP 클라이언트 설정에서 npx로 서버를 시작해 .uproject를 가리키는 것이다. 전제: 위에 나열한 UE, Node.js 18+, C++ 툴체인이 이미 설치되어 있을 것.
클라이언트 설정에 공식 스니펫을 추가한다:
"command": "npx",
"args": ["-y", "ue-mcp@latest", "C:/path/to/MyGame.uproject"]
C:/path/to/MyGame.uproject를 자신의 프로젝트 파일 경로로 바꾼다. 첫 실행에서는 대화형 설정이 진행된다. 현재 디렉터리의 .uproject를 자동으로 찾고, 활성화할 도구 카테고리를 선택하게 하고, C++ 브리지 플러그인을 프로젝트에 배포하고, 필요한 UE 플러그인(Niagara, PCG, GAS 등)을 켜고, MCP 클라이언트를 감지해 설정한다.
성공 신호: 에디터 첫 시작의 플러그인 컴파일이 끝나면 클라이언트에서 이 서버의 도구 카테고리가 보인다. 열려 있는 에디터에 자연어로 명령 하나를 내려 에디터 안에서 실제 반응이 관찰되는지 확인한다. 카테고리가 좀처럼 나타나지 않으면 설정의 프로젝트 경로가 맞는지 먼저 확인하고, 첫 컴파일이 끝나기를 기다린다.
주의: 공식은 이 도구를 AI 어시스턴트에게 에디터에 대한 깊은 읽기/쓰기 접근을 주는 것으로 위치시키며, 쓰기 작업은 프로젝트 내용을 직접 바꾼다. 근거에는 개별 도구 이름과 읽기/쓰기 구분이 나와 있지 않아 특정 읽기 전용 도구를 첫 호출로 지정할 수 없다. 버전 관리 중이거나 백업이 있는 프로젝트에서 먼저 시도하고, AI가 행동에 앞서 어떤 작업을 수행할지 설명하게 하라.
사용 사례
사례 1: 자연어로 레벨과 액터 조정하기. 에디터를 연 뒤 클라이언트에 원하는 씬 변경을 한 문장으로 설명하면 서버가 레벨·액터 카테고리 도구를 호출해 에디터에서 실행한다. 기대할 수 있는 것: 두 영역 모두 공식이 밝힌 자연어 프로그래밍 가능 범위 안이다. 구체적 도구 이름과 매개변수는 근거에 없으므로 클라이언트에 실제로 나타나는 도구 목록을 기준으로 삼아라. 확신이 없으면 테스트 프로젝트에서 먼저 돌려보고 본 프로젝트로 돌아가라.
사례 2: YAML 플로 엔진으로 다단계 워크플로 실행하기. 한 문장 지시로는 부족하고 에디터 작업의 고정된 연쇄가 필요할 때는 내장 YAML 플로 엔진으로 다단계 흐름을 기술해 서버에 실행시킬 수 있다. 확인되는 것: 이 엔진이 존재하고 다단계 워크플로용이라는 점. YAML의 구체적인 형식과 예시는 근거에 없으므로 시작 전에 공식 문서를 확인하라. 흐름이 써지지 않을 때는 먼저 한 문장씩 지시로 검증한 뒤 흐름으로 묶어라.
사용 경계
읽기/쓰기 성격: 공식적으로 부여되는 것은 읽기/쓰기 접근이지 읽기 전용 서비스가 아니며, 되돌리는 수단도 제공되지 않는다. 쓰기 작업을 되돌릴 수 있다고 가정하지 마라. AI에게 맡기기 전에 프로젝트의 무엇을 바꿀지 먼저 확인하라. 로컬 영향: 설치하면 프로젝트 안에 C++ 브리지 플러그인이 배포되고 UE 플러그인이 활성화된다. 실행 시 클라이언트는 stdio로 서버에 접속하고, 서버는 WebSocket JSON-RPC로 에디터 안의 플러그인에 접속한다. 어떤 카테고리를 켤지는 설정 단계에서 직접 정하는 것이므로 당장 쓰지 않는 카테고리는 꺼 두면 노출면이 그만큼 줄어든다. 외부 네트워크 접근 여부, 텔레메트리나 데이터 수집, 자격 증명 필요 여부, 같은 프로젝트에 여러 클라이언트가 동시에 접속할 때의 동작은 어느 것도 근거에 설명이 없어 확인되지 않았다. 설명을 찾지 못했다고 위험이 없다고 여기지 말고, 이 경계를 쓸 모든 사람에게 미리 공유하라.