Which integrations are available for this server?

Enables building and revising 3D props through AI-authored Blender Python scripts executed in background Blender. It retains editable .blend source revisions and can publish existing .blend files created by other Blender tools for import into Unity. Provides a Unity package bridge that imports validated FBX assets, creates materials and prefabs, places props in the active scene with colliders, preserves stable asset identities across revisions, and returns import receipts with request IDs, GUIDs, mesh counts, and bounds.

How do I use prompt-to-scene?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@prompt-to-scene build a wooden crate in Blender and place it at [2,0,3] in Unity with a collider" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

prompt-to-scene

by 316sandon12

Overview Schema Source Related Servers Discussions Admin

Local

Prompt-to-Scene

Ask your AI to build a prop in Blender, place it in Unity, and revise the same asset.

简体中文 · Quickstart · Asset contract · Architecture

An open-source MCP server and Unity package for a complete build → import → verify → revise workflow. Your existing AI client writes Blender Python; this project runs Blender, transfers a validated asset, creates Unity materials and a prefab, places it in the active scene, and returns an import receipt.

v0.1 experimental: static opaque props; Unity Built-in/URP. Unreal support is planned, not implemented. This project does not include an LLM or an image-to-3D model. Natural-language interpretation comes from your MCP-compatible AI client.

Two material variations of the included crate, rendered in Unity

Actual Unity render of the included Blender recipe, staged with two material variations. See the real-engine checks.

The interaction

“Create a one-meter wooden crate with iron straps in Blender. Put it at [2, 0, 3] in Unity and add a collider.”
“Make the wood darker and the straps thinner. Update the same crate.”

The AI calls build_asset, then get_asset_status. Reusing the asset ID updates the existing prefab. Existing instance transforms and prefab-root components are preserved. A queued export is never reported as a successful Unity import.

Related MCP server: Blender MCP Server

What works

Four MCP tools: inspect_target, build_asset, publish_blend, get_asset_status.
Real background Blender execution; editable .blend source retained per revision.
Native FBX import into Unity; no additional Unity import package required.
Principled BSDF base color, metallic and roughness; optional direct base-color and tangent normal textures.
Materials adapted to Built-in Standard or URP Lit.
Stable asset/material/prefab paths, automatic scene placement and box collider.
Import receipts with request ID, prefab GUID, mesh/triangle counts and bounds.
A CLI and a reproducible crate recipe, usable without an AI subscription.

Requirements

Python 3.11+ and uv.
Blender 4.2+ (first verification target: 4.2).
Unity 2022.3+ with an activated editor; Built-in or URP.
An MCP-compatible client for natural-language use. CLI use does not require one.

Versions outside the recorded verification matrix are not a compatibility guarantee. See verification.

Quickstart

1. Get the server

git clone https://github.com/316sandon12/prompt-to-scene.git
cd prompt-to-scene
uv sync --locked

2. Install the Unity package

In Unity: Window → Package Manager → + → Add package from disk. Select:

unity/Packages/com.prompttoscene.bridge/package.json

Keep the cloned repository in place. Open a scene in the target project, leave Play Mode, and wait for compilation to finish. Both applications operate on your local machine; Blender is started as a separate background process by the server. You do not need a Blender MCP addon for this path.

3. Register the MCP server

Use your client's MCP server settings with this configuration. Replace every example path with your own absolute path:

{
  "mcpServers": {
    "prompt-to-scene": {
      "command": "/absolute/path/to/uv",
      "args": ["--directory", "/absolute/path/to/prompt-to-scene", "run", "--locked", "prompt-to-scene-mcp"],
      "env": {
        "PTS_UNITY_PROJECT": "/absolute/path/to/MyUnityProject",
        "PTS_BLENDER": "/absolute/path/to/blender"
      }
    }
  }
}

On macOS the usual Blender executable is /Applications/Blender.app/Contents/MacOS/Blender. On Windows use the full path to blender.exe; backslashes in JSON must be escaped. The project path selects the destination explicitly, even if several Unity editors are open.

Try the interaction above. Ask the AI to inspect the target, follow the asset contract, and verify the returned request ID. Unity polls for work every two seconds while idle. If you receive queued, the engine has not confirmed an import yet.

CLI smoke test

With Unity open and the package installed:

uv run prompt-to-scene --project /path/to/MyUnityProject build crate --script examples/crate.py --position 2 0 3
uv run prompt-to-scene --project /path/to/MyUnityProject status crate

The result appears under Assets/PromptToScene/crate/. Save your scene normally; the bridge marks it dirty but does not silently save existing scenes. Add .prompt-to-scene/ to your Unity project's .gitignore to exclude the local queue, logs and source revisions.

To publish a model created through another Blender AI tool, save it with its asset meshes inside a collection named Export, then call publish_blend. The original file is opened with auto-execution disabled and is not overwritten.

