• Introduce BlenderCommandError exception to distinguish addon errors from transport failures
• Addon-reported errors no longer wrapped as communication errors, socket preserved
• execute_blender_code returns cleaner "Blender Python error" message without duplicate prefixes
• Other tools inherit improved error messages through existing generic exception handlers

Distinguish addon errors from transport failures

• Added new BlenderCommandError exception class for addon-reported errors
• Modified send_command to raise BlenderCommandError instead of generic Exception when addon
 returns error status, and re-raise it without wrapping to preserve socket
• Updated execute_blender_code to catch BlenderCommandError separately and return "Blender
 Python error" message with addon's duplicate prefix stripped
• Changed generic exception handler in execute_blender_code to return "Communication error" for
 true transport failures

src/blender_mcp/server.py

Walkthrough

Added a new BlenderCommandError exception type to distinguish Blender addon failures from communication errors. Updated error handling in BlenderConnection.send_command to re-raise this exception unchanged, and modified execute_blender_code to handle the two error types separately with distinct logging levels and user-facing messages.

Changes

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Poem

🐰 Errors now wear their names with pride,
BlenderCommand ones clearly unteide,
While comms mistakes find their own way,
Each handled just right, hip hooray! ✨

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

• X
• Mastodon
• Reddit
• LinkedIn

Description

execute_blender_code prefixes all non-BlenderCommandError exceptions with "Communication error: ",
but send_command already formats many transport failures (e.g., "Connection to Blender lost: ..." or
"Communication error with Blender: ..."), resulting in noisy nested messages and output that may not
match the PR’s intended format.

Code

src/blender_mcp/server.py[R369-371]

    except Exception as e:
-        logger.error(f"Error executing code: {str(e)}")
-        return f"Error executing code: {str(e)}"
+        logger.error(f"Communication error executing code: {str(e)}")
+        return f"Communication error: {str(e)}"

Evidence

execute_blender_code adds a top-level "Communication error:" wrapper for any Exception. send_command
already wraps connection/transport failures with its own prefixes before re-raising, so the final
returned string can include multiple layers of framing (e.g., "Communication error: Connection to
Blender lost: ...").

src/blender_mcp/server.py[163-184]
src/blender_mcp/server.py[345-371]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`execute_blender_code` returns `Communication error: {e}` for all non-`BlenderCommandError` exceptions, but `BlenderConnection.send_command` already raises transport-related exceptions with pre-framed messages (e.g., `Connection to Blender lost: ...`, `Communication error with Blender: ...`). This can create nested/noisy messages and makes it harder to match the intended output format.

### Issue Context
The PR’s goal is clearer error categorization. To keep messaging consistent, either transport errors should be raised as typed exceptions (without embedded prefixes) and formatted at the boundary, or the boundary should avoid re-prefixing already-framed messages.

### Fix Focus Areas
- src/blender_mcp/server.py[163-184]
- src/blender_mcp/server.py[345-371]

### Suggested approach
- Option A (cleanest): introduce a `BlenderTransportError` (or reuse `ConnectionError`) and have `send_command` raise that *without* embedding `Communication error with Blender:` in the message; then `execute_blender_code` formats `Communication error: {raw}`.
- Option B: in `execute_blender_code`, strip known transport prefixes (`Communication error with Blender: `, `Connection to Blender lost: `) before adding `Communication error: `.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

execute_blender_code treats every BlenderCommandError as a "Blender Python error", but
BlenderCommandError is raised for any addon status:"error" response, including non-user-code
failures like "Unknown command type", which can mislead users about the root cause.

Code

src/blender_mcp/server.py[R359-368]

+    except BlenderCommandError as e:
+        # A Python exception inside the executed code round-tripped cleanly.
+        # The addon prefixes these with "Code execution error: "; strip it so
+        # the user sees the underlying exception without two layers of framing.
+        msg = str(e)
+        prefix = "Code execution error: "
+        if msg.startswith(prefix):
+            msg = msg[len(prefix):]
+        logger.info(f"Blender Python error: {msg}")
+        return f"Blender Python error: {msg}"

Evidence

send_command raises BlenderCommandError for all addon error statuses, regardless of cause. The addon
can emit status:"error" for protocol/command failures (e.g., unknown command), so
execute_blender_code’s fixed "Blender Python error" label is not always semantically correct for
this exception type.

src/blender_mcp/server.py[126-163]
src/blender_mcp/server.py[345-368]
addon.py[255-268]
addon.py[421-436]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`execute_blender_code` currently assumes `BlenderCommandError` always represents a user-code Python exception and returns `Blender Python error: ...`. But `BlenderCommandError` is thrown for any addon `status:error`, including protocol-level errors like `Unknown command type`.

### Issue Context
The addon uses the same `status:error` envelope for multiple kinds of failures. The server-side wording should not be narrower than what the exception actually represents.

### Fix Focus Areas
- src/blender_mcp/server.py[126-163]
- src/blender_mcp/server.py[345-368]
- addon.py[255-268]

### Suggested approach
- In `execute_blender_code`, only label as `Blender Python error:` when the message starts with `Code execution error: ` (the known execute_code exception prefix). Otherwise, return something like `Blender addon error: {msg}` (or `Blender command error: {msg}`) to keep semantics correct even under version/protocol mismatches.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools