Summary
Installing this plugin via UPM (Packages/manifest.json git URL) fails to compile on Unity 6 with a cascade of CS0103: The name 'X' does not exist in the current context errors. The same source tree compiles cleanly when embedded at Packages/com.anklebreaker.unity-mcp/. Root cause is three .cs.meta files that ship with obviously-hand-typed placeholder GUIDs rather than real random values; Unity's Asset DB tolerates them under Packages/ but silently skips the three .cs files during import when the plugin is resolved into Library/PackageCache/.
Environment
- Plugin version:
v2.27.0 (commit f40a5c7). Also reproduces on main tip.
- Unity:
6000.3.10f1 (macOS arm64, Darwin 25.4.0).
- Install path:
Packages/manifest.json →
"com.anklebreaker.unity-mcp": "https://github.com/AnkleBreaker-Studio/unity-mcp-plugin.git#v2.27.0"
- UMA not installed (no
UMA_INSTALLED scripting define set) — not relevant to this bug, confirmed below.
- Project: standard URP project, no asmdef overrides touching this package.
Reproduction
- Fresh Unity 6 project.
- Add the UPM entry above to
Packages/manifest.json.
- Open the project. UPM resolves to
Library/PackageCache/com.anklebreaker.unity-mcp@<sha>/.
- Wait for compilation.
Expected
Clean compile. The plugin appears in Package Manager → In Project as a Git source and the MCP bridge starts on port 7890.
Actual
8 compilation errors, all variants of "name does not exist" against classes defined inside the plugin itself:
Library/PackageCache/com.anklebreaker.unity-mcp@<sha>/Editor/MCPBridgeServer.cs(1196,28):
error CS0103: The name 'MCPPrefsCommands' does not exist in the current context
Library/PackageCache/com.anklebreaker.unity-mcp@<sha>/Editor/MCPBridgeServer.cs(1198,28): CS0103 MCPPrefsCommands
Library/PackageCache/com.anklebreaker.unity-mcp@<sha>/Editor/MCPBridgeServer.cs(1200,28): CS0103 MCPPrefsCommands
Library/PackageCache/com.anklebreaker.unity-mcp@<sha>/Editor/MCPBridgeServer.cs(1202,28): CS0103 MCPPrefsCommands
Library/PackageCache/com.anklebreaker.unity-mcp@<sha>/Editor/MCPBridgeServer.cs(1204,28): CS0103 MCPPrefsCommands
Library/PackageCache/com.anklebreaker.unity-mcp@<sha>/Editor/MCPBridgeServer.cs(1206,28): CS0103 MCPPrefsCommands
Library/PackageCache/com.anklebreaker.unity-mcp@<sha>/Editor/MCPBridgeServer.cs(1208,28): CS0103 MCPPrefsCommands
Library/PackageCache/com.anklebreaker.unity-mcp@<sha>/Editor/MCPSelfTest.cs(1043,30): CS0103 MCPPrefsCommands
(Same pattern also affects MCPConstraintCommands and MCPProfilerCommands in projects that exercise those call sites during import — all three share the same failure mode.)
Counter-evidence that the code itself is correct
All three affected classes compile and link correctly when the plugin is embedded at Packages/com.anklebreaker.unity-mcp/:
MCPPrefsCommands.cs is in namespace UnityMCP.Editor, same namespace as MCPBridgeServer and MCPSelfTest that reference it — no using statement needed.- All three are in
Editor/ which is governed by the single AnkleBreaker.UnityMCP.Editor.asmdef.
- Byte-for-byte the files are identical between embedded
Packages/... and resolved Library/PackageCache/...; diff -r shows zero content differences.
- The
#if UMA_INSTALLED block around MCPUMACommands calls is preprocessor-excluded when UMA is not installed, so it cannot be the source of these errors. (I initially suspected the UMA asmdef refs and built an asmdef-split fork branch to test; it produced the identical error, which ruled UMA out.)
Root cause
Three .meta files under Editor/ ship with non-random GUIDs:
Editor/MCPPrefsCommands.cs.meta guid: 8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f
Editor/MCPConstraintCommands.cs.meta guid: 3f6e7d8c9a1b2e5d4a6c8e9f0a2b3d5e
Editor/MCPProfilerCommands.cs.meta guid: 3f7a2c8e19d04b6d8e5c1a9f4b3d7e2a
The first one is a strictly-ascending sequence of hex byte pairs:
8c → 9d → 0e → 1f → 2a → 3b → 4c → 5d → 6e → 7f → 8a → 9b → 0c → 1d → 2e → 3f. The other two are less obvious but share the same characteristic: they contain only digits 0-9 a-f with a rolling pattern, no high-entropy bytes. They were clearly typed by hand (or emitted by a template) rather than generated by Unity's importer.
Every other .cs.meta file in the package — ~68 of them — has a proper random-looking GUID (e.g. 05020b5bfbfa4a8d9bd3fcd5f7d67100, 097e9cc7a597f33442bba4386d3ecaed, 436586a98b59274f1313f0891078ffe2). Only those three are anomalous. Confirmed by scanning the full tree at v2.27.0.
Why it only breaks under Library/PackageCache/
Unity 6's Asset Database appears to validate .meta GUIDs more strictly when importing a resolved UPM package (read-only Library/PackageCache/ tree) than when discovering an embedded package under Packages/. Under the embedded path, Unity accepts the placeholder GUIDs and indexes the .cs files normally; under the UPM path, Unity silently refuses to index those three specific files. Since the .cs files are never indexed, their types never make it into the compilation unit for AnkleBreaker.UnityMCP.Editor.asmdef, and every call site referencing them fails with CS0103.
I'm not 100% certain of the exact validator path inside Unity — the fix is empirical — but the differential is clear: same bytes, different install path, only the files with placeholder GUIDs fail.
Fix
Regenerate the three GUIDs with any proper randomness source. Shell one-liner per file:
Replace the three guid: lines in those three .meta files. No source code, asmdef, namespace, or API changes needed.
Safe because these classes are pure editor-side command handlers; no scene/prefab/ScriptableObject references target them by GUID (they're reached by CLR type name from MCPBridgeServer and MCPSelfTest, both in the same assembly).
Proposed PR
Will follow as a separate PR against main from BadranRaza:fix/placeholder-meta-guids. Verified by pointing a test project's manifest at that branch and observing the compile errors disappear in Library/PackageCache/.
Secondary observation (not blocking this issue)
While investigating, noticed the editor asmdef unconditionally references UMA_Core and UMA_Core_Editor:
"references": ["UnityEngine.TestRunner", "UnityEditor.TestRunner", "UMA_Core", "UMA_Core_Editor"]
This is harmless today — Unity emits warnings for unresolved references rather than errors, and the UMA-using code in MCPUMACommands.cs is already guarded by #if UMA_INSTALLED. But a cleaner pattern would be to move MCPUMACommands.cs into a child asmdef AnkleBreaker.UnityMCP.Editor.UMA.asmdef with "defineConstraints": ["UMA_INSTALLED"] and the UMA references scoped to that child. Happy to send as a separate PR if you'd like; keeping it out of the GUID fix to keep the diff minimal and surgical.
Summary
Installing this plugin via UPM (
Packages/manifest.jsongit URL) fails to compile on Unity 6 with a cascade ofCS0103: The name 'X' does not exist in the current contexterrors. The same source tree compiles cleanly when embedded atPackages/com.anklebreaker.unity-mcp/. Root cause is three.cs.metafiles that ship with obviously-hand-typed placeholder GUIDs rather than real random values; Unity's Asset DB tolerates them underPackages/but silently skips the three.csfiles during import when the plugin is resolved intoLibrary/PackageCache/.Environment
v2.27.0(commitf40a5c7). Also reproduces onmaintip.6000.3.10f1(macOS arm64, Darwin 25.4.0).Packages/manifest.json→UMA_INSTALLEDscripting define set) — not relevant to this bug, confirmed below.Reproduction
Packages/manifest.json.Library/PackageCache/com.anklebreaker.unity-mcp@<sha>/.Expected
Clean compile. The plugin appears in Package Manager → In Project as a Git source and the MCP bridge starts on port 7890.
Actual
8 compilation errors, all variants of "name does not exist" against classes defined inside the plugin itself:
(Same pattern also affects
MCPConstraintCommandsandMCPProfilerCommandsin projects that exercise those call sites during import — all three share the same failure mode.)Counter-evidence that the code itself is correct
All three affected classes compile and link correctly when the plugin is embedded at
Packages/com.anklebreaker.unity-mcp/:MCPPrefsCommands.csis in namespaceUnityMCP.Editor, same namespace asMCPBridgeServerandMCPSelfTestthat reference it — nousingstatement needed.Editor/which is governed by the singleAnkleBreaker.UnityMCP.Editor.asmdef.Packages/...and resolvedLibrary/PackageCache/...;diff -rshows zero content differences.#if UMA_INSTALLEDblock aroundMCPUMACommandscalls is preprocessor-excluded when UMA is not installed, so it cannot be the source of these errors. (I initially suspected the UMA asmdef refs and built an asmdef-split fork branch to test; it produced the identical error, which ruled UMA out.)Root cause
Three
.metafiles underEditor/ship with non-random GUIDs:The first one is a strictly-ascending sequence of hex byte pairs:
8c → 9d → 0e → 1f → 2a → 3b → 4c → 5d → 6e → 7f → 8a → 9b → 0c → 1d → 2e → 3f. The other two are less obvious but share the same characteristic: they contain only digits0-9 a-fwith a rolling pattern, no high-entropy bytes. They were clearly typed by hand (or emitted by a template) rather than generated by Unity's importer.Every other
.cs.metafile in the package — ~68 of them — has a proper random-looking GUID (e.g.05020b5bfbfa4a8d9bd3fcd5f7d67100,097e9cc7a597f33442bba4386d3ecaed,436586a98b59274f1313f0891078ffe2). Only those three are anomalous. Confirmed by scanning the full tree atv2.27.0.Why it only breaks under
Library/PackageCache/Unity 6's Asset Database appears to validate
.metaGUIDs more strictly when importing a resolved UPM package (read-onlyLibrary/PackageCache/tree) than when discovering an embedded package underPackages/. Under the embedded path, Unity accepts the placeholder GUIDs and indexes the.csfiles normally; under the UPM path, Unity silently refuses to index those three specific files. Since the.csfiles are never indexed, their types never make it into the compilation unit forAnkleBreaker.UnityMCP.Editor.asmdef, and every call site referencing them fails withCS0103.I'm not 100% certain of the exact validator path inside Unity — the fix is empirical — but the differential is clear: same bytes, different install path, only the files with placeholder GUIDs fail.
Fix
Regenerate the three GUIDs with any proper randomness source. Shell one-liner per file:
Replace the three
guid:lines in those three.metafiles. No source code, asmdef, namespace, or API changes needed.Safe because these classes are pure editor-side command handlers; no scene/prefab/ScriptableObject references target them by GUID (they're reached by CLR type name from
MCPBridgeServerandMCPSelfTest, both in the same assembly).Proposed PR
Will follow as a separate PR against
mainfromBadranRaza:fix/placeholder-meta-guids. Verified by pointing a test project's manifest at that branch and observing the compile errors disappear inLibrary/PackageCache/.Secondary observation (not blocking this issue)
While investigating, noticed the editor asmdef unconditionally references
UMA_CoreandUMA_Core_Editor:This is harmless today — Unity emits warnings for unresolved references rather than errors, and the UMA-using code in
MCPUMACommands.csis already guarded by#if UMA_INSTALLED. But a cleaner pattern would be to moveMCPUMACommands.csinto a child asmdefAnkleBreaker.UnityMCP.Editor.UMA.asmdefwith"defineConstraints": ["UMA_INSTALLED"]and the UMA references scoped to that child. Happy to send as a separate PR if you'd like; keeping it out of the GUID fix to keep the diff minimal and surgical.