skkg-mcp

Overview Schema Source Related Servers Discussions Admin

skkg_view_image

skkg_view_image

Read-onlyIdempotent

Opens a zoomable, pageable viewer showing an object's published images or a single image from the SKKG collection, with rights and licence information displayed.

Instructions

Show SKKG images to the user in a zoomable viewer they can page through. Pass an object id for all its published images, primary first in the order of skkg_get_object, with index for the image to open first, or an image id ("multimedia/…") for that image alone. The viewer appears beside the result in clients that support MCP Apps, and shows each image's rights. Nothing comes back for you to look at. The viewer is for the user; to look at an image yourself, call skkg_inspect_image with its id. If the user says no viewer appeared, give them website_url as a plain link; never embed an image URL as Markdown. Quote both rights: image_rights.image_license is the image's, each object's object_copyright its own.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "skkg_view_image"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	An object id ("object/1014", an inventory number, a website link) for its images, or an image id ("multimedia/…") from skkg_get_object or skkg_get_record
`lang`	No	Language of vocabulary labels. Most vocabularies, materials and object types among them, have German labels only, which are returned whatever the language; titles and texts stay as recorded	de
`index`	No	With an object id: the image to open first, 1 being the primary, in the order of skkg_get_object's images. Default 1

Output Schema

Name	Required	Description
`id`	Yes	The object or image id the viewer opened
`type`	Yes
`images`	Yes	The images sent to the viewer, in order
`objects`	Yes	The object, or for an image id the objects it belongs to
`warnings`	No
`data_as_of`	No
`image_count`	Yes	Published images of the object; 1 for an image id
`start_index`	Yes	The image the viewer opens first, counted in `index`
`image_rights`	Yes	Each distinct set of image rights once; images point to one with rights_set
`object_count`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.5.0Nov 13, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, it discloses the key non-obvious trait that "Nothing comes back for you to look at," that the viewer only renders in clients supporting MCP Apps (so the agent knows rendering may silently fail), and that each image's rights are shown. These are behavioral facts the annotations cannot express.

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 the action and viewer behavior, then usage routing, then fallbacks. It is dense but nearly every clause carries a distinct instruction; the trailing rights-quoting rule is the one piece that feels appended rather than integrated.

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?

Despite having an output schema, it still flags the crucial fact that no readable content is returned, which an agent could otherwise misread from the schema alone. Combined with id-form guidance, ordering semantics, and the no-viewer fallback, nothing needed to invoke 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 100%, so the schema already documents all three parameters; the description adds relational meaning by tying `index` to "the order of skkg_get_object, primary first" and by explaining that an object id yields all published images while a "multimedia/…" id yields that image alone.

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?

Specific verb and resource: "Show SKKG images to the user in a zoomable viewer they can page through." It immediately distinguishes itself from the sibling skkg_inspect_image by being a user-facing viewer rather than an agent-facing image read.

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?

Explicit routing is given both ways: use this to show the user an image, but "to look at an image yourself, call skkg_inspect_image with its id." It also covers the fallback case ("If the user says no viewer appeared, give them website_url as a plain link") and a formatting prohibition ("never embed an image URL as Markdown").

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

Deploy Server