Un servidor de Protocolo de Contexto de Modelo (MCP) que proporciona acceso a la Colección del Museo Metropolitano de Arte mediante interacciones de lenguaje natural. Este servidor permite a los modelos de IA buscar en la colección de arte del Met y disponer de obras de arte como recurso.
Este servidor proporciona a los modelos de IA las siguientes herramientas para interactuar con la colección de arte del Met
Enumera todos los departamentos válidos en The Met
Entradas:
Ninguno
Producción:
Department ID: 1, Display Name: American Decorative Arts
Department ID: 3, Display Name: Ancient Near Eastern Art
...Busque varios objetos en The Met basándose en las entradas.
Entradas:
q (cadena): El término de búsqueda, p. ej. girasoles
hasImages (booleano, opcional, predeterminado: falso): solo busca objetos con imágenes
title (booleano, opcional, valor predeterminado: falso): devuelve objetos que coinciden con la consulta, buscando específicamente objetos en el campo de título.
departmentId (número, opcional): Devuelve objetos que forman parte de un departamento específico.
Salidas:
Total objects found: 54
Object IDs: 436532, 789578, 436840, 438722,...Obtenga un objeto específico de The Met que contenga todos los datos de acceso abierto sobre ese objeto, incluida su imagen (si la imagen está disponible bajo acceso abierto).
Si hay una imagen, se agrega al recurso del servidor a través del título del objeto.
Entradas:
objectId (número): el id del objeto a recuperar
returnImage (booleano, opcional, valor predeterminado: verdadero): si se debe devolver la imagen (si está disponible) del objeto y agregarla a los recursos del servidor
Salidas:
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-portraitsSi returnImage es verdadero
**base64 encoding of jpeg image**Agregue esto a su claude_desktop_config.json :
{
"mcp-servers": {
"met-museum": {
"command": "npx",
"args": [
"-y",
"metmuseum-mcp"
]
}
}
}Agrega lo siguiente en tu librechat.yaml
mcpServers:
metmuseum:
command: npx
args:
- -y
- metmuseum-mcpRelated MCP server: mcp-va-museum
Aquí hay algunas preguntas que puedes hacerle al modelo de IA cuando este servidor esté conectado:
Can you show me a few painting 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"?¡Agradecemos sus contribuciones! No dude en enviar una solicitud de incorporación de cambios.
Este servidor MCP cuenta con la licencia MIT. Esto significa que puede usar, modificar y distribuir el software libremente, sujeto a los términos y condiciones de la licencia MIT. Para más detalles, consulte el archivo de LICENCIA en el repositorio del proyecto.
Esta biblioteca no está oficialmente asociada con el Museo Metropolitano de Arte de Nueva York. Es una implementación externa de la API de la Colección del Museo Metropolitano de Arte con un servidor MCP.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.9.0get-museum-object7 fields changedInput schema / properties / __intentRemoved value: -{
- "description": "In ≤ 30 words, describe why you are calling this tool and how its result advances your overall task. Don't use first-person pronouns like \"I\" or \"my\". Make sure to give a gist of the whole task and how this tool fits into it.",
- "type": "string"
-}Input schema / properties / objectId / descriptionPrevious value: -"The ID of the museum object to retrieve"New value: +"The positive integer ID of the museum object to retrieve"Input schema / properties / objectId / exclusiveMinimumAdded value: +0Input schema / properties / objectId / typePrevious value: -"number"New value: +"integer"Input schema / properties / returnImage / descriptionPrevious value: -"Whether to return the image (if available) of the object and add it to the server resources"New value: +"Whether to return the image (if available) of the object"Input schema / requiredPrevious value: -[
- "objectId",
- "__intent"
-]New value: +[
+ "objectId"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "object": {
+ "additionalProperties": false,
+ "description": "Detailed object data for the requested object ID",
+ "properties": {
+ "GalleryNumber": {
+ "description": "Gallery number where artwork is located",
+ "type": "string"
+ },
+ "accessionNumber": {
+ "description": "Identifying number for each artwork (not always unique)",
+ "type": "string"
+ },
+ "accessionYear": {
+ "description": "Year the artwork was acquired",
+ "type": "string"
+ },
+ "additionalImages": {
+ "description": "An array containing URLs to the additional images of an object in JPEG format",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "artistAlphaSort": {
+ "description": "Used to sort artist names alphabetically. Last Name, First Name, Middle Name, Suffix, and Honorific fields",
+ "type": "string"
+ },
+ "artistBeginDate": {
+ "description": "Year the artist was born",
+ "type": "string"
+ },
+ "artistDisplayBio": {
+ "description": "Nationality and life dates of an artist, also includes birth and death city when known",
+ "type": "string"
+ },
+ "artistDisplayName": {
+ "description": "Artist name in the correct order for display",
+ "type": "string"
+ },
+ "artistEndDate": {
+ "description": "Year the artist died",
+ "type": "string"
+ },
+ "artistGender": {
+ "description": "Gender of the artist (currently contains female designations only)",
+ "type": "string"
+ },
+ "artistNationality": {
+ "description": "National, geopolitical, cultural, or ethnic origins or affiliation of the creator",
+ "type": "string"
+ },
+ "artistPrefix": {
+ "description": "Describes the extent of creation or describes an attribution qualifier to the information given in the artistRole field",
+ "type": "string"
+ },
+ "artistRole": {
+ "description": "Role of the artist related to the type of artwork or object that was created",
+ "type": "string"
+ },
+ "artistSuffix": {
+ "description": "Used to record complex information that qualifies the role of a constituent",
+ "type": "string"
+ },
+ "artistULAN_URL": {
+ "description": "ULAN URL for the artist",
+ "type": "string"
+ },
+ "artistWikidata_URL": {
+ "description": "Wikidata URL for the artist",
+ "type": "string"
+ },
+ "city": {
+ "description": "City associated with the artwork's creation",
+ "type": "string"
+ },
+ "classification": {
+ "description": "General term describing the artwork type",
+ "type": "string"
+ },
+ "constituents": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "constituentID": {
+ "type": "number"
+ },
+ "constituentULAN_URL": {
+ "type": "string"
+ },
+ "constituentWikidata_URL": {
+ "type": "string"
+ },
+ "gender": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "role": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "constituentID",
+ "role",
+ "name",
+ "constituentULAN_URL",
+ "constituentWikidata_URL",
+ "gender"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "An array containing the constituents associated with an object, with the constituent's role, name, ULAN URL, Wikidata URL, and gender, when available (currently contains female designations only)"
+ },
+ "country": {
+ "description": "Country associated with the artwork's creation",
+ "type": "string"
+ },
+ "county": {
+ "description": "County associated with the artwork's creation",
+ "type": "string"
+ },
+ "creditLine": {
+ "description": "Text acknowledging the source or origin of the artwork and the year the object was acquired",
+ "type": "string"
+ },
+ "culture": {
+ "description": "Information about the culture, or people from which an object was created",
+ "type": "string"
+ },
+ "department": {
+ "description": "Indicates The Met's curatorial department responsible for the artwork",
+ "type": "string"
+ },
+ "dimensions": {
+ "description": "Size of the artwork or object",
+ "type": "string"
+ },
+ "dynasty": {
+ "description": "Dynasty (a succession of rulers of the same line or family) under which an object was created",
+ "type": "string"
+ },
+ "excavation": {
+ "description": "Excavation associated with the artwork",
+ "type": "string"
+ },
+ "geographyType": {
+ "description": "Type of location related to the artwork (e.g., \"Made in\", \"From\")",
+ "type": "string"
+ },
+ "isHighlight": {
+ "description": "When \"true\" indicates a popular and important artwork in the collection",
+ "type": "boolean"
+ },
+ "isPublicDomain": {
+ "description": "When \"true\" indicates the image is in the public domain",
+ "type": "boolean"
+ },
+ "isTimelineWork": {
+ "description": "Whether the artwork is featured on the Timeline of Art History website",
+ "type": "boolean"
+ },
+ "linkResource": {
+ "description": "URL to the object's page on metmuseum.org",
+ "type": "string"
+ },
+ "locale": {
+ "description": "Locale associated with the artwork's creation",
+ "type": "string"
+ },
+ "locus": {
+ "description": "Locus associated with the artwork's creation",
+ "type": "string"
+ },
+ "measurements": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "elementDescription": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "elementMeasurements": {
+ "additionalProperties": {
+ "type": "number"
+ },
+ "type": "object"
+ },
+ "elementName": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "elementName",
+ "elementMeasurements"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Array of elements, each with a name, description, and set of measurements. Spatial measurements are in centimeters; weights are in kg"
+ },
+ "medium": {
+ "description": "Refers to the materials that were used to create the artwork",
+ "type": "string"
+ },
+ "metadataDate": {
+ "description": "Date metadata was last updated",
+ "type": "string"
+ },
+ "objectBeginDate": {
+ "description": "Machine readable date indicating the year the artwork was started to be created",
+ "type": "number"
+ },
+ "objectDate": {
+ "description": "Year, a span of years, or a phrase that describes the specific or approximate date when an artwork was designed or created",
+ "type": "string"
+ },
+ "objectEndDate": {
+ "description": "Machine readable date indicating the year the artwork was completed",
+ "type": "number"
+ },
+ "objectID": {
+ "description": "Identifying number for each artwork (unique, can be used as key field)",
+ "type": "number"
+ },
+ "objectName": {
+ "description": "Describes the physical type of the object",
+ "type": "string"
+ },
+ "objectURL": {
+ "description": "URL to the object's page on metmuseum.org",
+ "type": "string"
+ },
+ "objectWikidata_URL": {
+ "description": "Wikidata URL for the object",
+ "type": "string"
+ },
+ "period": {
+ "description": "Time or time period when an object was created",
+ "type": "string"
+ },
+ "portfolio": {
+ "description": "A set of works created as a group or published as a series",
+ "type": "string"
+ },
+ "primaryImage": {
+ "description": "URL to the primary image of an object in JPEG format",
+ "type": "string"
+ },
+ "primaryImageSmall": {
+ "description": "URL to the lower-res primary image of an object in JPEG format",
+ "type": "string"
+ },
+ "region": {
+ "description": "Region associated with the artwork's creation",
+ "type": "string"
+ },
+ "reign": {
+ "description": "Reign of a monarch or ruler under which an object was created",
+ "type": "string"
+ },
+ "repository": {
+ "description": "Indicates the repository containing the artwork",
+ "type": "string"
+ },
+ "rightsAndReproduction": {
+ "description": "Credit line for artworks still under copyright",
+ "type": "string"
+ },
+ "river": {
+ "description": "River associated with the artwork's creation",
+ "type": "string"
+ },
+ "state": {
+ "description": "State or province associated with the artwork's creation",
+ "type": "string"
+ },
+ "subregion": {
+ "description": "Subregion associated with the artwork's creation",
+ "type": "string"
+ },
+ "tags": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "AAT_URL": {
+ "type": "string"
+ },
+ "Wikidata_URL": {
+ "type": "string"
+ },
+ "term": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "An array of subject keyword tags associated with the object"
+ },
+ "title": {
+ "description": "Title, identifying phrase, or name given to a work of art",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "object"
+ ],
+ "type": "object"
+}list-departments3 fields changedInput schema / properties / __intentRemoved value: -{
- "description": "In ≤ 30 words, describe why you are calling this tool and how its result advances your overall task. Don't use first-person pronouns like \"I\" or \"my\". Make sure to give a gist of the whole task and how this tool fits into it.",
- "type": "string"
-}Input schema / requiredRemoved value: -[
- "__intent"
-]Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "departments": {
+ "description": "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",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "departmentId": {
+ "description": "Department ID as an integer. The departmentId is to be used as a query parameter on the `/objects` endpoint",
+ "type": "number"
+ },
+ "displayName": {
+ "description": "Display name for a department",
+ "type": "string"
+ }
+ },
+ "required": [
+ "departmentId",
+ "displayName"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "departments"
+ ],
+ "type": "object"
+}open-met-explorersearch-museum-objects14 fields changedInput schema / properties / __intentRemoved value: -{
- "description": "In ≤ 30 words, describe why you are calling this tool and how its result advances your overall task. Don't use first-person pronouns like \"I\" or \"my\". Make sure to give a gist of the whole task and how this tool fits into it.",
- "type": "string"
-}Input schema / properties / artistOrCultureAdded value: +{
+ "default": false,
+ "description": "When true, q is matched against artist or culture",
+ "type": "boolean"
+}Input schema / properties / dateBeginAdded value: +{
+ "description": "Start year for a date range filter. Must be provided together with dateEnd.",
+ "type": "integer"
+}Input schema / properties / dateEndAdded value: +{
+ "description": "End year for a date range filter. Must be provided together with dateBegin.",
+ "type": "integer"
+}Input schema / properties / geoLocationAdded value: +{
+ "description": "Restricts search to objects with the specified geographic location",
+ "type": "string"
+}Input schema / properties / isHighlightAdded value: +{
+ "default": false,
+ "description": "Only returns objects designated as highlights",
+ "type": "boolean"
+}Input schema / properties / isOnViewAdded value: +{
+ "default": false,
+ "description": "Only returns objects currently on view",
+ "type": "boolean"
+}Input schema / properties / mediumAdded value: +{
+ "description": "Restricts search to objects with the specified medium",
+ "type": "string"
+}Input schema / properties / pageAdded value: +{
+ "default": 1,
+ "description": "1-based page number for paginated object IDs",
+ "exclusiveMinimum": 0,
+ "type": "integer"
+}Input schema / properties / pageSizeAdded value: +{
+ "default": 24,
+ "description": "Number of object IDs to return per page (max 100)",
+ "exclusiveMinimum": 0,
+ "maximum": 100,
+ "type": "integer"
+}Input schema / properties / q / minLengthAdded value: +1Input schema / properties / tagsAdded value: +{
+ "default": false,
+ "description": "Only returns objects that have subject keyword tags",
+ "type": "boolean"
+}Input schema / requiredPrevious value: -[
- "q",
- "__intent"
-]New value: +[
+ "q"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "objectIDs": {
+ "description": "Paginated list of object IDs for the current page",
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ "page": {
+ "description": "Current 1-based page number returned by the tool",
+ "exclusiveMinimum": 0,
+ "type": "integer"
+ },
+ "pageSize": {
+ "description": "Number of object IDs returned per page",
+ "exclusiveMinimum": 0,
+ "type": "integer"
+ },
+ "total": {
+ "description": "Total number of matching objects across all pages",
+ "type": "number"
+ },
+ "totalPages": {
+ "description": "Total number of pages available for this query",
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "total",
+ "page",
+ "pageSize",
+ "totalPages",
+ "objectIDs"
+ ],
+ "type": "object"
+}v1.0.0list-departments1 field changedInput schema / additionalPropertiesRemoved value: -falseget-museum-objectlist-departmentssearch-museum-objectsScored across 4 tools
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.
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)
