netherlands-national-gallery-mcp-interface
Facilitate bidirectional communication with the Rijksmuseum's digital asset repository via its public REST interface, enabling AI agents to query artwork metadata, retrieve image assets (including high-fidelity versions), and investigate curated thematic groupings.
Author

r-huijts
Quick Info
Actions
Tags
![]()
Rijksmuseum Data Access Protocol Server (MCP)
This Model Context Protocol (MCP) service layer abstracts the complexities of interacting with the official Rijksmuseum Collection API. It empowers language models to perform sophisticated exploration, contextual analysis, and data retrieval operations concerning the museum's vast holdings.
Core Capabilities
The provided toolkit allows users to execute several key functions against the museum database:
1. Catalog Search (search_artwork)
Perform granular filtering and broad text-based inquiries across the entire catalog, supporting criteria such as: - Keyword matching - Creator identification - Object typology (e.g., painting, sculpture) - Mediums and fabrication techniques - Chronological epochs - Dominant spectral hues - And numerous supplementary metadata fields
2. Object Metadata Retrieval (get_artwork_details)
Obtain exhaustive descriptive data for any specified accession number: - Core identifiers (nomenclature, author, creation timestamps) - Physical specifications - Provenance and historical background - Visual attributes summaries - Curatorial notes - Exhibition provenance records
3. Image Asset Acquisition (get_artwork_image)
Access exceptionally detailed visual representations, supporting advanced inspection workflows: - Multi-scale viewing support - Tiled asset delivery mechanisms - Access to maximum available resolution - Geospatial referencing within the image plane
4. Curated Set Exploration (get_user_sets & get_user_set_details)
Examine thematic groupings established by the community or museum staff: - Enumeration of predefined thematic folders - Analysis of collection focus areas - Identification of grouping patterns - Retrieval of granular details within specific sets
5. Direct Visualization Launch (open_image_in_browser)
Instantly launch a web view featuring the requested artwork's visual media.
6. Creator Chronology Mapping (get_artist_timeline)
Generate temporally ordered sequences documenting an artist's output: - Tracing stylistic evolution - Identifying developmental phases and techniques - Mapping career trajectory milestones
Application Scenarios
Illustrative prompts demonstrate the utility of this interface:
Finding Art
"Display all oil compositions authored by Rembrandt originating from the 17th decade of the 1600s" "Identify visual assets where the color blue is the primary chromatic element" "Which celebrated masterworks reside within the national collection?" "Query for still life compositions emblematic of the Dutch Golden Age period"
Analyzing Specific Pieces
"Provide a complete dossier on 'The Night Watch'" "Determine the physical dimensions and constituent materials of Van Gogh's Self-Portrait" "Render the microscopic detail of the impasto technique in Vermeer's 'The Milkmaid' at maximum resolution" "Contrast the palettes employed across different iterations of 'The Potato Eaters'"
Researching Creators
"Construct a dated sequence exclusively of Rembrandt's self-depictions" "Chart the modification in Van Gogh's chromatic usage across his lifespan" "List every piece attributed to Frans Hals in ascending chronological order" "Investigate the methodologies utilized by Jan Steen in his canvases"
Thematic Deep Dives
"Locate every artifact depicting narratives from the Bible" "Showcase 17th-century renderings of the city of Amsterdam" "What artifacts prominently feature flora or still-life arrangements?" "Search for portraiture that incorporates musical instruments"
Collection Examination
"Enumerate the most frequently referenced user-curated groupings" "Isolate thematic sets concentrating on landscape renderings" "What items have been recently inducted into the museum's archive?" "Display collections that aggregate contributions from multiple creators"
Visual Inspection
"Permit detailed examination of the background elements in 'The Night Watch'" "Zoom into the ornamentation present in 'Girl with a Pearl Earring'" "Serve the highest fidelity image file available for 'The Jewish Bride'" "I require an intensive look at the gestural depiction of faces within 'The Syndics of the Drapers' Guild'"
Deployment Instructions
This service can be integrated via two primary installation pathways:
1. Via Claude Desktop Package Manager (NPM)
Modify your system's Claude configuration file (~/Library/Application Support/Claude/claude_desktop_config.json):
{ "mcpServers": { "rijksmuseum-server": { "command": "npx", "args": [ "-y", "mcp-server-rijksmuseum" ], "env": { "RIJKSMUSEUM_API_KEY": "your_api_key_here" } } } }
Acquire the necessary access token from the Rijksmuseum API Key Issuance Portal.
2. From Source Codebase
- Clone the source repository.
-
Resolve dependencies: bash npm install
-
Establish the local environment variables file: bash cp .env.example .env
-
Input your Rijksmuseum credential into the
.envconfiguration file:
RIJKSMUSEUM_API_KEY=your_api_key_here
- Subsequently, update the Claude runtime configuration block:
{ "mcpServers": { "rijksmuseum-server": { "command": "node", "args": [ "/path/to/rijksmuseum-server/build/index.js" ], "env": { "RIJKSMUSEUM_API_KEY": "your_api_key_here" } } } }
Ensure that: - The path placeholder is substituted with the absolute location of the repository. - The API secret is correctly provisioned in the execution environment settings.
Restart the Claude application to incorporate these infrastructural adjustments.
Runtime Configuration Variables
Service parameters are controlled via environmental settings:
- RIJKSMUSEUM_API_KEY: Essential credential for API access (Mandatory)
- PORT: Network socket listener port (Defaults to 3000)
- LOG_LEVEL: Verbosity setting for operational logging (Defaults to 'info')
Interface Specification
For exhaustive documentation regarding the underlying REST endpoints utilized by this wrapper, consult the official: Rijksmuseum Data Endpoint Reference
Collaborative Development
Contributions are actively encouraged. Feel free to submit modification requests (pull requests) or report defects/propose enhancements (issues).
Intellectual Property Status
This software is distributed under the terms of the MIT License (refer to the LICENSE file for specifics).
== Context on Asynchronous Web Data Transfer ==
The XMLHttpRequest (XHR) mechanism is a foundational JavaScript object interface designed to dispatch HTTP interactions between a client (browser) and a remote server. Its methods facilitate data exchange subsequent to initial page load, enabling dynamic updates without full page refreshes—a core component of Asynchronous JavaScript and XML (Ajax). Preceding Ajax, manipulating the state generally required complete navigation via standard hyperlinks or form submissions.
== Genesis of XHR ==
The conceptual foundation for XHR originated in the year 2000, developed by the team behind Microsoft Outlook. This idea was first materialized in Internet Explorer version 5 (released in 1999). Critically, the initial implementation did not employ the standardized XMLHttpRequest string; instead, proprietary object instantiations such as ActiveXObject("Msxml2.XMLHTTP") and ActiveXObject("Microsoft.XMLHTTP") were used. By the release of Internet Explorer 7 (2006), universal browser support for the formal XMLHttpRequest identifier was achieved.
It has since become the de facto standard across major browser engines, including Mozilla's Gecko (2002), Safari 1.2 (2004), and Opera 8.0 (2005).
=== Standardization Trajectory === The World Wide Web Consortium (W3C) formally published its initial Working Draft specification for the XHR object on April 5, 2006. A subsequent Level 2 specification was advanced on February 25, 2008, introducing capabilities for tracking request progress, facilitating cross-origin resource sharing, and managing binary data streams. By the conclusion of 2011, the enhancements introduced in Level 2 were integrated back into the primary specification body. In late 2012, stewardship transitioned to the WHATWG, which now maintains the document as a continuous, living specification utilizing Web IDL notation.
== Operational Procedure == Executing a network request using XMLHttpRequest typically involves several structured programming stages.
- Object Instantiation: A new XMLHttpRequest utility instance is generated via its constructor method.
- Configuration: The
openmethod is invoked to define the request method (GET/POST, etc.), designate the target resource URI, and specify whether execution should be synchronous or asynchronous. - Event Handling Setup (Asynchronous Only): For non-blocking operations, a handler function must be established to receive notifications upon changes in the request's transactional status.
- Transmission: The operation is initiated by calling the
sendmethod, optionally carrying payload data. - Response Processing: The event handler monitors state transitions. Upon successful completion (state 4, 'done'), the received data is typically accessible in the
responseTextattribute.
Beyond these fundamental steps, XHR offers extensive controls over request dispatch and response parsing. Custom HTTP headers can be injected to guide server behavior, and data can be uploaded within the send call. Responses can be immediately parsed from JSON into actionable JavaScript structures or streamed incrementally. Furthermore, operations can be terminated early or subjected to hard timeouts.