For a self-contained textured example, use --script examples/textured_cube.py with a different asset ID. It creates its own UVs, checker texture and normal map, without downloads.

Revision behavior

Use the same asset_id to regenerate the same asset. Each build_asset script describes the entire asset from scratch; there is no persistent interactive Blender session. To edit an existing file, use another Blender tool and publish_blend.

Source revisions remain in <UnityProject>/.prompt-to-scene/work/.
Imported .meta files and prefab/material GUIDs remain stable.
Existing scene instance positions/rotations/scales and prefab-root components remain intact.
The prefab's Visual subtree, root box collider and managed material properties are owned by the bridge. Put custom scripts on the prefab root; do not put manual overrides inside Visual.
Renaming a Blender material creates a new material identity. Removed material/texture files are retained rather than automatically deleted.
A pending import must finish before rebuilding that asset. Different asset IDs have independent requests.

Boundaries

This version deliberately rejects unsupported material nodes instead of silently exporting a different appearance. No automatic procedural texture baking, roughness/metallic textures, transparency, rigs, animation, LOD generation or UE adapter yet. Materials can differ under different engine lighting/color management; there is no pixel-identical rendering guarantee.

Blender scripts execute as your local user and are not sandboxed. Use trusted scripts and your AI client's tool permissions. Generated .blend files are local artifacts; no model or project is uploaded by this bridge. Import failures are reported, but there is no full AssetDatabase rollback after a mid-import engine error. Keep projects under version control.

Development

uv sync --locked
uv run pytest
uv run ruff check .
uv run ruff format --check .

For real Blender/Unity integration verification, see verification. CI exercises Python and the MCP protocol; Unity requires a licensed editor and is tested separately.

Roadmap

AI-authored Blender Python → Unity scene with import receipts
Stable asset identity and revisions
Texture baking and broader PBR input coverage
Engine-side preview screenshots returned to the AI
Unreal Engine adapter using the same task/receipt contract
Interactive Blender-session adapter and richer scene placement

MCP for Blender, MCP for Unity, and Blender Tools are useful adjacent projects. This repository is an independent implementation and does not vendor their code. It can receive a saved .blend produced by another tool through publish_blend.

License

MIT. See LICENSE. Blender, Unity and your AI client have their own licenses. Example geometry is generated by the included original Python recipe.

Available Tools

4 tools

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.

ParametersJSON Schema

Name	Required	Description	Default
`asset_id`	Yes
`collider`	No
`position`	No
`blender_python`	Yes

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does substantial work: it discloses background execution, that each script builds from scratch (so prior content in the asset is replaced), that default scene objects must be deleted, that unsupported materials fail explicitly, and that no external APIs are needed. It doesn't cover idempotency, permissions, or runtime/rate behavior, so it is not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action in the first clause, then progressive detail on identity, placement, script conventions, and version limits. Every sentence carries information, though the dense multi-clause final paragraph could be tighter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-annotation, no-output-schema, 4-parameter mutation tool this is unusually complete on execution model, scoping, and failure behavior. The remaining gaps are the undocumented collider parameter and any indication of what the call returns or how queued Unity imports progress.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate, and it does for three of four params: asset_id character set and stability semantics, position units (Unity XYZ meters) and the first-placement-only rule, and blender_python conventions (delete defaults, create Export collection, link meshes). The collider boolean is never mentioned, leaving one parameter entirely undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource chain — execute bpy code in background Blender, save .blend, queue Unity import — which is far more informative than the bare name build_asset. It stops short of naming or contrasting with siblings like publish_blend or get_asset_status, so an agent must infer the boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives concrete when-to-use rules: reuse a stable asset_id to update rather than create, and position applies ONLY on first placement. It also states scope limits (v0.1 static meshes, constant opaque PBR) and that unsupported materials fail explicitly. It never routes to an alternative tool or states prerequisites, which keeps it from a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_asset_statusC

Read Unity's receipt: request ID, asset paths, geometry, bounds, scene and errors.

ParametersJSON Schema

Name	Required	Description	Default
`asset_id`	Yes

TDQS

C2.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only operation ('Read') and mentions that errors are returned, but it omits permissions, rate limits, idempotency, and side-effect information.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no wasted words; the return fields are listed compactly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description compensates for the absent output schema by enumerating return fields, but with no annotations and an undocumented required parameter, an agent still lacks enough context to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the single required parameter asset_id is not described at all in the description. The description lists output fields instead of explaining what an asset_id is or its format.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb 'Read' and names the resource 'Unity's receipt', then enumerates the receipt's fields. This is more specific than a tautology and approximates 'clear verb+resource+fields', but it does not distinguish this tool from sibling inspect_target or clarify what 'receipt' means in this context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool, prerequisites, or alternatives. Sibling tools inspect_target/build_asset/publish_blend are not referenced, so the agent must infer the workflow.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

inspect_targetC

