design-os-3d-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.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| blender_runtime_statusA | Inspect the host environment for Blender 5.2 availability, OS, and knowledge readiness. Returns: JSON string describing Blender binary availability, paths, and status. |
| query_blender_knowledgeA | Query the verified bpy 5.2 knowledge base for modeling, shading, modifiers, and gate rules. Args: query: Search keywords (e.g., 'bevel modifier', 'pbr shader', 'watertight mesh', 'cycloid drive'). topic: Optional topic filter (e.g., '00-foundations', '10-modeling', '20-shading', '60-pipeline'). Returns: JSON string containing matching knowledge entries, guidelines, and code snippets. |
| validate_part_specA | Validate a 3D part specification (spec.json) against design:os requirements. Args: spec_path: Path to the part specification JSON file. Returns: JSON string containing validation status, errors, and checked dimensions. |
| execute_blender_passA | Execute a bpy Python script in headless Blender and verify the AGENT_OK sentinel contract. Args: script_path: Path to the Python script to execute inside Blender. blend_path: Optional path to an existing .blend file to open. Returns: JSON string containing execution returncode, stdout snippet, and AGENT_OK / AGENT_FAIL sentinel. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| design_parametric_part | Prompt template for designing a parametric 3D mechanical part in Blender 5.2. Args: part_name: Name or slug of the part to design (e.g., 'bracket-m3'). purpose: Deliverable purpose: 'render-only', 'print', or 'both'. |
| review_geometry_gate | Prompt template for reviewing a 3D print gate report. Args: part_slug: Slug of the part build (e.g., 'bracket-m3'). |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| get_knowledge_index | Resource listing the verified bpy 5.2 knowledge base chapters and modules. |
| get_bracket_example_spec | Resource returning reference bracket-m3.spec.json specification. |
TDQS
Scored across 4 tools
Each tool targets a clearly different part of the pipeline: environment inspection, script execution, knowledge lookup, and spec validation. There is no practical overlap, and descriptions make the boundaries explicit (e.g., execute vs. validate operate on scripts vs. specs).
Three tools follow a clean verb_noun pattern (execute_blender_pass, query_blender_knowledge, validate_part_spec) with a shared snake_case convention. blender_runtime_status is a noun-phrase status probe rather than an action verb, a minor but noticeable deviation from the otherwise predictable pattern.
Four tools is on the lean side but each maps to a distinct stage of the headless Blender workflow. Nothing feels redundant or padded, though the surface is minimal enough that a slightly richer set would be expected for the stated scope.
The core loop is covered: check the environment, consult the knowledge base, run bpy scripts, and validate output specs. Minor gaps exist — there is no tool to author or repair a spec, enumerate knowledge topics, or inspect/render resulting assets beyond the AGENT_OK sentinel — but agents can work around these via script execution.