Unity Code MCP Server 0.4 Release Changes

✨ What’s New for You?

The 0.4 release focuses on making Unity-agent workflows simpler to connect, easier to observe, and more reliable during Play Mode and test automation. If you want the broader product overview, see the Unity Code MCP Server product page.

• Simpler connection to Unity: The bundled STDIO bridge now talks to Unity through a file-backed transport in .unityCodeMcpServer/messages, so you no longer need to manage TCP ports for the standard setup.
• New Game View screenshot tool: A dedicated get_unity_game_view_window_screenshot tool lets agents capture the current Game View on demand without piggybacking on gameplay input calls.
• More reliable Play Mode automation: play_unity_game now has tighter argument validation, better background execution handling, and smarter Input System asset resolution.
• Clearer diagnostics when things go wrong: Unity logs are more structured, and both the Unity side and the STDIO bridge now emit stronger diagnostics for transport and request failures.
• Safer automated runs: Test execution and request handling were tightened so Unity is less likely to process requests at the wrong time or leave stale transport files behind.

---

⚠️ Breaking Changes & Migration

This release changes how external clients connect to Unity.

• STDIO transport changed: The Python bridge no longer forwards requests over TCP. It now exchanges request and response files through .unityCodeMcpServer/messages in the Unity project root.
• Older server-style configs should be removed: If your MCP client was configured for TCP or the earlier HTTP server flow, switch to the bundled unity-code-mcp-stdio bridge configuration described in the current README and release materials.
• The default documented path is now the file-backed bridge: For 0.4, the standard setup is the bundled STDIO bridge rather than a standalone HTTP or TCP server path.

For the full packaged release and upgrade context, see the v0.4 GitHub release.

---

🚀 Key Improvements

📡 Transport and Setup

• File-backed Unity transport: Requests are written to disk, Unity claims and deletes request files as it starts processing them, and the bridge waits only for the matching response file.
• Cleaner bridge behavior: The STDIO bridge now uses request timeouts instead of retry-based socket connection settings, which makes failures easier to reason about.
• Refined setup guidance: The repo guidance and settings flow were updated so agents and users follow the current Unity workflow more consistently.

🕹 Play Mode and Testing

• Dedicated screenshot capture: get_unity_game_view_window_screenshot is now a first-class tool with Edit Mode and Play Mode coverage.
• Smarter input asset lookup: play_unity_game resolves the InputActionAsset from settings on each call and falls back more gracefully when no explicit path is configured.
• More defensive automation flow: Play Mode operations and Unity test execution perform stronger validation around active test runs and editor state.

📊 Diagnostics and Configuration

• Structured Unity console output: Console log reads now include richer metadata such as severity, making automated troubleshooting easier.
• Centralized logging: Unity-side logging was consolidated and expanded, with better context around server startup, transport activity, and failures.
• Settings UX improvements: The server settings editor was refined, including better assembly selection and clearer configuration behavior.