* refactor: rename namespace from UnityMcpBridge to MCPForUnity across all files
See thread in #6, we can't use Unity MCP because it violates their trademark.
That name makes us look affiliated. We can use MCP for Unity
* Change package display name, menu item and menu titles
These are front facing so has to change for Unity asset store review
* Misc name changes in logs and comments for better consistency
* chore: update editor window title from 'MCP Editor' to 'MCP for Unity'
* refactor: update branding from UNITY-MCP to MCP-FOR-UNITY across all log messages and warnings
* chore: rename Unity MCP to MCP For Unity across all files and bump version to 2.1.2
* docs: update restore script title to clarify Unity MCP naming
* Fix usage instructions
* chore: update log messages to use MCP For Unity branding instead of UnityMCP
* Add a README inside plugin, required for distributing via the asset store
* docs: update Unity port description and fix typo in troubleshooting section
* Address Rabbit feedback
* Update Editor prefs to use new name
Prevents overlap with other Unity MCPs, happy to revert if it's too much
* refactor: rename server logger and identifier from unity-mcp-server to mcp-for-unity-server
* Standardize casing of renamed project to "MCP for Unity", as it is on the asset store
* Remove unused folder
* refactor: rename Unity MCP to MCP for Unity across codebase
* Update dangling references
* docs: update product name from UnityMCP to MCP for Unity in README
* Update log and comments for new name
This merge combines upstream's organizational rebrand and updates with
our comprehensive bridge stability improvements:
**From Upstream:**
- CoplayDev organizational rebrand (README, LICENSE, documentation)
- Updated logo and deployment scripts
- Python version pinning (.python-version file)
**From Our Branch (Preserved):**
- Comprehensive bridge stability improvements (threading, heartbeat, retries)
- Enhanced debugging and diagnostic features
- Embedded server installation approach (more reliable than git-based)
- Broader Python compatibility (>=3.10 vs >=3.12)
- Advanced port management with per-project persistence
- Auto-setup and connection reliability features
- Robust error handling and recovery mechanisms
**Key Technical Decisions:**
- Used our comprehensive UnityMcpBridge.cs (625 lines vs 473) with all stability features
- Maintained embedded server approach over upstream's git-based installer
- Preserved broader Python compatibility (>=3.10) for better accessibility
- Used our optimized connection settings and retry logic
- Kept our user-centric server installation approach (on-demand vs automatic)
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Two .bat files that could directly deploy and restore the current repo to the unity project and the llm project. With this the tools will be integrated easier.
Marcus Sanatan
David Sarno
Scriptwonder