Skip to main content
Glama
Sign In
Construct

Construct

by rtmandreyev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

construct_export

Read-onlyIdempotent

Exports a valid v2 scene or parameter document as a glTF/GLB or OBJ/MTL 3D model with named parts, materials, and animations for Blender, Godot, Unreal, Unity, or three.js.

Instructions

A 3D model of a valid v2 scene or parameter document: glTF 2.0 (base64 .glb: named parts, materials by role, the open and idle animations, each vertex's build phase as _PHASE) or OBJ text with its MTL. Opens in Blender, Godot, Unreal, Unity (glTFast) and three.js.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "document": "<document>"
    },
    "name": "construct_export"
  }
}

Input Schema

NameRequiredDescriptionDefault
poseNo
wireNo
frameNo
gluedNowith pieces: what stays put is one body, each hinged or sliding part one more, its joint in its extras (Godot: docs/GODOT.md)
mergeNomerge the parts that do not move, one mesh per material
formatNo
piecesNothe pieces it would break into, each a rigid body with convex shapes (OMI_physics_body), interlocked parts together
documentYesa construct-scene (version 2) or a construct-params document
collidersNoa box collider per part (Godot: -convcolonly)
materialsNoa material map: {"materials": [{"parts": [...], "color": "#rrggbb", "metallic", "roughness"}]}

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.3.1

TDQS

B3.4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the description's job is to add substance, which it does: named parts, materials assigned by role, bundled open/idle animations, per-vertex _PHASE data, base64 encoding for glb, and a compatibility list of engines. It omits failure behavior for invalid documents and any size/streaming caveats for the base64 payload.

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?

Dense but front-loaded: the product is stated first, then the two format branches with their distinguishing details. It reads as one long run-on sentence with parenthetical nesting, which costs some scannability but wastes no content.

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?

For a 10-parameter tool with nested objects and no output schema, the description does cover return shape (base64 .glb vs OBJ text plus MTL), which is the biggest gap it needed to fill. It still leaves the four optional enum parameters and error behavior on invalid input unexplained, so it is adequate rather than complete.

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

Parameters3/5

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

Schema coverage is 60%: document, glued, merge, pieces, colliders, and materials carry their own descriptions, while pose, wire, frame, and format are bare enums. The description only obliquely touches format (glb/obj) and pose (open/idle animations); the ambiguous wire enum ('edges','tubes','seams','none') is never explained, so it does not fully compensate for the gaps.

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 concrete outcome — a 3D model produced from a valid v2 scene or parameter document — and enumerates the two payload forms (base64 .glb, OBJ+MTL) with their contents. It is specific about the resource and result, though it never names a sibling or explicitly distinguishes exporting from compile/print.

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?

The only usage signal is the precondition that the document be a 'valid v2 scene or parameter document'; there is no guidance on when to choose this over construct_compile, construct_print, or the template helpers. An agent must infer that this is the geometry/file-output path from the name alone.

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

Deploy Server

Other Tools