IvanMurzak/Unity-MCP

tests-run reports TotalTests as the size of the entire test tree for the given testMode, ignoring testAssembly / testNamespace / testClass / testMethod. PassedTests / FailedTests / SkippedTests count only executed tests, so the summary is internally inconsistent whenever a filter is set. Repro Unity 6000.3.5f1, com.ivanmurzak.unity.mcp 0.87.0. Project has 941 tests in EditModeTests.dll. tests-run { testMode: EditMode, testAssembly: "EditModeTests", testClass: "SongPipelineCacheTests" } → { Status: "Passed", TotalTests: 942, PassedTests: 1, FailedTests: 0, SkippedTests: 0 } One test ran, but TotalTests reports the whole EditMode tree (941 project tests + 1 stub from com.unity.addressables). The same 942 appears for an unfiltered run, a single-assembly run, and this single-class run — the value is constant regardless of filter. Cause TestResultCollector.RunFinished — Editor/Scripts/API/Tool/Tests/TestResultCollector.cs:105: _summary.TotalTests = CountTests(result.Test); result.Tes

Environment Package: com.ivanmurzak.unity.mcp v0.82.3 (latest, registry source) Unity: 6000.3.8f1 OS: Windows 11 Reproduces consistently in an actively-running Editor session (game in Play Mode / logging happening), intermittently otherwise Summary Calling the Console / Clear Logs MCP tool (console-clear-logs) intermittently fails with: Tool execution failed for 'Console / Clear Logs': One or more errors occurred. (The process cannot access the file 'Temp\mcp-server\ai-editor-logs.txt' because it is being used by another process.) This happens repeatedly across sessions whenever any Unity log message is emitted around the same time as a Clear Logs call. Root cause Console.ClearLogs.cs marshals to the main thread and runs Debug.ClearDeveloperConsole() then logCollector.Clear(). FileLogStorage.Clear() (and the BufferedFileLogStorage override) do: lock (_fileMutex) { fileWriteStream?.Dispose(); fileWriteStream = null; if (File.Exists(filePath)) File.Delete(filePath); // <-- fails here i

Summary Add a CI matrix entry for Unity 6.5 so the Unity-MCP plugin is validated against that editor version on every PR/release, alongside the currently covered versions (2022.3.62f3, 2023.2.22f1, 6000.3.1f1). Status: Blocked This issue is blocked until game-ci publishes a unityci/editor Docker image for Unity 6.5. Our CI runs Unity inside a container on ubuntu-latest, so without a prebuilt image there is no supported way to execute editor tests headlessly. Track availability of new tags here: Docker Hub tags page: https://hub.docker.com/r/unityci/editor/tags Filter by Unity version, e.g. https://hub.docker.com/r/unityci/editor/tags?name=6500 game-ci docker source: https://github.com/game-ci/docker Implementation Once a unityci/editor:ubuntu-6500.<x>.<y>f<z>-base-3 (and -windows-mono-3) tag exists, the change is mechanical and follows the existing pattern in .github/workflows/test_pull_request.yml. 1. Add a Unity-Tests/<unity-6.5-version> project Create a sibling Unity project to Un

Summary Follow-up to #703 / #705. Even with the Install()-time stale-version cleanup landed, upgrading com.ivanmurzak.unity.mcp in a third-party Unity project still leaves the project broken: the NuGet resolver never runs after the upgrade, so the stale <Id>.<oldVersion>/ directory is never cleaned up and the new code never compiles. The reason: the resolver is wired through [InitializeOnLoad], which Unity only invokes after a successful project-wide recompilation. The package upgrade itself introduces compile errors (new plugin code references newer APIs of a NuGet dep — e.g. ReflectorNet — but the old DLL is still on disk), Unity refuses to reload the domain, and the new NuGetDependencyResolver static constructor is never executed. The previously-loaded resolver instance from the last successful reload is still alive in the editor's AppDomain, but its EditorApplication.update += ResolveOnce handler already fired, unsubscribed itself, and ran exactly once. So nothing in the runnin

MCP protocol supports authorization. Need to implement it properly by providing metadata with proper URL to the server based on the current configuration (custom / cloud). Should only be supported with HTTP transport