Skip to main content
Glama

capture_scene_3d

Captures WebGL/canvas page evidence at scroll checkpoints, saving viewport and canvas screenshots plus an asset inventory for design verification.

Instructions

Scene evidence in two strict operations. request.op:"capture" records a passive evidence pack for a WebGL/canvas page: at each checkpoint it scrolls the selected root, optionally moves the pointer, and saves a viewport screenshot plus a clipped canvas screenshot, with requested/actual scroll, canvas CSS rect/backing size/DPR and elapsed time. It also records a redacted inventory of the page's own responses (URL, MIME, size when declared, resource type, texture/model/HDR/shader/script/font/image guess, and an assetId per row) and passive framework hints (THREE.REVISION, BABYLON.Engine.Version, pc.version, matching script URLs, canvas count) without calling getContext or installing hooks. request.op:"download_assets" downloads up to 32 inventory assets from one capture: downloading is a licensing decision, so rights.basis (owned|licensed|permission) and rights.evidence are mandatory, are recorded with a timestamp in scene-captures//provenance.json, and are not verified by the server - do not download assets you may not use. It only fetches observed inventory URLs that carry no query string, fragment or credentials; there is no crawling, no guessed model or source-map URL and no credential use. Original bytes are written under scene-captures//assets with SHA-256 and an extension validated from MIME/magic (glb, gltf, bin, png, jpg, webp, ktx2, hdr, exr); unknown types are skipped unless allowUnknown saves them as .bin. Caps: 16 MiB per file, 64 MiB per run, 5 manual redirects, 1 request/second, one request at a time, 15s body deadline, 120s overall; every hop is DNS-validated and loopback/private/metadata/reserved addresses are refused. Honest scope: without the opt-in adapters no scene graph, camera, controls, shader source or geometry is recovered - frames show rendered output only. adapters are experimental and opt-in (at most two entries, each once): "three" reads objects reachable from window.THREE, window.scene/camera/renderer and window.app/experience/viewer/world after load (no heap crawl, no hooks, no network) and adds a bounded evidence.three summary (max 500 nodes, depth 20, 8 cameras, 8 lights, 32 materials, 200 texture URLs); "spector" needs the optional spectorjs package, installs its bundle as an init script before load and captures one WebGL frame into a bounded evidence.spector summary (command names/counts, context attributes, analyses, max 8 programs, 16 shaders, 64 KiB per shader source and 256 KiB of shader source total; command arguments, state, results, stack traces and memory are never transferred, and shader source is untrusted page text that is never executed). scene/camera/controls/geometry are marked available only for what three actually returned, shaders only when spector captured at least one source, and neither adapter promises scene recovery. Evidence is written to scene-captures//evidence.json plus PNG frames; responses are compact JSON with assetIds and downloadability, paths, hashes, counts, coverage and limitations, never inline image or asset bodies. The capture op requires the optional playwright dependency; download_assets does not.

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": {
      "request": "<request>"
    },
    "name": "capture_scene_3d"
  }
}

Input Schema

NameRequiredDescriptionDefault
requestYesExactly one scene operation: choose op and its fields

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?

Annotations only say it is not read-only, is open-world, non-idempotent and non-destructive; the description goes far beyond that by disclosing on-disk artifacts (scene-captures/<captureId>/evidence.json, PNG frames, provenance.json, assets with SHA-256), that rights evidence is recorded but never verified, hard caps (16 MiB/file, 64 MiB/run, 1 req/s, 15s/120s deadlines), DNS validation refusing private/loopback/metadata addresses, and exactly what the adapters never transfer (heap, command arguments, state, executed shader source).

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?

The information is front-loaded with the two-op split, but the body is a single dense paragraph that repeats itself ('no hooks, no heap crawl, no network' appears twice) and restates caps and adapter limits already expressed in the schema. It earns much of its length given tool complexity, but trimming duplication would improve scannability.

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?

For a complex, non-idempotent, open-world tool with no output schema, the description covers artifacts written, return shape ('compact JSON with assetIds and downloadability, paths, hashes, counts, coverage and limitations, never inline bodies'), failure/limits, dependency requirements, and the honest-scope limitation. Nothing an agent needs to invoke either op correctly appears 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 description coverage is already 100%, so the baseline is 3, but the prose adds genuine meaning: it explains why rights.basis/evidence exist (licensing decision, timestamped in provenance), why only query-string-free inventory URLs are fetched, what adapters actually return and their per-adapter bounds, and what allowUnknown vs skip means semantically. Remaining gaps are minor since the schema carries the per-field detail.

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 line names both operations as strict modes and the capture branch states a precise verb+resource: a passive evidence pack for a WebGL/canvas page (screenshots, scroll/canvas metrics, redacted response inventory, framework hints). An agent can tell this apart from generic capture siblings like capture_live_site or capture_pose_3d because the scope is explicitly WebGL/canvas scene evidence.

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 clearly frames the two-op decision (request.op capture vs download_assets), states that capture requires the optional playwright dependency while download_assets does not, and makes rights.basis mandatory before any download. It gives the honest-scope caveat that scene graph/camera/shader recovery only happens with opt-in adapters. What it lacks is an explicit comparison to sibling tools such as capture_live_site, leaving that choice to inference.

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