3D Visualizer

Overview Schema Source Related Servers Discussions Admin

manage_3d_views

Save, restore, list, delete, or undo named camera views in the current 3D session to manage agent camera changes.

Instructions

Save/restore named camera views for this renderer session; undo the last agent camera change (up to 50). Names are not persisted after closing/reloading the widget. Does not restore geometry or filters.

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": {
      "scene_id": "<scene_id>",
      "action": "<action>"
    },
    "name": "manage_3d_views"
  }
}

Input Schema

Name	Required	Default
`name`	No
`action`	Yes
`detail`	No	summary
`scene_id`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 9, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description adds valuable behavioral traits: view names are not persisted after closing/reloading, the undo stack is limited to 50 changes, and the tool does not restore geometry or filters. These details are not inferable from the schema or annotations and significantly inform the agent's expectations.

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 a single sentence with semicolons, efficiently packing purpose, scope, undo limit, persistence caveat, and exclusions. It is front-loaded with the core action and avoids redundancy. Every clause adds necessary information without waste.

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

Completeness4/5

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

Given the tool has an output schema (which can explain return values) and a clear action enum, the description covers the essential behavioral context. It explains the main use cases and limitations, but could have mentioned the availability of list and delete actions to preempt ambiguity. Overall, it is sufficient for an agent to invoke the tool correctly, but not exhaustive.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It only hints at the 'name' parameter via 'named camera views' and implicitly covers 'action' with 'save/restore' and 'undo'. It does not mention the 'detail' parameter or other actions like 'list' and 'delete'. The description falls short of explaining the full parameter set, leaving the agent to rely on the schema enum values without additional context.

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 description states a specific verb-resource pair: 'Save/restore named camera views' and 'undo the last agent camera change'. It clearly scopes to the renderer session and distinguishes from siblings like set_3d_camera and navigate_3d_view by focusing on named views and undo. The exclusion of geometry/filters further clarifies its boundary.

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 provides clear context on when to use the tool (managing named camera views and undoing agent changes) and notes non-persistence across sessions. However, it does not explicitly name alternatives or state when not to use it, leaving some inference to the agent. It conveys usage context well but lacks direct exclusions.

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