ViperMesh for Blender
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
ViperMesh for Blender uses one persistent MCP server process per agent session. Do not launch npm, npx, tsx, or another MCP subprocess for individual Blender operations. Call bootstrap_vipermesh_session once before the first Blender mutation. Inspect the scene before editing, prefer deterministic Blender tools, group only already-decided operations, and retain execute_code for genuinely custom work. Choose task-appropriate inspection and repair points. Validate requested relationships and inspect the actual output before accepting it; file-health checks do not judge appearance. Save only requested artifacts to approved paths.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| bootstrap_vipermesh_sessionA | Call once at session start. Checks Blender and returns compact operating context plus the recommended next calls for one persistent MCP session. |
| check_blender_connectionA | Check whether the local ViperMesh Blender addon is responding on its configured loopback socket. |
| list_blender_toolsC | List Blender commands available through the trusted local portable gateway, including execute_code for fallback measurement. |
| call_blender_toolC | Call one approved ViperMesh Blender command with structured parameters. |
| call_blender_tool_batchB | Run an ordered bounded sequence of approved ViperMesh Blender commands through one persistent session. Use only when intermediate observations are not needed to choose the next command. |
| run_blender_scene_stageC | Run one compact scene-workflow stage over the persistent Blender session. Use build, inspect_preview, and finalize as separate decision points; standalone tools remain available for repairs and unusual work. |
| get_blender_agent_contextC | Load the public compact ViperMesh operating rules for persistent Blender MCP sessions. |
| search_3d_guidanceC | Search checked-in ViperMesh 3D tool skills and optionally the configured semantic guidance store. |
| get_3d_guidance_documentB | Read one approved Markdown reference from the checked-in ViperMesh agent skill. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| vipermesh-connector-manual | Persistent-session setup, tool selection, workflow, and acceptance guidance. |
| vipermesh-operating-context | Compact operating rules for an agent using the connector. |
TDQS
Scored across 9 tools
Most tools have clearly distinct roles: connection checking, tool listing, single calls, batch calls, scene staging, and guidance retrieval. There is some overlap between bootstrap_vipermesh_session, check_blender_connection, and get_blender_agent_context because bootstrap combines connection checking and context loading, but the descriptions clarify when each should be used.
All tool names use consistent snake_case and follow a verb_noun pattern such as check_blender_connection, call_blender_tool, and get_3d_guidance_document. Domain-specific terms like blender and 3d are applied predictably across the set.
Nine tools is well-scoped for a Blender MCP gateway that needs session setup, connection checking, tool discovery, command execution, batching, scene staging, and guidance access. Each tool appears to earn its place without excessive surface area.
The surface covers the main lifecycle: session bootstrap, connection verification, tool discovery, single and batch command execution, scene workflow staging, and guidance lookup. Minor gaps exist, such as no explicit session teardown or direct tool-schema introspection, but the generic call path can likely work around them.