Skip to main content
Glama

Create export

export_create

Export a revision to GLB, OBJ, STL, or .blend. 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
NameRequiredDescriptionDefault
yUpNo
formatYes
bakeSizeNo
objectIdsNoPlatform 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.
projectIdYesStable project ID returned by project_create or projects_list.
revisionIdNo"HEAD" (default) uses the project's current headHEAD
scaleFactorNo
bakeLightingNoGLB 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.
bakeOverflowNoWhen 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.error
bakeTexturesNoGLB 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.
enginePresetNo
applyModifiersNo
idempotencyKeyYesStable caller-chosen key for safe retries of this same request.
bakeObjectLimitNoMaximum 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.
selectionPolicyNoall
excludeObjectIdsNoDrop these specific platform ids. Applied after the other selectors.
objectNamePatternNoSelect 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).
excludeNamePatternNoDrop 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
NameRequiredDescriptionDefault
jobYes
yUpYes
selectionYesResolved runner selection policy; this field is a string, not a selection object.
revisionIdYes
scaleFactorYes
selectedCountYesNumber of selected objects when the revision summary is available; null means unknown.
expectedCountsYes
selectedObjectIdsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

The description goes well beyond the four boolean annotations: it discloses that selection is resolved against the exported revision, the response lists selected objects by type, stale ids fail loudly, curves without surfaces are skipped, a durable job handle is returned, and the file becomes an immutable artifact. These are exactly the behavioral traits an agent needs to predict side effects.

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

Conciseness5/5

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

The description is dense but every clause earns its place: purpose is front-loaded, then engine conventions, selection failure behavior, curve handling, and the durable artifact output. For an 18-parameter tool, the length is justified and there is no filler or repetition of schema content.

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

Completeness5/5

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

Given the tool's complexity, the existing output schema, and the presence of defaults in the input schema, the description covers the essential operational context: formats, engine presets, selection semantics, failure modes, and async job behavior. Nothing critical for invoking it correctly appears to be missing.

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?

With only 61% schema description coverage, the description meaningfully compensates by explaining enginePreset behavior in detail (overrides yUp/scaleFactor; print's Z-up/mm convention; unreal scaling), bake trade-offs, and selection/curve edge cases. It does not directly address every remaining parameter, but the decision-critical parameters are substantially enriched.

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?

The opening sentence names a specific verb and resource: 'Export a revision to GLB, OBJ, STL, or .blend.' The export formats and verb clearly separate this tool from siblings like render_create and asset_generate_3d, so an agent can identify it without opening the schema.

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?

The description gives clear context for when to use it — when a revision needs to be exported to specific file formats — and then gives concrete decision guidance for engine presets and bake modes. It does not explicitly contrast against sibling tools such as render_create, but the context is strong enough to route correctly.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources