Issues setting component references using the MCP
Closed this issue · 4 comments
After this tool call was made the following log entry was observed
[ManageGameObject] Could not set property 'enemySpawnPoints' on component 'WaveManager' ('WaveManager'). Property might not exist, be read-only, or type mismatch.
UnityEngine.Debug:LogWarning (object)
UnityMcpBridge.Editor.Tools.ManageGameObject:SetComponentPropertiesInternal (UnityEngine.GameObject,string,Newtonsoft.Json.Linq.JObject,UnityEngine.Component) (at ./Library/PackageCache/com.coplaydev.unity-mcp@cb7fadb13779/Editor/Tools/ManageGameObject.cs:1487)
UnityMcpBridge.Editor.Tools.ManageGameObject:SetComponentPropertyOnTarget (Newtonsoft.Json.Linq.JObject,Newtonsoft.Json.Linq.JToken,string) (at ./Library/PackageCache/com.coplaydev.unity-mcp@cb7fadb13779/Editor/Tools/ManageGameObject.cs:1086)
UnityMcpBridge.Editor.Tools.ManageGameObject:HandleCommand (Newtonsoft.Json.Linq.JObject) (at ./Library/PackageCache/com.coplaydev.unity-mcp@cb7fadb13779/Editor/Tools/ManageGameObject.cs:142)
UnityMcpBridge.Editor.UnityMcpBridge:ExecuteCommand (UnityMcpBridge.Editor.Models.Command) (at ./Library/PackageCache/com.coplaydev.unity-mcp@cb7fadb13779/Editor/UnityMcpBridge.cs:630)
UnityMcpBridge.Editor.UnityMcpBridge:ProcessCommands () (at ./Library/PackageCache/com.coplaydev.unity-mcp@cb7fadb13779/Editor/UnityMcpBridge.cs:533)
UnityEditor.EditorApplication:Internal_CallUpdateFunctions ()
So the log entry is a warning?, the MCP thinks the operation was successful but the game object reference was not set the script in the inspector.
If you need more examples let me know.
Glenn
@ibytergj can you give a screenshot of the component? And say a bit more about what operations you want to do on it? Is it hook up (arrays of) game objects to serialized fields?
Adding to this for when we improve manage_gameobject behavior and robustness. (See user bug report here: )
Fix description:
The failure to add a custom component with manage_gameobject (e.g., "ExplosiveFireCube") and the error “Could not load the file 'Assembly-CSharp'” happens because our add‑component path assumes the type lives in Assembly-CSharp and/or resolves by short name. That breaks in three common cases: (1) scripts are compiling, (2) the component is in a different assembly due to asmdefs, or (3) the type is namespaced and we only pass the short name.
Proposed hardening: replace any Assembly.Load("Assembly-CSharp")/GetType logic with an assembly‑agnostic resolver that uses TypeCache.GetTypesDerivedFrom<Component>() to find matches by fully qualified name or short name, with an AppDomain scan as a fallback. Also accept a guid:<MonoScriptGUID> form and map GUID → MonoScript.GetClass() to avoid name collisions. This lets callers use any of:
components_to_add: ["MyGame.Play.ExplosiveFireCube"]components_to_add: ["ExplosiveFireCube"](resolver expands)components_to_add: ["guid:<GUID>"]
Gate the operation during compilation: if EditorApplication.isCompiling (or we just compiled with errors), short‑circuit with a clear, actionable message instead of attempting reflection. When a type still can’t be found, return a precise error plus a few suggestions gathered from TypeCache (e.g., “Did you mean MyGame.Play.ExplosiveFireCube?”). Or us similar debounce / retry functionality we have in other tools).
Implementation notes: add via Undo.AddComponent and record prefab changes (PrefabUtility.RecordPrefabInstancePropertyModifications), marking the scene dirty when in Prefab Stage. For property writes like materials, default to sharedMaterial unless the caller explicitly requests an instance. Minimal tests: (a) add succeeds when the component is in Assembly-CSharp and when it’s in an asmdef/namespace; (b) add during active compile returns the compile‑gate message; (c) “type not found” response includes suggested fully qualified names and accepts guid: tokens.
This should work better in latest release. Please give it a try and let us know.

