skkg-mcp

Overview Schema Source Related Servers Discussions Admin

skkg_get_object

skkg_get_object

Read-onlyIdempotent

Retrieve one SKKG collection object by id, link, or inventory number and return chosen sections such as provenance, acquisition, materials, exhibitions, and images with their rights.

Instructions

Get one SKKG object by id or inventory number, with the sections you ask for. The summary and the rights block are always included. Sections: production (creators, techniques, dating and its basis), physical (materials, parts with dimensions, inscriptions, condition), texts (SKKG's descriptions), acquisition (how, when, from whom and for how much SKKG acquired it), provenance (the ownership chain before SKKG, where one is recorded), exhibitions, literature, related (parent, parts, references, groups), images (each image with its rights and IIIF service; to look at one, pass its id to skkg_inspect_image), or all. Quote both rights: object_copyright is the object's own status, image_license the primary image's. live: true checks the rights against SKKG's API (one request), and says what differs from the dump. Lists longer than 50 are cut and say so in warnings. To find objects, use skkg_search_objects.

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_get_object"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	Object id ("object/1014", "1014", a UUID), its data.skkg.ch or website link, or its inventory number ("884", "GB-0171.1"). A number that is one object's id and another's inventory number is refused; pass "object/…" then
`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
`live`	No	Also fetch the object from SKKG's API and compare its credit line, redaction status, images, and image rights with the dump. The API has no object copyright. Default: false
`include`	No	Sections besides the summary: production, physical, texts, acquisition, provenance, exhibitions, literature, related, images, or all. Default: none

Output Schema

Name	Required	Description
`id`	Yes
`live`	No	Only with live: true
`type`	Yes
`texts`	No
`title`	No
`images`	No
`rights`	Yes
`related`	No
`summary`	Yes
`physical`	No
`warnings`	No
`data_as_of`	No
`literature`	No
`production`	No
`provenance`	No
`acquisition`	No
`exhibitions`	No
`website_url`	No
`manifest_url`	No	IIIF Presentation 3 manifest
`inventory_number`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.5.0Nov 13, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare a safe, idempotent read, but the description adds substantial behavior: summary and rights are always returned, live=true triggers exactly one API request and reports diffs against the dump, and lists over 50 are truncated with a warning. It also clarifies a real pitfall — that the API has no object copyright — which no annotation conveys.

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 alternatives, and every sentence carries information. It is a single dense paragraph with heavy parenthetical nesting, which makes the section list harder to scan than it needs to be.

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 four-parameter read tool with an output schema, the description covers the remaining unknowns: truncation limits, warnings, the live-comparison cost, and rights interpretation. Nothing an agent needs in order 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.

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 goes beyond the schema by explaining what each section actually contains (e.g. acquisition = how/when/from whom/for how much) and by telling the agent to interpret object_copyright vs image_license separately. That is genuine added meaning, not restatement.

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 ("Get one SKKG object") plus the keying options (id or inventory number) and the section scoping. It explicitly separates itself from skkg_search_objects, so an agent can pick the right tool without opening either 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?

Names two alternatives with conditions: "To find objects, use skkg_search_objects" and "to look at one [image], pass its id to skkg_inspect_image." That covers the main routing decisions an agent faces for this resource family.

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

Deploy Server