Skip to main content
Glama

Twinmotion MCP

by io.scanbimlabs

tm_list_scenes

Enumerate every 2D/3D view ('scene') baked into the translated model, plus a shallow dump of the model object tree (first 50 top-level nodes across all 3D views), plus the list of completed derivatives (svf2, thumbnail, obj, etc.) available via APS. The canonical discovery tool for anything downstream that needs a view name or GUID.

When to use: before tm_render_image (to pick a valid camera_preset), before tm_export_video (to plan a camera path across named views), to audit what was translated ('did the 3D coordination view survive translation?'), or to expose the top-level model hierarchy for UI display. Also a useful health check — if scene_count=0, the translation is incomplete or failed. When NOT to use: not for full property queries on individual objects (this tool returns names + GUIDs + child counts only — use a dedicated property-query tool for full attribute dumps), not for geometry data (use tm_export_video for OBJ export), not on a URN that has not yet started translating. APS scopes required: viewables:read data:read. Read-only across Model Derivative manifest + metadata + object-tree endpoints. Rate limits: APS default ~50 req/min. This tool fans out across every 3D view to fetch object trees — for models with many 3D views (10+) it can burn a chunk of the budget in one call. Prefer caching the result on the caller side rather than re-invoking. Errors: 401/403 = token/scope; 404 = URN not found; 422 = n/a; 429 = back off 60s (this tool makes multiple APS calls per invocation, so 429 is more likely than on single-call tools); 5xx = APS upstream. A 202 on object-tree means APS is still building the tree — the tool retries once internally. Side effects: NONE on APS (read-only). Writes a usage_log row. Idempotent.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_idYesBase64-URL-safe URN of the translated model. Should have manifest.status='success' for full results; if still translating, scene_count may be 0 or partial.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed2 schema fields changed
    • changedInput schema / properties / project_id / description
      Previous value: -"Base64-encoded URN"New value: +"Base64-URL-safe URN of the translated model. Should have manifest.status='success' for full results; if still translating, scene_count may be 0 or partial."
    • addedInput schema / properties / project_id / examples
      Added value: +[
+  "dXJuOmFkc2sub2JqZWN0czpvcy5vYmplY3Q6c2NhbmJpbS12aXotMTcwMDAwMDAwMC9CdWlsZGluZy5ydnQ"
+]
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and excels: it discloses read-only status across APS endpoints, required APS scopes (viewables:read data:read), rate limits (~50 req/min) with fan-out caveat for 10+ views, a full error-code map including 429 backoff and internal retry on 202, and side effects (writes usage_log row, idempotent, no APS mutation).

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 organized into labeled sections with front-loaded main purpose. While long, every sentence earns its place: rate limits, error details, side effects, and alternatives are all operational necessities. This is deliberate structure, not verbosity.

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 tool with no output schema and no annotations, the description fully covers return content, error handling, rate limits, side effects, prerequisites, and alternatives. It is complete enough for an agent to invoke without missing critical constraints.

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?

Input schema covers the single parameter 100% with base64 URL-safe URN description and status caveat. The tool description adds no additional parameter semantics beyond this, so baseline 3 is appropriate.

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?

Description opens with specific verb 'Enumerate' and concrete outputs: every 2D/3D view, shallow object-tree dump (first 50 top-level nodes), and completed derivatives list. It explicitly names itself 'canonical discovery tool' for view names/GUIDs, clearly distinguishing it from render/export/import siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Contains explicit 'When to use' and 'When NOT to use' sections, naming alternative tools (property-query tool, tm_export_video for OBJ) and listing prerequisite conditions (not on a URN that hasn't started translating). This is textbook usage guidance.

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

All Twinmotion MCP toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.8/5.0
Disambiguation5/5

Each tool targets a distinct step in the BIM visualization pipeline: importing, listing scenes, rendering images, setting environment config, and preparing video export. Their purposes are clearly separated with no overlap.

Naming Consistency5/5

All tools follow a consistent 'tm_verb_noun' pattern (e.g., tm_import_rvt, tm_list_scenes, tm_render_image). The naming is uniform and predictable.

Tool Count5/5

With only 5 tools, the server is well-scoped for a focused domain (BIM model import and visualization preparation). Each tool serves an essential function without unnecessary bloat or deficiency.

Completeness4/5

The tool set covers the main workflow (import->configure->list->render/export), but there are minor gaps: tm_export_video does not produce the final video (requires external pipeline) and there is no tool for direct FBX/glTF export or model cleanup. Still, it adequately supports the stated purpose.

Resources