rijksmuseum-mcp+

Overview Schema Source Related Servers Discussions Admin

Navigate Viewer

navigate_viewer

Zooms or pans an already-open artwork viewer to a specified region, steering the user's view to a detail without fetching image bytes for analysis.

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 cropRegion of an inspect that used a pct: region (only pct:x,y,w,h is accepted) 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

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

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.

Changed1 schema field changedv0.90.4Oct 31, 2026

changedInput schema / properties / commands / items / properties / relativeTo / description

Previous value: -"Crop region from a prior inspect_artwork_image call. When provided, 'region' is interpreted as coordinates within that crop's local space and projected to full-image space by the server. Use pct: region values directly, or crop_pixels: values with relativeToSize from inspect_artwork_image."New value: +"pct:x,y,w,h crop region from a prior inspect_artwork_image call that used a pct: region. When provided, 'region' is interpreted as coordinates within that crop's local space and projected to full-image space by the server. Use pct: region values directly, or crop_pixels: values with relativeToSize from inspect_artwork_image."

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.9/5.0

Behavior5/5

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

Annotations only mark it non-read-only, non-idempotent, non-destructive; the description adds the operational context annotations cannot carry — 30-minute idle session expiry reset by polling/navigation, a <10 commands-per-call batch limit, out-of-bounds rejection with the exact `overlay_region_out_of_bounds` warning and retry advice, and interpretation of the three deliveryState values (including that queued is not a failure). This is well beyond the annotation bar.

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?

Front-loaded with purpose and the 'you probably don't need this' caveat, then organized under region-format headings and a closing deliveryState paragraph — good scannability. Slightly long, with the region formats enumerated once in a list and re-explained in the coordinate-shortcut paragraph, which is mild redundancy but each block is useful on its own.

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 stateful, session-bound navigation tool this covers everything an agent needs to call it correctly: prerequisites, coordinate spaces, batch limits, failure modes, session lifetime, and how to interpret the response. The output schema exists, and the description still supplies the interpretive meaning of deliveryState that the schema alone would not convey.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds genuine semantic depth the schema does not: default full-image coordinate space, the relativeTo/relativeToSize exception for crop-local space, the meaning of each region format including the legacy bare 'x,y,w,h' form, and the note that pct: regions match inspect_artwork_image identically.

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 and resource ('Zooms/pans an already-open viewer to a region') and immediately contrasts with both relevant siblings: get_artwork_image opens viewers, inspect_artwork_image performs analysis. An agent can distinguish this tool 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?

Explicitly routes usage: 'In most cases you do NOT need this tool' because inspect_artwork_image auto-zooms; call navigate_viewer 'only to move the user's view WITHOUT fetching image bytes.' It names the prerequisites (viewUUID from get_artwork_image, viewer must be open) and both exclusions with their alternatives.

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

Deploy Server