Skip to main content
Glama

build_scene_stub

Read-onlyIdempotent

Generates an offline Vite + Three.js scaffold from a capture_scene_3d evidence pack, recreating supported primitives and a static camera while marking unresolved elements.

Instructions

Generate an offline Vite + Three.js scaffold from a capture_scene_3d evidence pack (scene-evidence-v1), not a recovery: the pack stores rendered frames and observed responses, so unless the experimental three adapter recorded a bounded scene summary, no scene graph, camera, controls, shader source or geometry is read, and captured application code, shader source, userData and callbacks are never executed. With evidence.three it recreates only Box/Plane/Sphere/Cylinder primitive meshes with position/quaternion/scale, MeshStandard/MeshBasic colour/opacity and locally bound texture maps, plus a static perspective camera applied from its exact captured matrix (matrix auto-update off); captured controls are never recreated, and unsupported geometry, materials, cameras and controls are listed as unresolved instead of guessed. Validates evidencePath itself (regular file, <=2 MiB, inside /scene-captures or a pack exported with top-level "exported": true) and up to 32 assetBindings (resourceId must be an observed inventory row that is not a script or shader; localPath must exist, be a regular non-symlink file <=64 MiB with a glb/gltf/bin/png/jpg/jpeg/webp/ktx2/hdr/exr extension; traversal and duplicate resourceIds are rejected). Returns files[{path,content}] (package.json with pinned three 0.160.0 + vite and dev/build/preview scripts, index.html, src/main.js with resize, reduced-motion static render, GLTFLoader for a bound model, texture loading, a clearly labelled placeholder plane when no model or captured mesh exists, disposal on pagehide and a load-failure message, scene.json describing bindings and frame references, and a provenance README), assetCopies[{from,to}] to public/assets/., unresolved[], authoredDefaults[] and provenance; mode is "reconstructed-subset" when a glb/gltf model is bound or the three adapter recorded at least one supported mesh, otherwise "placeholder". Deterministic and byte-stable, and strictly offline: no fetch, no install, no directory writes - copy assetCopies, then run npm install && npm run build yourself.

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": {
      "evidencePath": "<evidencePath>"
    },
    "name": "build_scene_stub"
  }
}

Input Schema

NameRequiredDescriptionDefault
titleNoTitle for index.html and the provenance README
evidencePathYesLocal scene-evidence-v1 JSON from capture_scene_3d, under <cache>/scene-captures or an exported pack
assetBindingsNoUp to 32 local files bound to inventory rows; each resourceId binds once

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.0

TDQS

A4.5/5.0
Behavior5/5

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

Goes far beyond the annotations (which already cover read-only/idempotent/non-destructive/closed-world) by disclosing that captured code, shaders, userData and callbacks are never executed, that output is deterministic and byte-stable, and that nothing is fetched, installed, or written to disk. It also names the concrete validation thresholds and rejection rules up front rather than hiding them in errors.

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

Conciseness3/5

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

Every clause carries information, but the whole definition is one dense run-on paragraph with deeply nested parentheticals, making it hard to scan for the key limits. Front-loading the purpose is good, yet validation rules, reconstruction scope, return shape and workflow are interleaved rather than separated into scannable chunks.

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?

There is no output schema, so the description carries the full burden and does: it enumerates files[{path,content}], assetCopies, unresolved[], authoredDefaults[], provenance and the mode values. For a generator tool with non-obvious failure semantics (unresolved vs guessed), nothing essential is 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real constraints not present in the schema: the <=2 MiB cap, the requirement that evidencePath live under <cache>/scene-captures or a pack with top-level "exported": true, and traversal/duplicate resourceId rejection. The extension whitelist is largely a restatement of the schema field descriptions.

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 and artifact ('Generate an offline Vite + Three.js scaffold') plus the exact input source ('capture_scene_3d evidence pack (scene-evidence-v1)'), and immediately bounds it with 'not a recovery'. The scaffolding-tool family (build_pose_stub, build_gsap_stub, build_project) is clearly distinguished by name and domain.

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?

Explicitly says when the three-adapter subset path applies ('With evidence.three it recreates only...') and what happens otherwise ('placeholder' mode), plus a closing workflow instruction ('copy assetCopies, then run npm install && npm run build yourself'). It never names an alternative sibling to use instead when no evidence pack exists, so routing is clear in-context but not fully enumerated.

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