set_viewport_camera

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

With no annotations, the description carries the full burden. It usefully discloses failure behavior ('fails if it did not take') and that the result reports the camera actually being looked through, which is genuine behavioral context. It does not cover permissions, side effects on other panes, or whether the change is persistent, so it is only partially transparent.

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

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

Purpose is front-loaded in the first sentence, followed by a compact Args block that maps cleanly to the two parameters. No filler; only minor structural overhead from the arg list formatting.

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

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

For a simple two-parameter mutation tool with no output schema and no annotations, the description covers what changes (viewport camera), the failure mode, and both parameters. It could say more about pane targeting or persistence, but nothing essential for correct invocation is missing.

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

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, and it does: it explains camera_path (camera node path or USD camera prim path for Solaris) and pane_name (pane tab name). Both parameters are given meaning beyond their bare names, including the important dual-format nuance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a precise verb and resource: 'Set the viewport to look through a specific camera.' This distinguishes it from the nearby siblings set_viewport_direction (rotation), set_viewport_display, and set_viewport_renderer, since the scope here is camera assignment. An agent can select this tool unaided.

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

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

It implies when the tool applies by noting that camera_path may be a node path or a USD prim path 'for a Solaris viewport', which helps route Solaris vs non-Solaris contexts. However, there is no explicit when-to-use versus alternatives such as set_viewport_direction or get_viewport_info, and no exclusions. Usage is inferred rather than stated.

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