Can't get blender mcp to work no matter what I do

Summary Blender addon accepts the incoming connection from the MCP server, but never receives/executes any command. Every tool call times out (~4 min) with no error on either side. This happens consistently across multiple different configurations, ruling out most common causes.

Environment

• OS: Windows 11
• Blender version: 5.1.1
• Python (pinned via uv): 3.11
• uv: latest, installed via official PowerShell installer
• Client: Claude Desktop

Symptom Blender's system console shows:

Connected to client: ('127.0.0.1', <port>)
Client handler started

...and then nothing further. No error, no traceback, no "Executing handler for..." message. The client-side request eventually times out (Claude Desktop shows: "No result received... Ensure Blender is running with the MCP addon enabled and the server started"). Blender itself remains fully responsive throughout — it is not a frozen main thread.

What I've already ruled out

1. A separate untrusted/impersonating extension (from an unofficial "blender-mcp.com" site) was found installed and removed — not the cause, since the issue persists with only the official addon installed.
2. Reinstalled addon.py fresh from the official GitHub repo (raw.githubusercontent.com/ahujasid/blender-mcp/main/addon.py) — same symptom.
3. Used the official uvx blender-mcp install-addon installer to guarantee matching addon/server versions — same symptom.
4. Antivirus (Windows Defender + checked for third-party AV) — no flags, no quarantine events during test windows.
5. Pinned Python to 3.11 via uvx --python 3.11 blender-mcp and UV_PYTHON_PREFERENCE=only-managed, since uv was otherwise picking up a local Python 3.13 install — same symptom.
6. Pre-cached uv's environment manually (uvx --python 3.11 blender-mcp --help) to rule out first-run dependency downloads exceeding the client's handshake timeout — same symptom.
7. Forced BLENDER_HOST=127.0.0.1 explicitly instead of localhost, to rule out an IPv6/IPv4 loopback resolution mismatch — same symptom.
8. Confirmed via netstat -ano | findstr 9876 that only a single process (blender.exe) is listening on the port — no port conflict.
9. Validated claude_desktop_config.json JSON syntax — valid, matches documented format.

Current claude_desktop_config.json

{
  "mcpServers": {
    "blender": {
      "command": "uvx",
      "args": ["--python", "3.11", "blender-mcp"],
      "env": {
        "UV_PYTHON_PREFERENCE": "only-managed",
        "BLENDER_HOST": "127.0.0.1"
      }
    }
  }
}

Possible lead I noticed the project's README (main branch) mentions the TCP link uses length-prefixed JSON frames, but the addon.py I installed (both from the release zip and freshly re-fetched from GitHub) parses incoming data with a plain json.loads() on the accumulated buffer, with no length-prefix handling. If the current PyPI blender-mcp server package sends length-prefixed frames while this addon.py expects raw JSON only, that would explain the exact symptom: the connection is accepted, but the addon can never successfully parse what it receives, and simply waits forever. Wondering if this is a known addon/server version mismatch issue, or if I'm missing an install step that would give me a length-prefix-aware addon.py.