Setup Unity MCP

Capisci il bridge dell'editor

CoplayDev/unity-mcp collega un client MCP a un server e a un pacchetto lato editor. Il servizio modello è una dipendenza separata. Il progetto documenta strumenti per scene, script, asset e test, ma una capacità elencata non dimostra che funzioni nel tuo progetto.

Registra quale processo possiede ogni parte della connessione. È importante quando un client raggiunge il server ma non può operare sull'editor. Mantieni come controlli separati credenziali dell'account, licenza dell'editor, compatibilità del pacchetto e disponibilità del modello. Cambiare modello non ripara un mismatch dell'istanza editor.

Rivedi percorso d'installazione e policy di pinning

La guida d'installazione del progetto documenta l'aggiunta del pacchetto tramite Unity Package Manager e l'uso dell'interfaccia di setup per configurare server e client. Rivedi i prerequisiti Unity, Python e uv dichiarati per la revisione scelta prima di installare qualsiasi cosa.

Per la riproducibilità, conserva revisione risolta del pacchetto, versione editor, versione server e record delle dipendenze dopo il setup. Un URL verso un branch mobile è un percorso di discovery, non un'identità immutabile dell'esperimento. Rivedi download e modifiche ai pacchetti prima di applicarli a un gioco esistente e conserva lo stato funzionante precedente perché l'esperimento resti reversibile.

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

Abbina l'endpoint HTTP locale al client

La guida d'installazione mantenuta documenta l'esempio HTTP locale seguente e presuppone che il server sia già in esecuzione a quell'indirizzo. Conferma trasporto e indirizzo configurati nell'interfaccia di setup dell'editor prima di usarli. L'URL MCP non è una base URL API LLM.

Usa il formato di configurazione documentato dal tuo client. Alcuni client usano chiavi root o dichiarazioni di trasporto diverse, quindi l'esempio generico mcpServers non è un file universale da incollare in ogni agente. Mantieni locale il server salvo un setup remoto revisionato separatamente e non aggiungere credenziali modello a una connessione editor non pertinente.

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

Dimostra quale istanza editor riceve il lavoro

Apri il progetto previsto e ispeziona lo stato della connessione tramite l'interfaccia del pacchetto. Poi usa le operazioni di lettura scoperte dal client per ottenere contesto di progetto e scena. Confronta queste informazioni con il progetto locale prima di approvare una modifica. Più progetti aperti rendono questo gate particolarmente importante.

Registra risorse reali e schemi degli strumenti della versione installata. Non inventare una chiamata a uno strumento da un nome ricordato di un'altra release. Un buon primo risultato identifica la scena attesa e gli oggetti esistenti senza cambiarli. Se lo stato restituito è obsoleto o ambiguo, fermati e risolvi il routing invece di eseguire una mutazione visibile per scoprire il target.

Usa un edit reversibile come primo miniflow

Scegli una scena usa-e-getta di tua proprietà, registra lo stato iniziale e chiedi una modifica semplice con conseguenza visibile. Ispeziona scena salvata e diff, aspetta che l'editor sia pronto ed esegui la scena. Conserva comportamento osservato ed eventuali errori di console.

Riapri poi la scena per confermare la persistenza della modifica. Questo distingue un effetto in memoria dell'editor da una modifica salvata. Mantieni il flusso abbastanza piccolo da diagnosticare il guasto a un solo confine: routing, mutazione, compilazione, esecuzione o persistenza. Ripristina la scena usa-e-getta dopo la revisione e usa la configurazione funzionante registrata per l'attività successiva.

Risolvi il trasporto prima del gioco

Quando il client non può connettersi, verifica URL configurato e stato del server locale. Quando il server parte ma l'editor è assente, controlla connessione del pacchetto e log dell'editor. Quando l'editor previsto è connesso ma manca uno strumento, ispeziona i gruppi esposti dalla versione installata.

Solo dopo aver superato quel confine diagnostica compilazione o gameplay. Mantieni separati gli estratti di log per avvio client, routing server, readiness dell'editor e azione di scena fallita. Così il report può spiegare dove si è fermata l'esecuzione invece di attribuire ogni errore al modello o reinstallare componenti senza prove.

Proteggi il progetto dall'automazione ampia

Una connessione editor può modificare scene, script e asset. Limita il primo esperimento a una directory nota e richiedi revisione per operazioni che eliminano risorse, alterano dipendenze o toccano scene non correlate. Conserva uno stato di lavoro recuperabile prima della prima modifica.

Non rendere pubblico un servizio di sviluppo locale solo per risolvere un problema di configurazione del client. Tratta contenuti di asset di terze parti e risultati degli strumenti come input non fidati e mantieni le credenziali fuori dai log condivisi. Una connessione riuscita non autorizza upload di build o modifiche ai record dello store. La pubblicazione resta un workflow separato con un confine di autorizzazione separato.

Consegna un record di connessione riproducibile

Registra revisioni di editor, progetto, pacchetto e server, versione del client, trasporto, superficie osservata degli strumenti e miniflow completato. Conserva il diff esatto della scena e il risultato runtime. Indica se compilazione, comportamento PlayMode, test ed export target sono stati esaminati o restano pendenti.

Questa configurazione segue la documentazione mantenuta del progetto; verificala rispetto a pacchetto e client installati. Per la produzione del gioco, passa alla guida del workflow Unity e testa il loop completo. Mantieni i limiti noti nella consegna, così un altro sviluppatore può distinguere un problema di connessione da un problema di progetto e riprodurre lo stesso setup funzionante.

Domande frequenti