skkg-mcp

Overview Schema Source Related Servers Discussions Admin

skkg_get_record

skkg_get_record

Read-onlyIdempotent

Fetch a single non-object SKKG record, such as an actor, literature, exhibition, provenance period, object group, or address, with its summary and requested sections.

Instructions

Get one SKKG record other than an object, with the sections you ask for. Record types: actors (persons, institutions, and authors or publishers of literature), literature, exhibitions, provenance periods, object groups, and addresses of institutions. The summary is always included; its counts give the size of each section. Sections by type: actor: names, events, biography, relations, external (GND, Wikidata, other ids), literature (by and about them), objects; literature: objects (with page, figure, and catalogue number), provenance (periods it documents), about (persons and exhibitions it is about); exhibition: objects, literature, images; provenance: literature; objectgroup: objects; address: exhibitions. objects is paged with limit and offset; each object carries image_license (its primary image) and object_copyright (the object itself): quote both. SKKG's anonymisation ("Privatperson", "Unbekannte:r Eigentümer:in") is returned as it is; never try to identify those persons. For objects, use skkg_get_object; for vocabulary terms, skkg_find_terms with id.

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

Input Schema

Name	Required	Description	Default
`id`	Yes	Record id ("person/107", "literature/66", "exhibition/152", a UUID) or its data.skkg.ch IRI. A bare number or UUID that several record types share is refused; pass the prefixed id 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
`limit`	No	Objects per page of the `objects` section. Default 10
`offset`	No	First object of the `objects` page. Default 0
`include`	No	Sections besides the summary; which exist depends on the record type (see the description), or all. A section the type does not have, or one that is empty, is left out with a warning; `objects` stays, with total 0. Default: none

Output Schema

Name	Required	Description
`id`	Yes
`type`	Yes
`about`	No
`label`	No
`names`	No
`events`	No
`images`	No
`objects`	No
`summary`	Yes
`external`	No
`warnings`	No
`biography`	No
`relations`	No
`data_as_of`	No
`literature`	No
`provenance`	No
`exhibitions`	No
`website_url`	No	The record's page on digital.skkg.ch: for persons (with their works, for creators and influences) and exhibitions. Literature has no page there; the other types have none here

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.5.0Nov 13, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, and the description adds real context beyond that: the summary is always returned with `counts`, `objects` is paged, each object carries image_license and object_copyright that must be quoted, and anonymisation labels are returned verbatim rather than resolved. It does not discuss error surfaces or rate limits, keeping it short of a 5.

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 core action and record types, then flows into per-type section lists and finally the sibling routing. It is dense and long, but the enumeration of sections-per-type is load-bearing because the schema explicitly points there; only the paging sentence is close to redundant.

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 five-parameter, five-typed record getter with an output schema, the description covers scope, per-type section availability, default behavior, licensing obligations, and alternatives. An agent has everything needed to call it correctly without further inference.

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 baseline is 3, but the description adds the mapping the schema defers to it — which `include` values exist for actors, literature, exhibitions, provenance, objectgroups, and addresses. It adds little on `lang`, and its paging note simply restates limit/offset.

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 record") and immediately enumerates the record types covered, plus the negative scope ("other than an object"). It names the sibling to use for objects, so an agent can distinguish it from skkg_get_object 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?

Explicitly routes the agent away from this tool twice: "For objects, use skkg_get_object; for vocabulary terms, skkg_find_terms with `id`." It also gives conditional context (section sets differ by record type) and a behavioral rule for anonymised records, covering both when-to-use and when-not.

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

Deploy Server