open-museum-mcp

One search across open-access museum collections worldwide, with strict per-museum rights verification and ready-to-use citations.

The Met, Rijksmuseum, the Smithsonian, Cleveland Museum of Art, the Art Institute of Chicago, SMK (National Gallery of Denmark), the Walters, Wellcome Collection, Wikimedia Commons, and Europeana — searched together, returned in one normalized shape, with the rights gate enforced per museum so you never receive a record whose open-access status is missing or ambiguous. The list keeps growing.

See it in action first → pramod.ch/open-museum-mcp — three worked examples (cross-tradition pairing, date-windowed scan, counterpoint discovery), real records, real citations, no install required.

Who this is for

• Art-history students and researchers who need cited references and rights-cleared images for papers, slides, and theses — across institutions, in one query.

• Writers, educators, and journalists who want reuse-safe artwork to pair with essays, lessons, or articles, with pre-formatted attributions.

• MCP / agent builders who want a small set of high-value tools (search_artworks, get_artwork, cite) with consistent schemas across sources, instead of installing one MCP per museum.

Related MCP server: webfetch

Why I built this

I kept wanting reuse-safe artwork for my writing, and every museum's rights model is different. So I built one MCP interface that only returns records that pass per-museum verification rules, with strict deny on ambiguity. It lets me search by artist, period, region, and other fields, and pulls the image and description back in one normalized shape.

If anyone else is exploring open-access art, I hope this helps. The plan is to keep adding museums from around the world.

How this is different from single-museum MCPs

There are excellent single-museum servers (metmuseum-mcp, rijksmuseum-mcp, smithsonian-mcp). This one is the multi-museum entry point: install once, query across all sources at the same time, get a single normalized schema across them, with a license gate you can audit per museum in src/licenseGate.ts. If you only ever need one collection, install that museum's MCP. If you want comparisons across institutions, citations across periods, or rights-verified breadth — install this.

What you get

• Many museums, one query. The Met, Rijksmuseum (direct), the Smithsonian, Cleveland, the Art Institute of Chicago, SMK (National Gallery of Denmark), the Walters, Wellcome Collection, the National Gallery of Art (Washington), Harvard Art Museums, the J. Paul Getty Museum, Wikimedia Commons, and Europeana are live — keyless where the museum allows it, opt-in via a free API key where required — and the list keeps growing.

• Strict deny on ambiguity. Records are validated against per-museum rights rules in code. Missing or unclear indicators drop the record; nothing is defaulted to "open".

• Catalog-grade metadata. A dynasty-aware date parser handles Tang, Edo, Safavid, Mughal and the rest. Regions normalize across museums. Attribution separates named artists from anonymous, workshop, "after", and attributed works. Date-range filter on search_artworks for queries like Dutch genre painting 1640–1680.

• Citation-ready output. Three citation styles (full, caption, short) generated deterministically from the same record — paste straight into a paper, a slide caption, or an inline reference.

• Listable resources. museum://{code}/{id} resources let you bookmark interesting IDs across a session.

Quick example

A search call returns license-verified results in one normalized shape:

// Tool call: search_artworks({ query: "van gogh wheat", museum: "met", limit: 1 })
{
  "count": 1,
  "results": [
    {
      "id": "met:436535",
      "museum": {
        "code": "met",
        "name": "The Metropolitan Museum of Art",
        "url": "https://www.metmuseum.org"
      },
      "title": "Wheat Field with Cypresses",
      "artist": {
        "name": "Vincent van Gogh",
        "nationality": "Dutch",
        "lifespan": "1853–1890",
        "attributionType": "named"
      },
      "displayDate": "1889",
      "yearStart": 1889,
      "yearEnd": 1889,
      "medium": "Oil on canvas",
      "region": "netherlands",
      "period": null,
      "imageUrls": { "full": "https://images.metmuseum.org/..." },
      "imageOpenAccess": true,
      "metadataOpenAccess": true,
      "license": {
        "type": "CC0",
        "rawValue": "true",
        "verificationSource": "met.isPublicDomain",
        "verifiedAt": "2026-04-25T12:00:00.000Z",
        "confidence": "high"
      },
      "source": {
        "apiUrl": "https://collectionapi.metmuseum.org/public/collection/v1/objects/436535",
        "pageUrl": "https://www.metmuseum.org/art/collection/search/436535"
      }
    }
  ]
}

Install

Want to see it work before installing? pramod.ch/open-museum-mcp walks through the three core workflows with real records and citations.

One-click

For supported clients, no JSON, no Node, no npm — pick your client:

• Claude Desktop: Download open-museum-mcp.mcpb from the latest release and double-click it. Claude Desktop opens the bundle and installs the server in one step.

• VS Code: Install in VS Code — opens VS Code with the install dialog prefilled (requires the GitHub Copilot Chat extension).

• Cursor: Install in Cursor — same idea, Cursor-flavoured (MCP support is built in).

JSON config (any MCP client)

For ChatGPT with MCP, Cline, Goose, Continue, Zed, or anything else: paste this into your client's MCP config and restart. npx fetches and runs the server on first launch.

{
  "mcpServers": {
    "open-museum": {
      "command": "npx",
      "args": ["-y", "open-museum-mcp"]
    }
  }
}

From source (for contributors)

git clone https://github.com/cfpramod/open-museum-mcp
cd open-museum-mcp
npm install
npm run build

Then point the MCP config at the built binary:

{
  "mcpServers": {
    "open-museum": {
      "command": "node",
      "args": ["/absolute/path/to/open-museum-mcp/dist/server.js"]
    }
  }
}

Recipes

Once installed, paste one of these into your MCP client (Claude Desktop, ChatGPT with MCP, etc.) — the tools take care of the rest.

Cross-tradition pairing for an essay or slide deck

Find a 17th-century Dutch genre painting and a same-period work from East Asia I can pair as a comparison. Return citations in caption form for both.

The agent will call search_artworks with year_min: 1600, year_max: 1700 plus your two queries, then cite(id, "caption") on the picks.

Date-windowed research scan

Show me Dutch genre painting between 1640 and 1680. Six works, full citations, prefer different artists.

search_artworks({ query: "Dutch genre painting", year_min: 1640, year_max: 1680, limit: 6 }) then cite per result.

Counterpoint to a canonical work

Suggest a non-canonical Edo-period work to pair with Vermeer's Woman Holding a Balance. Explain the contrast.

search_artworks for Vermeer, then discover_random({ region: "japan", period: "edo" }) for the counterpoint, then prose from the agent grounded in both records' metadata.

Tools

cite example outputs

For Van Gogh's Wheat Field with Cypresses (met:436535):

caption: "Vincent van Gogh, Wheat Field with Cypresses, 1889. Oil on canvas.
          The Metropolitan Museum of Art, CC0.
          https://www.metmuseum.org/art/collection/search/436535"

full:    "Vincent van Gogh, Wheat Field with Cypresses. 1889. The Metropolitan
          Museum of Art. CC0. https://www.metmuseum.org/art/collection/search/436535."

short:   "Wheat Field with Cypresses (Vincent van Gogh, 1889)"

The caption style follows museum-publication convention: comma-separated head, medium called out, terse end. The full style is suitable for footnotes and bibliographies. The short style is for inline references where you've already established context.

For anonymous works (e.g. a Tang dynasty funerary vessel), the artist field becomes "Unknown artist" in caption form.

Resources

• museum://{museum_code}/{id}: read or list any indexed artwork by URI. Listable resources let you build a per-session shortlist without re-invoking tools.

Performance notes

• The Met API has no batch endpoint for object retrieval. A search_artworks call with limit: 10 makes one search request plus up to ten parallel object fetches (eleven HTTP round trips total on a cold cache). On warm cache the search is one round trip and most objects are local.

• Where possible, search-side filters are pushed to the museum (isPublicDomain=true is sent with every Met search) so the rights gate has fewer rejections to handle.

• Object records are cached for 90 days (artworks don't change). Search result IDs are cached for 14 days (museums add new open-access objects regularly).

Verification model

This is the heart of the project. Each museum exposes rights information in its own way; the server's job is to decide acceptance per museum and never default to "open" on ambiguity.

Default policy: strict deny. If a record's rights signal is missing, malformed, or non-affirmative, the record is dropped and the rejection reason is logged.

The Walters is the one INGEST source: its API closed in 2023, so it ships as a committed CC0 bundle (src/data/walters.json, regenerated by scripts/build-walters-index.ts) rather than a live API. Because the dump carries no per-object rights flag, the accept condition substitutes the museum's blanket CC0 grant plus a defensive pre-1928 + image gate — strict on the ambiguous modern tail.

Each accepted record carries:

• imageOpenAccess: the artwork's image may be reused under the recorded license.

• metadataOpenAccess: the artwork's catalog metadata may be reused (often broader than image rights).

• license.type: normalized license tier (CC0, PD, CC-BY, OTHER, …). Most sources emit CC0 or PD; a source with an open-access permission that isn't a standard CC licence (e.g. Harvard's imagepermissionlevel=0) is surfaced as OTHER with imageOpenAccess: true, rather than over-claimed as CC0/PD — the rights are shown faithfully, the Open Clearance way.

• license.rawValue: the museum's own field value, preserved.

• license.verificationSource: the exact museum field that was checked (e.g. met.isPublicDomain).

• license.confidence: high for unambiguous accepts (the only level emitted today).

• license.verifiedAt: ISO timestamp of when this verification ran.

This is what "rights-verified" means here: validated against published museum metadata using source-specific rules implemented in this repo, with strict deny on ambiguity. It is not a guarantee of third-party rights beyond what each museum's API publicly represents. See Disclaimer.

Supported museums

On Wikimedia Commons: Commons is a federation, not a single museum. Rights are per-file. The adapter accepts only cc0 and the worldwide public-domain templates (pd, pd-art, pd-old*, pdm, pdm-*); CC-BY, CC-BY-SA, and other attribution-or-restriction licences are rejected even though they're "free", because the per-museum gate model doesn't carry the obligations they impose. Jurisdiction-scoped public-domain tokens (pd-us*, pd-1923, and similar US-only templates) are also rejected: an accepted record is stamped as a worldwide determination, so a US-only signal must not be promoted to a worldwide claim — the same strict-default-deny reason the Europeana gate rejects NoC-US. Adding Commons unlocks works whose home museums don't have public APIs (Bruegel at the Royal Museums of Fine Arts of Belgium, the National Gallery in London pre-API, regional museums worldwide) — at the cost of a thinner metadata layer than the structured-API museums provide. Region and period are not surfaced for Wikimedia records until v0.7 adds Wikidata enrichment.

On Europeana: Europeana aggregates tens of millions of records from European cultural-heritage institutions, with rights expressed as a URI from a fixed vocabulary (Europeana Rights Statements). The adapter accepts only the unambiguous public-domain URIs — CC0 (creativecommons.org/publicdomain/zero/1.0/) and the Public Domain Mark (creativecommons.org/publicdomain/mark/1.0/). Everything else (CC-BY, CC-BY-SA, CC-BY-NC, NoC-*, InC) is rejected on the same strict-default-deny grounds as the Wikimedia gate. Europeana requires a free per-user API key — register at pro.europeana.eu/get-api and set EUROPEANA_API_KEY either in your shell, in a project-root .env, or in ~/.open-museum-mcp/.env. The fetcher silently disables itself when the key is missing (the rest of the federation continues to work).

On the Getty Museum: Getty publishes its collection as Linked.Art (CIDOC-CRM) JSON-LD, not a flat REST search API — there is no keyword-search or bulk-list endpoint, only fetch-by-known-ID and a public SPARQL endpoint. The adapter searches via SPARQL (title and artist-name text matching) and hydrates each result over REST, same per-result cost model as the Met's per-object fan-out — never a full-collection crawl. Rights are genuinely two-tier: collection metadata (title, artist, date) is CC0 across the dataset, but each image is independently rights-checked against its own media entity, since Getty's Open Content Program covers roughly 91,000 of the museum's ~168,000 objects — the remainder have open metadata but a still-copyrighted image. Records in that remainder are accepted (not rejected) with imageOpenAccess: false and no imageUrls.full, matching how this project treats every genuinely two-tier source.

Suggest a museum

If you know an open-access collection that should be on this list and you can't write the adapter yourself, open a museum-source issue. The form asks for the API URL, the rights field, and a sample record. Anyone — me, or a future contributor — can pick it up from there and build the adapter.

The contribution that matters is the source knowledge. Knowing what's in a collection and how that museum represents rights is the part the code can't do for itself.

If you can write the adapter, see CONTRIBUTING.md.

Schema

Full TypeScript definitions in src/types.ts. The Artwork shape is stable; additional fields may be added but existing fields will not be repurposed.

Highlights:

• displayDate (string, museum-provided) preserved alongside parsed yearStart / yearEnd (signed integers, BCE encoded as negatives).

• region and period normalized across museums (china, japan, tang dynasty, etc.).

• artist.attributionType distinguishes named / anonymous / workshop / after / attributed / circle / follower.

• imageOpenAccess is held distinct from metadataOpenAccess because museums frequently publish open metadata for objects whose images are not openly licensed.

Compatibility

Artwork field semantics are stable. New versions may add fields or tools, but won't repurpose or remove existing ones within a major version.

• Backward-compatible. New server versions may add fields to Artwork, add new tools, or add new optional arguments. A v0.5 client calling a v0.6 server will continue to work; it just ignores fields it doesn't know.

• Forward-compatible. A v0.6 client calling an older v0.5 server will get records that lack v0.6-only fields, but the records it does get will validate against the older client's schema.

• SemVer. While in v0.x, MINOR bumps may include backward-incompatible changes (per the SemVer spec for pre-1.0 versions). From v1.0 onwards, only MAJOR bumps may break compatibility.

Non-goals

• Not a full art-history ontology. The dynasty and region tables cover the most-encountered cases; they are not exhaustive iconographic taxonomies.

• Not a generic museum API client. The server only returns records that pass rights verification. If you need raw, unfiltered API access, talk to the museum APIs directly.

• Not a rights advisor. The verification model establishes machine-checkable acceptance rules; final rights decisions in commercial or sensitive contexts remain the user's responsibility.

• Not a content host. Image URLs point at each museum's CDN; this server does not rehost media.

Roadmap

• v0.1: Met adapter, dynasty-aware date parser, license gate, cite tool, MCP resources.

• v0.2: Cleveland and AIC adapters, discover_random with constraints, list_traditions.

• v0.3: Wikimedia Commons adapter (per-record rights model; covers works whose home museums lack public APIs).

• v0.4: Europeana adapter (federated European institutions, opt-in via API key); year_min/year_max date-range filter on search_artworks.

• v0.5: .mcpb Desktop Extension bundle (one-click Claude Desktop install); migration to Node 22+ node:sqlite (no native compile required). (here)

• v0.7: Wikidata enrichment (artist QIDs, movement, country, dedup across cache).

• v0.8: Dominant-colour extraction across museums (color: "#3a5f7d" discovery via sharp).

• v1.0: Artist-obscurity scoring (object_count_total, museum_count) for deliberate exploration of less-canonical work.

• v2.0: Smithsonian, Rijksmuseum direct integration, Walters Art Museum, more European institutions.

Release cadence

This is a side project. New releases ship when one of three things happens: my own work needs a feature, a new museum is wired in, or a contributor's PR is merged. There is no fixed cadence. I do commit to reviewing and merging contributor PRs promptly.

Project status

This is actively maintained as of the latest release. Because it is a side project, if active maintenance ever stops I will archive the repository and say so here, rather than leave it looking live. The published npm package, the adapters, and the Artwork schema remain usable either way, and the code is MIT-licensed, so anyone is free to fork and continue it. Governance and the path for new maintainers are described in GOVERNANCE.md.

Changelog

Releases lists what shipped in each version, with notes.

Help maintain this

open-museum-mcp is an independently maintained side project, and it now carries two things that benefit from more hands:

• The MCP engine — the museum adapters, the rights gate, the date parser, the federation core. New collections, rights-model corrections, and bug reports are all welcome; CONTRIBUTING.md is the starting point.

• The openclearance Clearance Manifest spec (spec/clearance/) — a portable, fail-closed rights-clearance format emitted by the clearance_record tool. Schema review, conformance tests, and additional per-museum rule mappings are especially valuable while v0.1 is young and the schema can still absorb feedback.

If you'd like to help — code, review, documentation, or rights expertise — open an issue or a PR. And if your organisation relies on this and would like to fund its ongoing maintenance, open an issue or get in touch; a sponsorship path is being set up.

Contributing a museum adapter

See CONTRIBUTING.md. The short version:

1. Implement the Fetcher interface in src/fetchers/{code}.ts.

2. Add a validate{Code}License function in src/licenseGate.ts with explicit accept rules and strict default deny.

3. Add region/period mappings to src/data/regions.json and src/data/dynasties.json if the new collection introduces unmapped traditions.

4. Add fixture-based tests in tests/{code}.test.ts covering: one accepted record, one rejected (non-open) record, one rejected (missing field) record.

5. Register the adapter in src/server.ts.

The license gate is the most opinionated part of the codebase. Additions should err strict.

Security

• npm audit clean at launch. Zero vulnerabilities at any severity level across runtime and dev dependencies as of v0.1.

• stdio-only transport. No HTTP listener, no auth surface to bypass. The server only speaks to the MCP client over standard streams.

• Strict input validation. All tool arguments pass through Zod schemas; artwork IDs are constrained to /^[a-z]+:[1-9]\d*$/. The resource URI handler re-validates the constructed ID against the same regex, so URI-form requests can't bypass the constraint.

• Defense-in-depth on rights. The Met search filter isPublicDomain=true is sometimes inconsistent with the per-object boolean. The license gate runs again on every fetched record and rejects any disagreement.

• Parameterized SQL. All better-sqlite3 calls use named/positional parameters; zero string-concatenated SQL paths.

• No file writes from user input. The cache directory is created at ~/.open-museum-mcp/cache.db (or wherever OMM_CACHE_PATH points) with mode 0o700 and the cache file at 0o600; no fetcher rehosts media bytes locally.

If you find a record the gate accepts that shouldn't pass, please open an issue with the artwork ID and the museum's raw API response. Rights correctness is the project's most important property, and the part where outside review most helps.

Disclaimer

This software validates open-access status against the rights metadata each museum publishes and the rules each museum requests. It cannot independently verify third-party rights, derived works, model release issues, or sensitive cultural-heritage considerations beyond what the source museum represents. Several museums (e.g. the Art Institute of Chicago) explicitly note that even CC0-marked images may carry obligations around third-party permissions or culturally sensitive material. Always confirm against the source museum's terms before commercial or sensitive use.

License

MIT. See LICENSE.