Sceneplane

Create export

export_create

Export a revision to GLB, OBJ, STL, .blend, or the complete editable .ngp document for an ngPlant project. Native ngp is a byte-preserving download with no selection, modifiers, scale, presets or baking. enginePreset applies target-engine conventions and overrides yUp/scaleFactor: unity and godot (GLB, Y-up, meters), print (STL scaled ×1000 AND Z-up, because slicers read raw units as millimeters and orient Z-up — the preset is the whole print convention, not just the scale), unreal (GLB converted by UE on import; OBJ/STL scaled ×100 to centimeters). Selection is resolved against the exported revision before dispatch and the response lists exactly which objects were selected — broken down by type, so a stray curve or empty is visible — and a stale id or an empty match fails loudly instead of silently shipping an incomplete file. Curves with no bevel or extrude carry no surface and are skipped (named in the response) unless you pass them in objectIds. Returns a durable job handle; the file becomes an immutable artifact.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`yUp`	No
`format`	Yes
`bakeSize`	No
`objectIds`	No	Platform ids, with selectionPolicy=objects. NOTE: ids are datablock-scoped — deleting and recreating an object mints a NEW id, so a list gathered before an edit can go stale. Prefer objectNamePattern, which is resolved fresh at dispatch.
`projectId`	Yes	Stable project ID returned by project_create or projects_list.
`revisionId`	No	"HEAD" (default) uses the project's current head	HEAD
`scaleFactor`	No
`bakeLighting`	No	GLB only: bake the full rendered shading, lights included, into UNLIT emissive textures. The trade is view dependence, and it is not subtle: the bake stores one sample of the shading per surface point, so specular highlights stop moving with the camera, reflections and glass stop responding to their surroundings, and anisotropic or clearcoat sheen becomes a fixed painted shape. It looks correct from the baked viewpoint and drifts as the viewer orbits. Right for a dark or rig-driven scene a web viewer cannot relight, WRONG for a turntable of a metal or glass product — use bakeTextures for that, which bakes procedural material values and leaves lighting to the viewer.
`bakeOverflow`	No
`bakeTextures`	No	GLB only: bake procedural (node-driven) materials to textures before export so viewers keep the rendered look. Meshes without UV layers are unwrapped automatically first, which is slow on many-part assemblies (the response says so, and the job reports per-object bake progress). Only procedural, node-driven values are lost when this is off: materials with constant base colour, metallic and roughness export correctly unbaked, so false is the right choice for most hard-surface work.
`enginePreset`	No
`applyModifiers`	No
`idempotencyKey`	Yes	Stable caller-chosen key for safe retries of this same request.
`bakeObjectLimit`	No
`selectionPolicy`	No
`excludeObjectIds`	No	Drop these specific platform ids. Applied after the other selectors.
`objectNamePattern`	No	Select by Blender object name with * wildcards, e.g. "Watch_" or "_Link". Resolved against this revision at dispatch, so it cannot go stale like objectIds. Combined with selectionPolicy (visible + pattern selects visible matches).
`excludeNamePattern`	No	Drop objects whose name matches, e.g. "Studio_*". Applied after the other selectors. Omitting one backdrop from a 60-part scene previously meant enumerating 60 explicit ids, which is both tedious and stale-prone.

Output Schema

TableJSON Schema

Name	Required	Description
`job`	Yes
`yUp`	Yes
`selection`	Yes	Resolved runner selection policy; this field is a string, not a selection object.
`revisionId`	Yes
`scaleFactor`	Yes
`selectedCount`	Yes	Number of selected objects when the revision summary is available; null means unknown.
`expectedCounts`	Yes
`selectedObjectIds`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedOct 1, 2026

removedInput schema / properties / applyModifiers / default
```
Removed value: -true
```
removedInput schema / properties / bakeLighting / default
```
Removed value: -false
```
removedInput schema / properties / bakeObjectLimit / default
```
Removed value: -24
```

removedInput schema / properties / bakeObjectLimit / description

Removed value: -"Maximum eligible GLB objects to bake. Default 24; raise up to 512 for assemblies. The per-job budget is 67,108,864 object texture pixels: 446 objects fit at bakeSize=256."

removedInput schema / properties / bakeOverflow / default
```
Removed value: -"error"
```

removedInput schema / properties / bakeOverflow / description

Removed value: -"When eligible objects exceed bakeObjectLimit, error stops before any bake. partial explicitly permits an incomplete bake while retaining all selected geometry; exportVerification.bakeSummary reports completed and omitted counts."

removedInput schema / properties / bakeSize / default
```
Removed value: -1024
```
removedInput schema / properties / bakeTextures / default
```
Removed value: -true
```

changedInput schema / properties / format / enum

Previous value: -[
-  "glb",
-  "obj",
-  "stl",
-  "blend"
-]New value: +[
+  "glb",
+  "obj",
+  "stl",
+  "blend",
+  "ngp"
+]

removedInput schema / properties / scaleFactor / default
```
Removed value: -1
```
removedInput schema / properties / selectionPolicy / default
```
Removed value: -"all"
```
removedInput schema / properties / yUp / default
```
Removed value: -true
```

First observedSep 24, 2026

TDQS

A4.5/5.0

Behavior5/5

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

With annotations present, the description adds substantial behavior beyond them: selection is resolved against the exported revision before dispatch, the response enumerates selected objects by type, stale ids or empty matches fail loudly, surface-less curves are skipped and named, and the call returns a durable job handle producing an immutable artifact. This is far richer than the minimal annotation hints.

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?

Core purpose is front-loaded in the first sentence, and the following sentences are information-dense rather than filler. However, the single long paragraph packs many distinct concerns (presets, selection, curves, job lifecycle) and is heavier than strictly necessary.

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?

An output schema exists so return values need no explanation, and the description covers the mutation semantics, selection resolution, and job/artifact lifecycle for a complex 18-param tool. A few undocumented parameters (bakeSize, bakeObjectLimit, bakeOverflow) leave minor gaps.

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 only 50% across 18 params, but the description compensates well: it explains enginePreset's Y-up/scale behavior per engine (unity/godot/print/unreal), that print is ×1000 AND Z-up as a whole convention, and how selection/id staleness works. It leaves some params (bakeSize, bakeObjectLimit, bakeOverflow, format) unexplained, so shy of 5.

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

Purpose5/5

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

States a specific verb (export) plus the resource (a revision) and enumerates the exact output formats (GLB, OBJ, STL, .blend, .ngp) for an ngPlant project. This cleanly distinguishes it from sibling mutation tools like render_create or asset_generate_3d.

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?

Gives concrete routing guidance for parameters: ngp means byte-preserving with no selection/modifiers, enginePreset selects target-engine conventions, and bakeLighting explicitly points to bakeTextures as the alternative for metal/glass turntables. It lacks explicit when-to-use-this-tool-vs-siblings guidance (e.g. vs render_create), so not a 5.

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

All Sceneplane tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?