Pan the active Rhino viewport by specifying horizontal (dx) and vertical (dy) offsets to shift the camera view.
Pan the active viewport.
Args:
dx: Horizontal pan amount.
dy: Vertical pan amount.
| Name | Required | Description | Default |
|---|---|---|---|
| dx | No | ||
| dy | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It only says 'Pan the active viewport' without disclosing units, coordinate system, whether the pan is relative, side effects, or behavior when no viewport is active.
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?
The description is short and front-loaded, with no redundant filler. The Args section is minimal but directly labels the two parameters, making it efficient even if under-specified.
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?
Even though an output schema exists, the tool description omits critical invocation context: units for dx/dy and whether the pan is relative to the current view. An agent cannot reliably translate a user request like 'pan right 10 units' into correct numeric arguments.
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. It labels dx and dy as 'Horizontal pan amount' and 'Vertical pan amount', which adds minimal direction meaning, but it does not define units, sign conventions, or what an amount represents (pixels, model units, percentage).
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 specific action ('Pan') and a specific resource ('the active viewport'). This clearly sets it apart from siblings like rhino_zoom_extent or rhino_view_set, as no sibling targets panning.
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?
The description gives no guidance about when to use this tool versus alternatives, no mention of viewport prerequisites, and no exclusions. The intended use is only implied by the name and first line.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.