rijksmuseum-mcp+

Overview Schema Source Related Servers Discussions Admin

Navigate Viewer

navigate_viewer

Zoom and pan an already-open viewer to a region, steering the user's view to a detail. Requires a viewUUID from a prior get_artwork_image call.

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.

Changed2 schema fields changedv0.90.2Oct 2, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

First observedv0.90.0Jul 4, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare the mutation/idempotency profile; the description adds concrete behavior: out-of-bounds regions rejected with an overlay_region_out_of_bounds warning, batch limit under 10 commands, a 30-minute idle session timeout reset by polling, and the three deliveryState outcomes including guidance not to narrate queued as failure. This is substantial context beyond the structured fields.

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

Conciseness4/5

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

It is long, but front-loaded with the routing decision first, then coordinate formats, then response semantics. Nearly every sentence carries operational value; a small amount of the region-format list duplicates the schema wording.

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?

Complete for a command-batch mutation tool: prerequisites (viewUUID, viewer open), coordinate semantics, error handling, rate/batch limits, and delivery-state interpretation are all covered, so nothing an agent needs to call it correctly is missing.

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

Parameters4/5

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

Schema coverage is already 100%, so the baseline is 3, but the description adds real meaning: default full-image coordinate space, the relativeTo exception, and a worked mapping showing the same pct string targets the same area in viewer and inspect_artwork_image. This goes beyond the schema text.

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?

States a specific verb+resource ('Zooms/pans an already-open viewer to a region') and explicitly names the two siblings it is not: get_artwork_image for opening, inspect_artwork_image for analysis. An agent can distinguish it from every sibling without opening a schema.

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?

Gives explicit when-not guidance ('In most cases you do NOT need this tool') and the precise condition that selects it ('only to move the user's view WITHOUT fetching image bytes'). The alternatives are named with the case each covers.

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

Deploy Server