rijksmuseum-mcp+

Overview Schema Source Related Servers Discussions Admin

Navigate Viewer

navigate_viewer

Zoom or pan an already-open artwork viewer to a specific region, directing the user's view to a detail without fetching new image data.

Instructions

Zooms/pans an already-open viewer to a region. Steer the user's view to a detail. Requires a viewUUID from a prior get_artwork_image call (the viewer must be open). Not for opening the viewer — use get_artwork_image. Not for visual analysis — use inspect_artwork_image.

In most cases you do NOT need this tool: inspect_artwork_image already auto-zooms the open viewer to whatever region it inspects. Call navigate_viewer only to move the user's view WITHOUT fetching image bytes for your own analysis.

By default, region coordinates are in full-image space (percentages or pixels of the original image), not relative to the current viewport. The same pct:x,y,w,h used in inspect_artwork_image will target the identical area in the viewer. Exception: when a command includes relativeTo, region is interpreted in that inspected crop's local coordinate space.

Region formats:

'pct:x,y,w,h' — percentage of full image.
'crop_pixels:x,y,w,h' — pixel coordinates of the full image. Use nativeWidth/nativeHeight returned by inspect_artwork_image to bound values. When used with relativeTo + relativeToSize, crop_pixels is instead interpreted as pixels within that inspected crop.
'x,y,w,h' — equivalent to crop_pixels: (legacy IIIF form, kept for compatibility).
'full' | 'square' — whole image shortcuts.

Out-of-bounds regions are rejected with an overlay_region_out_of_bounds warning — correct the coordinates and retry. Keep batches under 10 commands per call. The viewer session (viewUUID) remains active for 30 minutes of idle inactivity — any polling or navigation resets the clock.

Coordinate shortcut: to zoom to a region of a prior inspect_artwork_image crop, use 'relativeTo' with the crop's region string and specify 'region' as coordinates within the crop's local space; the server projects to full-image space deterministically. Use pct:x,y,w,h for crop-local percentages, or crop_pixels:x,y,w,h plus relativeToSize:{width: cropPixelWidth, height: cropPixelHeight} from inspect_artwork_image for crop-local rendered pixels.

Response field deliveryState reports whether the iframe drained the commands immediately (delivered_recently), the iframe exists but hasn't polled recently and the commands are queued (queued_waiting_for_viewer — typical when scrolled out of view), or no iframe has connected yet (no_live_viewer_seen). In the queued case, the command is preserved server-side and will apply automatically when the viewer resumes polling — do not narrate this as a delivery failure to the user.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`commands`	Yes	Zoom/pan commands to execute in the viewer, in order
`viewUUID`	Yes	Viewer UUID from a prior get_artwork_image call

Output Schema

TableJSON Schema

Name	Required	Description
`error`	No
`queued`	Yes
`viewUUID`	Yes
`imageWidth`	No
`imageHeight`	No
`lastPolledAt`	No	ISO timestamp of the iframe's last poll. Absent if the iframe has never polled this session.
`objectNumber`	No	Object number of the artwork in this viewer session — gives a structuredContent reader the identity needed for a follow-up call without parsing prose.
`deliveryState`	No	Server's view of command delivery: delivered, queued for an existing-but-offscreen viewer, or no viewer ever connected.
`regionRecovery`	No	Out-of-bounds recovery hint. Present only on an `overlay_region_out_of_bounds` error — mirrors the recovery payload the text channel renders, so a structuredContent reader can self-correct without parsing prose.
`pendingCommandCount`	No	Commands sitting in the queue that the iframe has not yet drained.
`recentlyPolledByViewer`	No	True if the iframe polled within the last 5s.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.90.0Jul 4, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations provide no safety signals (readOnlyHint=false, destructiveHint=false), so the description carries the full behavioral burden. It thoroughly discloses the coordinate space defaults, out-of-bounds rejection behavior, the 10-command batch limit, the 30-minute viewer session timeout, and the queued vs. delivered deliveryState semantics. No annotation contradiction exists.

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 long, but the tool has genuinely complex coordinate semantics. It is front-loaded with the core purpose, then clear exclusions, followed by well-organized sections for formats, errors, limits, session behavior, and delivery states. Each sentence contributes necessary operational detail; this is appropriately sized for the complexity.

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 two required parameters, intricate coordinate space rules, and delivery-state nuances, the description is complete. It covers prerequisites, alternatives, coordinate formats, error handling, batching limits, session expiry, and response-field interpretation, leaving no critical gap for an agent to call it correctly.

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

Parameters5/5

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

Although the input schema covers all parameters, the description adds substantial meaning beyond it: every region format is explained ('pct', 'crop_pixels', legacy 'x,y,w,h', 'full', 'square'), the relativeTo coordinate projection is clarified, and relativeToSize is tied to inspect_artwork_image's cropPixelWidth/cropPixelHeight. This goes well beyond the schema descriptions.

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 and resource ('Zooms/pans an already-open viewer to a region') and immediately differentiates it from sibling tools: it is not for opening the viewer (use get_artwork_image) and not for visual analysis (use inspect_artwork_image). An agent can distinguish it from its siblings without inspecting schemas.

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?

The description gives explicit when-to-use and when-not-to-use guidance, including the important note that 'in most cases you do NOT need this tool' because inspect_artwork_image already auto-zooms. It also names alternatives and the prerequisite (viewer must be open from a prior get_artwork_image call).

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

Deploy Server