prompt-to-scene
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PTS_BLENDER | Yes | Absolute path to the Blender executable (e.g., /Applications/Blender.app/Contents/MacOS/Blender on macOS, or the full path to blender.exe on Windows). | |
| PTS_UNITY_PROJECT | Yes | Absolute path to the Unity project directory. This selects the destination explicitly. |
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
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| inspect_targetC | Inspect Blender, Unity heartbeat, rendering pipeline and previous asset receipts. |
| build_assetA | Execute trusted bpy code in background Blender; save .blend and queue Unity import. Use stable asset_id (lowercase letters/digits/_/-) to update the same asset. Position is Unity XYZ meters, applied ONLY when first placing the asset. Each script builds a complete asset from scratch. Delete default scene objects, create an Export collection, link meshes to it. v0.1: static meshes, constant opaque PBR, direct base-color / tangent normal textures. Unsupported materials fail explicitly. No paid model API or additional Blender MCP required. |
| publish_blendA | Publish the Export collection of an existing saved .blend without modifying the original. Use this after another Blender tool has modeled and saved an asset. Same material contract and queued/result semantics as build_asset. Blender file auto-execution is disabled. |
| get_asset_statusC | Read Unity's receipt: request ID, asset paths, geometry, bounds, scene and errors. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
inspect_target and get_asset_status both surface receipt/status information, creating overlap in when to use each. build_asset and publish_blend also share queued/result semantics and Unity import behavior, though descriptions distinguish from-scratch building versus publishing an existing .blend.
All four tools use a consistent snake_case verb_noun pattern: inspect_target, build_asset, publish_blend, get_asset_status. The verb choices are all imperative and predictable for a pipeline-oriented server.
Four tools is reasonable for a v0.1 asset pipeline: inspect, build, publish, and check status. It is slightly lean for full lifecycle management but each tool has a plausible role.
Core build, publish, and status operations exist, but the surface lacks explicit delete/list asset operations and has no direct prompt-to-scene generation tool despite the server name. Update is only partially addressed through stable asset_id reuse.