Loading ToolBench
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 have art works available as a Resource.
The Met Museum MCP server demonstrates solid tool definitions with clear naming, reasonable descriptions, and mostly complete schemas. All four tools follow verb_noun naming conventions (list-, search-, get-, open-) and have actionable descriptions. Input schemas are well-structured using Zod with proper types and descriptions. However, there are notable gaps: parameter descriptions vary in quality and completeness, output schemas are not explicitly documented in the tool definitions themselves, and error handling guidance is minimal. The server leverages structured content (structuredContent field) in responses but doesn't fully document this in the tool descriptions for LLMs. Overall, this is a solid B-grade implementation with room for improvement in documentation completeness and error recovery guidance.
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.
List all departments in the Metropolitan Museum of Art (Met Museum)
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.
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.
Output schemas not documented in tool descriptions. While GetObjectTool.ts includes structuredContent in CallToolResult, this is not communicated to the LLM. LLMs cannot infer that structured object data will be available alongside text content, limiting their ability to plan downstream processing.
Missing error guidance in descriptions. Tools catch MetMuseumApiError and return user-friendly messages, but descriptions do not explain recovery steps. E.g., search-museum-objects does not document: 'If no results found, try broader terms or use list-departments first.' Pattern recovery-guide explicitly requires this.
search-museum-objects description is lengthy (283 chars) and mixes multiple concerns: parameter guidance (title, hasImages), filtering hints, pagination notes, and a note about preferring app results. This violates the 10-1024 char guideline (though technically within bounds) and buries key intent. Should split into concise description + parameter-level guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 66 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Parameter 'page' and 'pageSize' lack explicit constraints in descriptions. Code defaults to page=1, pageSize=50, max 500, but descriptions only state 'Number of page IDs to return per page (max 500)'. Should include: '1-based integer, default 50, max 500' to prevent LLM from passing invalid values.
open-met-explorer description mentions 'keep your chat handoff short and UI-focused', this is implementation-specific guidance that should not be in a tool description. Tool descriptions should focus on WHAT it does, not HOW the agent should behave.