rijksmuseum-mcp+

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.90.0
Disambiguation5/5
Each tool targets a distinct action or data aspect: image viewing vs. inspection, metadata vs. bibliography vs. conservation history, set listing vs. member enumeration, etc. The two internal viewer tools are clearly marked as internal, causing minimal ambiguity.
Naming Consistency5/5
All tool names follow the verb_noun pattern (e.g., browse_set, get_artwork_details, search_artwork) with no mixing of conventions. Names are descriptive and predictable.
Tool Count5/5
13 tools for a museum collection server is well-scoped. Each tool serves a clear purpose without redundancy, and the count covers core interactions (search, details, images, bibliography, conservation, sets, recent changes) without being overwhelming.
Completeness4/5
The tool surface covers the primary workflows: artwork discovery (search_artwork, list_curated_sets), metadata retrieval (get_artwork_details, bibliography, conservation), image viewing (get_artwork_image, inspect_artwork_image), and updates (get_recent_changes). Missing are semantic search, person search, and provenance search, though some are referenced as separate tools; this is a minor gap given the depth of existing tools.
Average 4.5/5 across 13 of 13 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- 3 of 3 community issues answered or closed in the last 6 months
- 319 commits in the last 12 weeks
- Last stable release on June 24, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so description must disclose behavior. It does not clarify if polling is blocking or non-blocking, what happens on no commands, or any side effects. Polling typically implies non-destructive reads, but annotations contradict by setting readOnlyHint to false, creating ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) and front-loaded with 'Internal:', which is useful. However, it sacrifices necessary detail for brevity, making it insufficient for an agent to use correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one param) and existence of an output schema, the description still falls short. It fails to explain the return format, polling behavior, or how it fits with sibling tools like 'navigate_viewer' or 'remount_viewer'. Essential context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the required parameter 'viewUUID'. It does not, leaving the agent to guess its purpose (likely a viewer identifier). No constraints or format details are provided.
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?
The description clearly identifies the tool's purpose: polling for pending viewer navigation commands. The verb 'poll' and resource 'pending viewer navigation commands' are specific and distinguish it from siblings like 'navigate_viewer' which triggers navigation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks guidance on when to use this tool versus alternatives. The prefix 'Internal:' hints at restricted usage but does not explain polling behavior, repetition, or context (e.g., after navigating). No exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (destructiveHint=false, etc.). The description adds that 'Any user highlight is cleared on remount', which is a side effect beyond what annotations provide. This helps the agent understand the tool's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose, context, side effect. No unnecessary words. Information is front-loaded and earned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 params and an output schema, the description covers purpose, invocation context, and a side effect. It could mention error cases (e.g., invalid viewUUID) but is otherwise complete for a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds little beyond schema: it mentions 'preserving viewUUID' which reinforces viewUUID's role, but does not add new semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'switch the viewer to a different artwork while preserving the viewUUID', which is a specific verb+resource. It distinguishes itself by noting it is internal and called during in-viewer navigation, but does not explicitly differentiate from sibling 'navigate_viewer'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Called by the artwork-viewer iframe during in-viewer related navigation', implying usage context, but provides no exclusion criteria or alternatives. Sibling 'navigate_viewer' exists but no guidance on when to use which.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat these. However, it adds value by listing the types of data returned (technical examinations, conservation events, inscription count, provenance excerpt). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at 6 sentences, well-structured with purpose first, then content, then exclusions. No filler or redundant information.
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?
Given the output schema exists, the description adequately conveys what the tool returns without needing to detail the output structure. The single parameter is thoroughly documented in the schema, and the context signals show high coverage. The description is complete for an agent to understand and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% already describing objectNumber. The description adds context that the tool is accessed by objectNumber after a search, but does not provide new semantic details beyond what the schema already includes.
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?
The description clearly states it provides conservation/forensics record for one artwork, specifying technical examinations and restoration treatment history. It distinguishes itself from siblings by listing what it returns and what it does not (e.g., not general metadata, not transcribed inscriptions).
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 states when to use: follows get_artwork_details or a search result by objectNumber. Provides clear exclusions with alternative tools: use get_artwork_details for general metadata, search_inscriptions for transcribed inscriptions, and collection_stats for aggregate counts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds useful context about deleted records being flagged with 'deleted:true' and pagination via resumptionToken, going beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, and every sentence adds necessary information. No redundant or verbose content.
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?
Given the output schema exists and annotations are present, the description covers purpose, filtering, pagination, deleted records, and follow-up usage. It is complete for the tool's complexity.
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 already covers all 6 parameters with 100% description. The description adds value by explaining the effect of identifiersOnly, the presence of objectNumber for follow-up, and that resumptionToken overrides other filters.
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?
The description clearly states the tool as an 'OAI-PMH delta feed' for records changed within a date range, paginated, with options for identifiers-only and handling of deleted records. It distinguishes from sibling tools like get_artwork_details by mentioning follow-up usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides specific guidance on when to use identifiersOnly=true for lightweight listing and mentions follow-up tools. However, it lacks explicit alternatives or when-not-to-use compared to other tools like search_artwork.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and idempotentHint=true. Description adds performance info (DB-backed, tens of ms), resumptionToken portability limitations, and notes that includeExtentText is large. Does not cover error cases or rate limits, but adds meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet comprehensive, with clear structure: purpose, performance, return fields, linking to other tools, and pagination details. Every sentence adds value.
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?
Given the tool's complexity (4 parameters, output schema exists), the description covers all essential aspects: input, output fields, pagination, and connections to sibling tools. No gaps identified.
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?
Parameters have 100% schema coverage, so baseline is 3. The description adds value by explaining that setSpec comes from list_curated_sets, resumptionToken is stateless and not portable across upgrades, and includeExtentText defaults false and is large.
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?
The description clearly states the tool enumerates member artworks of a curated set by setSpec, using a specific verb and resource. It distinguishes itself from sibling tools like list_curated_sets and get_artwork_details.
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 states to obtain setSpec from list_curated_sets, explains pagination via resumptionToken, and directs to use get_artwork_details for multi-row vocabularies. Clearly says 'Not for set discovery — use list_curated_sets first.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that not all artworks have images, returns metadata and viewer link (not bytes), and advises against constructing IIIF URLs manually. Annotations are all false (no special behavior), and description adds valuable context beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with purpose, then usage rules, then additional notes. No redundant or vague language.
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?
Given the tool has only one required parameter and an output schema exists, the description fully covers usage context, limitations, and differentiation from sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter (objectNumber) already described. Description does not add new semantic information beyond restating 'object number' in context. Baseline score of 3 is appropriate.
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?
Explicitly states it opens an interactive deep-zoom viewer for 'see/show/view' requests, and distinguishes from inspect_artwork_image which is for LLM visual analysis. Verb and resource are specific.
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?
Provides explicit when-to-call (user wants to see, show, view) and when-not-to-call (list, summary, count, text-only). Names alternative tool inspect_artwork_image for visual analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive. Description adds rich behavioral context about result shape (category heuristic, memberCount) and pairing with browse_set. No contradictions. Minor gap: no mention of pagination or rate limits, but sufficient given annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise paragraph with front-loaded purpose. Every sentence adds value: purpose, result details, usage tip, pair suggestion, exclusions. No redundancy.
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?
Given 5 parameters, 1 enum, and presence of output schema, the description covers purpose, usage scenarios, result attributes, parameter tips, and sibling relationships comprehensively. Adequate for an AI agent to correctly select and invoke.
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 description coverage is 100%, so baseline is 3. Description adds operational guidance beyond schema, e.g., using minMembers/maxMembers to filter umbrella sets and examples for query parameter, justifying a 4.
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?
The description clearly states the tool browses thematic and sub-collection groupings curated by staff, listing specific result attributes (memberCount, dominantTypes, etc.) and distinguishing from sibling tools like browse_set, search_artwork, and collection_stats.
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 provides when to use (for thematic groupings) and when not (for keyword search or aggregate counts). Includes practical advice on parameter values (minMembers/maxMembers) to avoid umbrella sets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, non-destructive. The description adds substantial behavioral context: requires at least one filter, no full-text search, AND-combined arrays, warnings for shared object-number prefixes, ranking behavior, and follow-up calls. No contradiction with annotations.
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?
The description is well-structured with clear sections and front-loaded purpose. While somewhat lengthy, every sentence adds value given the tool's complexity. Could be slightly more concise but remains organized and informative.
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?
Given the tool's complexity (19 parameters, output schema exists), the description covers all essential aspects: when to use, filtering semantics, ranking, warnings, follow-up calls, and relationships to sibling tools. It is comprehensive and leaves no significant gaps.
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 description coverage is 100%, so baseline is 3. The description adds value beyond the schema by explaining overall parameter interaction (e.g., sort vs BM25, groupBy behavior, combining filters) and providing best practices for using certain parameters like subject and description.
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?
The description clearly states it is a 'Structured filter search' for artworks matching all given filters, returning summaries with totalResults. It explicitly distinguishes from siblings by specifying not for free-text concept queries (use semantic_search), not for artwork similarity (use find_similar), etc.
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?
The description provides comprehensive guidance on when to use this tool versus alternatives, including search_persons, search_provenance, collection_stats, semantic_search, and find_similar. It also explains when to prefer subject over description and gives specific usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds key behavioral details: 'Local and resolver-free' and default behavior (first 20 + total count) as explained in the 'full' parameter. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences and a short note, all front-loaded with essential information. No wasted words; every sentence adds value.
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?
Given the relative complexity (reverse lookup), presence of output schema, and clear annotations, the description covers how to obtain the input, default behavior, and exclusions. It is complete enough for an agent to select and invoke correctly.
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 baseline is 3. The description adds meaningful context: example URI for publication, and explanation of the 'full' parameter's effect on result set size. This elevates the score.
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?
The description explicitly states 'Reverse bibliography lookup' with a specific verb and resource, and clearly distinguishes from sibling tools like search_artwork by saying 'Not for topic search of the library catalogue.'
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 tells when to use: 'Use the publicationUri from get_artwork_bibliography'. Also states what not to use: 'Not for topic search of the library catalogue.' Provides clear context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses default pagination (first 5 + total count), the full=true option, and warns about large context windows, adding significant behavioral context beyond the readonly and idempotent annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words; front-loaded with purpose, followed by usage context and a key caveat. Every sentence earns its place.
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?
Covers what is returned, usage context, default pagination, and warnings. With an output schema present, no need to detail return format. Complete for the tool's complexity.
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%, but description adds practical context: the default behavior for 'full' parameter and a warning about context window, going beyond the schema description.
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?
The description clearly states it provides scholarly references for one artwork by objectNumber, and distinguishes from siblings by stating what it is not for (general metadata or library-catalogue search).
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 says it follows a search_artwork/get_artwork_details result, and lists exclusion cases (not for general metadata, not for library-catalogue search), providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as readOnly, idempotent, non-destructive. Description adds extensive details on return content, including structure of relatedObjects, authority IDs at two levels, and timestamps. No contradictions.
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?
Description is verbose but front-loaded with purpose and usage. The extensive field list is justified for a rich metadata tool, though could be slightly more concise.
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?
Given the tool's complexity, output schema presence, and 100% schema coverage, the description is complete: covers parameters, return values, and usage context thoroughly.
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%. Description adds clarity: exactly one of objectNumber or uri must be provided, gives example 'SK-C-5', explains verboseExtent defaults to false and structured dimensions suffice. This adds significant meaning beyond the schema.
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?
The description clearly states the tool gets full metadata for ONE artwork by objectNumber or URI. It lists the specific fields and distinguishes itself from siblings like search_artwork, find_similar, and collection_stats.
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 states when to use: after search_artwork/semantic_search/find_similar, or given an objectNumber. Also states when not to use: not for filter discovery (use search_artwork), not for similarity (use find_similar), not for aggregates (use collection_stats).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context: base64 return, crop dimensions in response, and viewer navigation behavior without contradiction.
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?
Well-structured with clear paragraphs, but slightly lengthy. Front-loaded core purpose. Each sentence adds value, but could be tightened.
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?
Given 7 parameters and output schema, the description covers all aspects: region types, size constraints, quality use cases, viewer integration, and multi-panel handling.
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 description coverage is 100%, but the description adds significant value: explains region formats with examples, size rationale (28 multiples for LLM), quality 'gray' for inscriptions, and iterative zoom strategy.
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?
The description clearly states the tool returns image bytes for LLM visual analysis, distinguishing it from get_artwork_image (for users) and search_artwork (for listing). The verb 'inspect' with object 'artwork image' is specific and informative.
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 states when NOT to use the tool (use get_artwork_image for user viewing, search_artwork for listing). Provides detailed guidance on region selection, iterative zoom strategy, and viewer synchronization.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes far beyond annotations: explains region formats, out-of-bounds warning, batch size limit (10), session timeout (30 min), deliveryState field. Details coordinate projection with relativeTo. Annotations only indicate mutating but not destructive, and description adds comprehensive behavioral context.
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?
Well-structured with front-loaded purpose and guidelines, but relatively lengthy due to detailed coordinate explanations. Every sentence earns its place, though could be slightly condensed without losing clarity.
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?
Covers all necessary aspects: when to use, coordinate formats, error handling, limits (batch, session), response interpretation. Given the complexity of coordinate projection, the description is thorough and leaves no gaps for an agent.
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%, yet description adds significant meaning: explains coordinate systems in detail, interrelation between region and relativeTo, and usage examples. Every parameter's purpose and constraints are elaborated beyond schema definitions.
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?
Clearly states the tool zooms/pans an already-open viewer, with specific verb and resource. Distinguishes from siblings by explicitly saying what it is not for (opening: use get_artwork_image; visual analysis: use inspect_artwork_image).
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 states when to use (only to move view without fetching image bytes) and when not (most cases not needed because inspect_artwork_image auto-zooms). Provides alternative tool names and detailed guidance on coordinate systems and relativeTo usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![rijksmuseum-mcp-plus MCP server](https://glama.ai/mcp/servers/kintopp/rijksmuseum-mcp-plus/badges/card.svg)](https://glama.ai/mcp/servers/kintopp/rijksmuseum-mcp-plus)

Score Badge

Copy to your README.md:

[![rijksmuseum-mcp-plus MCP server](https://glama.ai/mcp/servers/kintopp/rijksmuseum-mcp-plus/badges/score.svg)](https://glama.ai/mcp/servers/kintopp/rijksmuseum-mcp-plus)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kintopp/rijksmuseum-mcp-plus'

If you have feedback or need assistance with the MCP directory API, please join our Discord server