The Met Museum MCP Server enables AI models to interact with The Metropolitan Museum of Art's collection through natural language queries. Key capabilities include:
List Departments: Retrieve all departments in The Met.
Search Museum Objects: Search for objects by keywords, title, or department, with options to filter by availability of images.
Get Museum Object: Fetch detailed information about a specific object by ID, including metadata and images (if available).
Accesses the Metropolitan Museum of Art's Open Access data, including images available under Open Access which can be added to the server's resources and displayed to users.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Met Museum MCP Server show me paintings of sunflowers from the European Paintings department"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides access to the Metropolitan Museum of Art Collection through natural language interactions. This server allows AI models to search The Met's art collection and retrieve artwork details (including images) via tool results.
Related MCP server: mcp-va-museum
A hosted deployment is available on Fronteir AI.
This server provides AI models the following tools to interact with the art collection of The Met:
Lists all the valid departments at The Met
Inputs:
None
Output:
Department ID: 1, Display Name: American Decorative Arts
Department ID: 3, Display Name: Ancient Near Eastern Art
...Search for various objects in The Met based on the inputs.
Inputs:
q (string): The search term e.g. sunflowers
hasImages (boolean, optional, default: false): Only search for objects with images
title (boolean, optional, default: false): Returns objects that match the query, specifically searching against the title field for objects.
departmentId (number, optional): Returns objects that are a part of a specific department.
page (number, optional, default: 1): 1-based page number for results.
pageSize (number, optional, default: 24): Number of Object IDs per page (max 100).
Outputs:
Total objects found: 54
Page: 1/3
Object IDs: 436532, 789578, 436840, 438722,...Get a specific object from The Met containing all open access data about that object, including its image (if the image is available under Open Access).
If there is an image and returnImage is true, it is returned as an image content block in the tool result (base64-encoded JPEG).
Use this tool when the user asks for deeper details on a specific artwork and you already have an objectId.
Inputs:
objectId (number): The id of the object to retrieve
returnImage (boolean, optional, default: true): Whether to include the object's image (if available) in the tool result
Outputs:
Title: Self-Portrait with a Straw Hat (obverse: The Potato Peeler)
Artist: Vincent van Gogh
Artist Bio: Dutch, Zundert 1853–1890 Auvers-sur-Oise
Department: European Paintings
Credit Line: Bequest of Miss Adelaide Milton de Groot (1876-1967), 1967
Medium: Oil on canvas
Dimensions: 16 x 12 1/2 in. (40.6 x 31.8 cm)
Primary Image URL: https://images.metmuseum.org/CRDImages/ep/original/DT1502_cropped2.jpg
Tags: Men, Self-portraitsIf returnImage is true
**base64 encoding of jpeg image**Launches an interactive MCP App (ui://met/explorer.html) that can search, filter, and inspect objects from within MCP clients that support Apps.
Recommended flow:
Use open-met-explorer to launch and browse live search results (pass q to start searching immediately).
After creating a curated list from current results, use get-museum-object only for items the user wants to explore in depth.
Inputs (all optional):
q (string): Initial search term.
hasImages (boolean, default: true): Prefer objects with images.
title (boolean, default: false): Search titles only.
departmentId (number): Pre-select a department filter.
Output:
Opens the Met Explorer app in the client UI.There are now MCP Apps in this MCP Server. There is a UI component for the Open Met Explorer App tool and the Get Museum Object tool.
Node.js v18 or later
Run the server directly with npx — no install required:
npx -y metmuseum-mcpThis starts the server using stdio transport, which is what most MCP desktop clients expect.
For client-specific setup, see:
Usage with ChatGPT (requires Streamable HTTP transport)
The following environment variable applies to all transports:
Variable | Default | Description |
|
| Timeout in milliseconds for outbound requests to the Met Collection API. |
|
| Enables debug logging to |
This server supports two transports:
Stdio transport (default): Used by MCP desktop clients (Claude Desktop, LibreChat MCP, etc.).
Streamable HTTP transport: Run with --http to expose an MCP endpoint at /mcp.
Run with npx (recommended for end users):
npx -y metmuseum-mcp --httpOr run from a local clone:
pnpm run build
node dist/index.js --httpThe server listens on:
http://localhost:3001/mcpYou can control HTTP server behavior with environment variables:
Variable | Default | Description |
|
| HTTP port used by the Streamable HTTP server. |
|
| Network interface the HTTP server binds to. |
|
| Comma-separated host allowlist for host header validation (example: |
Example:
HOST=127.0.0.1 PORT=8080 ALLOWED_HOSTS=localhost,127.0.0.1 npx -y metmuseum-mcp --httpThe following steps allow you to use Met Museum MCP with the web UI of ChatGPT
Settings → Apps → Advanced settings → Developer mode
Additional instructions here
npx -y metmuseum-mcp --httpBy default the server will be listening on http://127.0.0.1:3001/mcp
Sign up and configure ngrok, the free plan works.
ngrok http http://127.0.0.1:3001 --host-header=rewriteTake note of the forwarding URL.
...
Forwarding https://john-joe-asdf.ngrok-free.dev -> http://localhost:3001
...Click Apps
Click Create Apps
Fill out the form using the URL from step 3 as the MCP Server URL, but add /mcp.
https://john-joe-asdf.ngrok-free.dev/mcpFor Authentication, select 'No Auth'
Tick the checkbox for 'I understand and want to continue'
Then click Create.
In the prompt input field you can use @name-of-server-from-step3 or In the ChatGPT UI, click the '+' button, scroll to '...more', select the newly created Met app, and enter your query.
Download the mcpb file from the Releases
Open it with Claude Desktop or Go to File -> Settings -> Extensions and drag the .mcpb file to the window to install it
Add this to your claude_desktop_config.json:
{
"mcpServers": {
"met-museum": {
"command": "npx",
"args": [
"-y",
"metmuseum-mcp"
]
}
}
}Add the following in your librechat.yaml
mcpServers:
metmuseum:
command: npx
args:
- -y
- metmuseum-mcpHere are some questions you can ask the AI model when this server is connected:
Can you help me explore the works of Vincent Van Gogh?
Can you help me explore the Met?
Can you show me a few paintings from the Asian Art department?
Can you find the painting titled "Corridor in the Asylum"?
Can you find any art that has "cat" in the title or features "cats"?This project uses pnpm for local development and CI.
corepack enable
pnpm install
pnpm run build
pnpm run checkFor non-interactive shells/CI runners, use CI=true pnpm install --frozen-lockfile.
Contributions are welcome! Please feel free to submit a Pull Request.
This MCP server is licensed under the MIT License. This means you are free to use, modify, and distribute the software, subject to the terms and conditions of the MIT License. For more details, please see the LICENSE file in the project repository.
This library is not officially associated with The Metropolitan Museum of Art in New York. It is a third-party implementation of the The Metropolitan Museum of Art Collection API with a MCP Server.
Get a museum object by its ID, from the Metropolitan Museum of Art Collection. Use this when the user asks for deeper details on a specific object ID.
| Name | Required | Description | Default |
|---|---|---|---|
| objectId | Yes | The positive integer ID of the museum object to retrieve | |
| returnImage | No | Whether to return the image (if available) of the object |
| Name | Required | Description |
|---|---|---|
| object | Yes | Detailed object data for the requested object ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. The description adds no additional behavioral context beyond 'Get' and 'deeper details,' which is consistent but not enriching.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: one for the action and one for usage guidance. Front-loaded and efficient with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple object retrieval tool, the description suffices given the presence of an output schema, annotations, and sibling tools. No missing critical context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters (objectId and returnImage). The description does not add parameter-specific context, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get a museum object by its ID' and specifies source (Metropolitan Museum of Art). It distinguishes from siblings that list, search, or open explorer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when the user asks for deeper details on a specific object ID,' providing clear when-to-use guidance and implying when not to use (e.g., for listing or searching).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all departments in the Metropolitan Museum of Art (Met Museum)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| departments | Yes | An array containing the JSON objects that contain each department's departmentId and display name. The departmentId is to be used as a query parameter on the `/objects` endpoint |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description confirms a read-only list operation but adds no behavioral details 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key action and resource, no unnecessary words. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and the presence of an output schema, the description is complete. It fully conveys the tool's purpose and scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description does not need to explain them. The baseline for 0 parameters is 4, and the description is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('List all departments') and the resource ('Metropolitan Museum of Art'). It distinguishes from sibling tools like 'get-museum-object' and 'search-museum-objects' by focusing on departments rather than objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving all departments but provides no explicit guidance on when to use this tool versus alternatives or any conditions/limitations. It is functional but lacks contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open the interactive Met Explorer app for browsing and filtering objects. For exploration intents, pass q so the app can run a live search on open. After opening, keep your chat handoff short and UI-focused. For deeper details on a specific object ID, prefer get-museum-object.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Optional initial search query to seed the explorer. If provided, the app automatically executes the search on launch | |
| hasImages | No | Whether the initial search should prioritize objects with images | |
| title | No | Whether the initial query should search only object titles | |
| departmentId | No | Optional department id to pre-select in the explorer |
| Name | Required | Description |
|---|---|---|
| initialState | Yes | Initial app launch state for the Met Explorer UI |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds value beyond annotations by describing post-opening behavior ('keep your chat handoff short and UI-focused'). Annotations already provide readOnlyHint, destructiveHint, idempotentHint, openWorldHint; description does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each purposeful: defines the tool, instructs on query parameter, advises post-opening behavior, and mentions alternative tool. No wasted words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given interactive nature, output schema existence, and annotations, description covers all necessary aspects: purpose, usage, alternative, and post-behavior. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds context like recommending 'q' for live search and default behavior of hasImages. Baseline is 3, and the description provides helpful but not critical additional insight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Open', resource 'interactive Met Explorer app', and purpose 'browsing and filtering objects'. Distinguishes from sibling get-museum-object by specifying alternative use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to pass 'q' for exploration intents, instructs to keep chat handoff short and UI-focused after opening, and directs users to get-museum-object for deeper details on a specific object ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for objects in the Metropolitan Museum of Art (Met Museum). Will return Total objects found, followed by a paginated list of Object Ids. If the Met Explorer app (open-met-explorer) is open and the user is referring to its existing results, prefer using those results from context instead of calling this tool. The parameter title should be set to true if you want to search for objects by title. The parameter hasImages is false by default, but can be set to true to return only objects with images. Additional optional filters are available for highlights, tags, on-view status, artist/culture match, medium, geographic location, and date range. Use page and pageSize to paginate results.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | The search query, Returns a listing of all Object IDs for objects that contain the search query within the object's data | |
| hasImages | No | Only returns objects that have images | |
| title | No | This should be set to true if you want to search for objects by title | |
| isHighlight | No | Only returns objects designated as highlights | |
| tags | No | Only returns objects that have subject keyword tags | |
| isOnView | No | Only returns objects currently on view | |
| artistOrCulture | No | When true, q is matched against artist or culture | |
| departmentId | No | Returns objects that are in the specified department. The departmentId should come from the 'list-departments' tool. | |
| medium | No | Restricts search to objects with the specified medium | |
| geoLocation | No | Restricts search to objects with the specified geographic location | |
| dateBegin | No | Start year for a date range filter. Must be provided together with dateEnd. | |
| dateEnd | No | End year for a date range filter. Must be provided together with dateBegin. | |
| page | No | 1-based page number for paginated object IDs | |
| pageSize | No | Number of object IDs to return per page (max 100) |
| Name | Required | Description |
|---|---|---|
| total | Yes | Total number of matching objects across all pages |
| page | Yes | Current 1-based page number returned by the tool |
| pageSize | Yes | Number of object IDs returned per page |
| totalPages | Yes | Total number of pages available for this query |
| objectIDs | Yes | Paginated list of object IDs for the current page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds value by detailing the exact output (total objects found + paginated object IDs) and clarifying default behaviors (e.g., hasImages defaults to false). 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Six sentences, front-loaded with purpose and return format, logically organized. No fluff; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 params, 1 required, output schema exists), the description is complete. It covers main output, alternative usage, parameter details, and cross-tool dependency. The existing output schema complements it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers 100% parameters with descriptions and defaults. The description summarizes and adds a cross-reference (departmentId from list-departments), but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: 'Search for objects in the Metropolitan Museum of Art (Met Museum).' It also mentions return type (total count and paginated object IDs). However, it does not explicitly differentiate from sibling tools like get-museum-object, though the name and context imply it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to avoid this tool ('If the Met Explorer app is open... prefer using those results). It also references the list-departments tool for a parameter. However, it does not compare with other search alternatives or mention get-museum-object.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: get-museum-object retrieves details by ID, list-departments lists departments, open-met-explorer launches an interactive app, and search-museum-objects performs filtered searches. There is no ambiguity between them.
All tool names follow a consistent verb-noun pattern with lowercase hyphens (e.g., get-museum-object, list-departments). No mixing of styles.
Four tools is an appropriate count for a museum collection server covering search, detail retrieval, department listing, and an interactive explorer. Not too sparse or overwhelming.
The tool surface covers key read operations (search, detail, departments) and an interactive explorer. Minor gaps like direct department-based object listing are covered by search filters, so no significant missing functionality.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for searching Airweave collections with natural language queries.
MCP server for AI dialogue using various LLM models via AceDataCloud
MCP server for progressive tool usage at any scale (see https://klavis.ai)
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mikechao/metmuseum-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
