Unity MCP setup

Editor bridge سمجھیں

CoplayDev/unity-mcp MCP client کو server اور editor-side package سے connect کرتا ہے۔ Model service الگ dependency ہے۔ Project scenes، scripts، assets اور tests کے tools document کرتا ہے، مگر listed capability آپ کے project میں کام کرنے کا evidence نہیں۔

Record کریں کہ connection کے ہر حصے کا مالک کون سا process ہے۔ Client server تک پہنچ سکے مگر editor operate نہ کر سکے تو diagnosis میں یہ فرق اہم ہے۔ Account credentials، editor licensing، package compatibility اور model availability الگ setup checks رکھیں۔ Model بدلنے سے editor-instance mismatch ٹھیک نہیں ہوتا۔

Installation path اور pinning policy review کریں

Project installation guide Unity Package Manager کے ذریعے package add کرنے اور setup interface سے server اور client configure کرنے کا طریقہ document کرتی ہے۔ منتخب revision کے لیے Unity، Python اور uv prerequisites install کرنے سے پہلے review کریں۔

Reproducibility کے لیے resolved package revision، editor version، server version اور dependency records محفوظ کریں۔ Moving branch URL discovery path ہے، immutable experiment identity نہیں۔ Existing game میں downloads اور package changes review کریں اور previous working project state رکھیں تاکہ connection experiment reversible رہے۔

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

Local HTTP endpoint کو client کے ساتھ match کریں

Maintained installation guide نیچے والا local HTTP example document کرتی ہے اور فرض کرتی ہے کہ server اسی address پر چل رہا ہے۔ استعمال سے پہلے editor setup interface میں actual transport اور address confirm کریں۔ MCP URL LLM API base URL نہیں ہے۔

اپنے client کا documented configuration format استعمال کریں۔ Clients کے root keys یا transport declarations مختلف ہو سکتے ہیں، اس لیے generic mcpServers example ہر agent میں paste کرنے والی universal file نہیں۔ Server کو local رکھیں جب تک separately reviewed remote setup درکار نہ ہو، اور غیر متعلق editor connection میں model credentials شامل نہ کریں۔

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

ثابت کریں کہ work کس editor instance کو مل رہی ہے

Intended project کھولیں اور package interface سے connection state inspect کریں۔ پھر client کے discovered read operations سے project اور scene context حاصل کریں۔ Edit approve کرنے سے پہلے اسے local project سے match کریں۔ Multiple open projects میں یہ gate خاص طور پر اہم ہے۔

Installed version کے actual resources اور tool schemas record کریں۔ کسی دوسری release سے یاد tool name کی بنیاد پر call invent نہ کریں۔ مفید پہلا result expected scene اور existing objects کو بغیر change کے identify کرتا ہے۔ Returned state stale یا ambiguous ہو تو visible mutation آزمانے کے بجائے routing resolve کریں۔

First miniflow کے لیے reversible edit استعمال کریں

Owned disposable scene چنیں، initial state record کریں اور visible consequence والی ایک simple change مانگیں۔ Saved scene اور file diff inspect کریں، editor ready ہونے کا انتظار کریں اور scene exercise کریں۔ Observed behavior اور console errors محفوظ کریں۔

پھر scene reopen کر کے intended change persist ہونے کی تصدیق کریں۔ اس سے in-memory effect اور saved project change میں فرق معلوم ہوتا ہے۔ Flow کو routing، mutation، compilation، execution یا persistence کی ایک boundary پر failure diagnose کرنے کے لیے چھوٹا رکھیں۔ Review کے بعد disposable scene restore کریں اور اگلی task کے لیے working configuration استعمال کریں۔

Game سے پہلے transport troubleshoot کریں

Client connect نہ کرے تو configured URL اور local server running ہے یا نہیں verify کریں۔ Server start ہو مگر editor absent ہو تو package connection اور editor logs inspect کریں۔ Intended editor connected ہو مگر tool missing ہو تو installed version کے exposed tool groups دیکھیں۔

اس boundary کے کام کرنے کے بعد ہی compilation یا gameplay diagnose کریں۔ Client startup، server routing، editor readiness اور failed scene action کے log excerpts الگ رکھیں۔ اس سے report میں execution رکنے کی جگہ واضح ہوگی، ہر failure model پر ڈالنے یا evidence کے بغیر components reinstall کرنے کی ضرورت نہیں۔

Project کو broad automation سے محفوظ رکھیں

Editor connection scenes، scripts اور assets بدل سکتی ہے۔ Initial experiment کو known directory تک محدود رکھیں اور resources delete، dependencies بدلنے یا unrelated scenes touch کرنے والی operations کے لیے review لازم کریں۔ First change سے پہلے recoverable working state رکھیں۔

Client configuration issue حل کرنے کے لیے local development service public نہ کریں۔ Third-party asset content اور tool results کو untrusted input سمجھیں اور shared logs سے credentials نکال دیں۔ Successful connection builds upload یا store records modify کرنے کی permission نہیں۔ Publishing الگ workflow اور الگ authorization boundary ہے۔

Reproducible connection record handoff کریں

Editor، project، package اور server revisions، client version، transport، observed tool surface اور completed miniflow record کریں۔ Exact scene diff اور runtime result ساتھ رکھیں۔ واضح کریں کہ compilation، PlayMode behavior، tests اور target export check ہوئے ہیں یا pending ہیں۔

یہ configuration maintained project documentation follow کرتی ہے؛ اپنے installed package اور client کے خلاف verify کریں۔ Game production کے لیے Unity workflow guide پر جائیں اور complete loop test کریں۔ Known limitations handoff میں رکھیں تاکہ دوسرا developer connection issue اور project problem الگ کر سکے اور یہی working setup reproduce کرے۔

عمومی سوالات