Inspect Blender, Unity heartbeat, rendering pipeline and previous asset receipts.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. "Inspect" implies a read-only diagnostic, but the description does not confirm that, nor does it mention permissions, side effects, freshness, or failure modes. For a zero-annotation tool this is a substantial gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler; the inspected sources are listed up front. It is terse almost to the point of under-specification, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description is the only source of information about what the agent receives back. It names the four things inspected but never describes the shape, aggregation, or status semantics of the result, leaving a meaningful gap for a diagnostic tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. No parameter-related value is added or needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description has a clear verb ("Inspect") and enumerates what is inspected (Blender, Unity heartbeat, rendering pipeline, asset receipts), which distinguishes it from build_asset, publish_blend and get_asset_status. However it never states the actual resource or what the inspection produces, so the purpose reads more like a list of inputs than a defined capability.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to call this tool, what condition it diagnoses, or how it relates to the siblings. An agent must infer that this is a health/diagnostic check, which is plausible but unstated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

ParametersJSON Schema

Name	Required	Description	Default
`asset_id`	Yes
`collider`	No
`position`	No
`blend_file`	Yes

TDQS

A3.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does meaningfully: it declares the operation is non-destructive to the original, that results are queued/asynchronous, and that Blender auto-execution is disabled. It does not state required permissions, error modes, or what is actually emitted as a result.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the core action and the non-destructive guarantee. The 'material contract and queued/result semantics as build_asset' sentence is compact but depends on external knowledge of a sibling tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Workflow placement, non-destructiveness, and async semantics are covered, and build_asset is cited for return behavior. However, with no output schema, 0% parameter coverage, and no mention of what a publish produces or where, an agent still has gaps before calling correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across four parameters, so the description must compensate — and it does not. It never explains asset_id, collider, or position, and only loosely implies blend_file via 'existing saved .blend'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (publish) and resource (Export collection of a saved .blend), plus the non-destructive constraint. It implicitly distinguishes itself from build_asset by requiring an existing saved file, though it never names the alternative outright.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use this after another Blender tool has modeled and saved an asset' gives a clear timing precondition for invoking it. It lacks explicit when-not guidance, e.g. what to use instead of publishing or when a publish would fail.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv0.1.0Sep 30, 2026
- First observedbuild_asset
- First observedget_asset_status
- First observedinspect_target
- First observedpublish_blend

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.2/5.0

Scored 2026-09-30 03:40 across 4 tools

Disambiguation3/5

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.

Naming Consistency5/5

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.

Tool Count4/5

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.

Completeness3/5

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.

Maintenance

ActivityNo data

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

ChiR24-unreal_mcpOAuth
ai.smithery
Control Unreal Engine to browse assets, import content, and manage levels and sequences. Automate…
Developer Tools App Automation Multimedia Processing
2888
Gessa: game asset generation for AI agentsOAuth
ai.gessa
Generate game-ready 3D models, textures, and audio from natural language, over MCP.
AI & Machine Learning Image & Video Processing Audio Processing
1
ReelpenOAuth
io.github.viscountsparrow-cloud
Build editable 3D scenes, direct characters and cameras, and export AI video references with MCP.
Image & Video Processing Multimedia Processing Design Tools
1
agent4.io A
io.agent4
Build and run grounded business agents over MCP: agents, knowledge bases, skills, Storylines.
Agent Orchestration Autonomous Agents RAG Systems
501

Related MCP Servers

bMCP
Design Tools Image & Video Processing
niewinny
A
license
Not graded
quality
C
maintenance
Enables AI to control Blender 3D through the Model Context Protocol, allowing Python execution, scene state queries, and automation of 3D workflows.
Updated 7 months ago (2026-02-19 19:44 UTC)
5
GPL 3.0
Blender MCP Server
Design Tools Multimedia Processing Code Execution
djeada
A
license
A
quality
A
maintenance
Enables AI assistants to control Blender via MCP tools for scene manipulation, material assignment, rendering, and Python script execution.
Updated 7 days ago (2026-09-23 17:18 UTC)
27
336 PyPI
28
MIT
Subhuti Blender MCP
Design Tools Image & Video Processing
taurus-wsk
F
license
A
quality
B
maintenance
Enables controlling a local Blender instance through natural language or code, allowing arbitrary Python/bpy execution and querying scene or object information via MCP.
Updated a month ago (2026-08-30 09:25 UTC)
4
-
Blender MCP
Design Tools Image & Video Processing Multimedia Processing
a-homelab
A
license
A
quality
C
maintenance
Enables AI assistants to control a Blender instance through MCP tools, supporting scene creation, editing, and asset exchange via HTTP and background CLI processes.
Updated 12 days ago (2026-09-18 20:31 UTC)
26
Apache 2.0

Prompt-to-Scene

The interaction

What works

Requirements

Quickstart

1. Get the server

2. Install the Unity package

3. Register the MCP server

CLI smoke test

Revision behavior

Boundaries

Development

Roadmap

Related projects

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers