art-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_sourcesA | List the museum data sources this server can query and whether each is currently available. Sources needing an API key are unavailable until the key is configured. |
| search_artworksA | Search museum collections for artworks. Returns compact results including a IMPORTANT — this matches keywords against catalog metadata; it is not semantic search. Artist names, titles, cultures, and periods work well. Descriptions of subject matter work badly: a query like 'man crossing a bridge' matches any record containing 'man', 'bridge', or names like 'Bridges' and 'Cross', and buries the relevant results. So translate the user's intent into catalog vocabulary before calling. If you can name a likely artist, school, or title from your own knowledge, search for that instead — e.g. prefer 'Hokusai' or 'Hiroshige Tokaido' over 'japanese painting of a bridge'. Searching a subject phrase directly is a last resort; if you must, use one or two distinctive nouns rather than a sentence. Results are ordered by each museum's own relevance ranking, which is often weak — scan the whole list rather than assuming the first hit is best. CHOOSING A SOURCE. 'all' is a fine default, but naming a source is much better when the work has an obvious home. Five of the ten sources hold mostly Western art (met, artic, cleveland, harvard, rijksmuseum); for anything else, reach for these first:
Source-specific quirks worth knowing:
|
| get_artworkA | Fetch full catalog details for a single artwork by its source and id (as returned by search_artworks) — medium, dimensions, department, culture, where it was made, credit line, and rights where the museum publishes them. Use this to confirm attribution or rights before relying on a work, since search results carry only a summary. Rights come back in two fields: |
| get_artwork_imageA | Download the image for a single artwork (by source and id) and return it so it can actually be viewed, plus a short caption. Use this whenever the user wants to see a work, or when you need to judge what a work actually depicts rather than trusting its title. Not every record has an image, and the Art Institute ('artic') serves images from a host behind a bot challenge, so those usually fail with a 403 — prefer another source when you need to display something, and fall back to the museumUrl from search results if an image cannot be fetched. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool has a distinct purpose: listing sources, searching for artworks, fetching full details, and retrieving images. No overlap exists.
All tool names follow a consistent verb_noun pattern (list_sources, search_artworks, get_artwork, get_artwork_image) in snake_case.
Four tools is well-scoped for a museum art server that needs to discover sources, search, retrieve metadata, and get images.
The tool surface covers the full workflow: source discovery, search, detail retrieval, and image access. No obvious gaps for the intended use case.