Skip to main content
Glama

met-museum-mcp-server

Search Met Collection

met_search_collections
Read-onlyIdempotent

Search the Metropolitan Museum of Art collection by keyword and optional filters. Returns the total match count and a page of matching object IDs, which met_get_object resolves to full records. Relevance is keyword-based, not semantic; department and geographic filters narrow results more than a longer query. The medium parameter maps to the classification field (pass "Paintings", "Drawings", etc., not material descriptions like "Oil on canvas"). isPublicDomain guarantees CC0-licensed images; hasImages also includes copyrighted works. isOnView restricts results to works currently on display in a Met gallery.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qYesKeyword query, matched across title, artist name, culture, medium, tags, and other text fields. Broad terms return large ID sets.
limitNoMaximum number of object IDs to return from the full result set. The Met search returns every match (up to tens of thousands); this caps how many IDs are returned.
mediumNoFilter by object classification (e.g., "Paintings", "Drawings", "Prints", "Ceramics", "Sculpture", "Photographs", "Textiles"). Maps to the classification field on the object, not the materials/medium text field — pass a classification category name, not a material description like "Oil on canvas".
offsetNoZero-based index into the full result set to start from (default 0). The nextOffset from a previous response is the value to pass here for the next page; a broad query carries the same timeout risk on every page, so narrow it with filters if paging times out. An offset at or beyond total returns an empty page, not an error.
dateEndNoLatest object date (year, inclusive). Negative integers for BCE. Requires dateBegin.
isOnViewNoWhen true, restricts results to objects currently on display in a Met gallery. The GalleryNumber field on the met_get_object record identifies the specific gallery.
dateBeginNoEarliest object date (year, inclusive). Negative integers for BCE (e.g., -500 for 500 BCE). Requires dateEnd.
hasImagesNoWhen true, restricts results to objects that have at least one associated image, including copyrighted works whose images cannot be reproduced. isPublicDomain is the filter for freely reusable CC0 images.
geoLocationNoFilter by geographic origin. Each value is matched broadly against geography fields and artist nationality. Multiple values are AND-combined — ["France", "Egypt"] returns objects associated with both, not either, so more values narrow the result set. Works best with the Egyptian Art, Greek and Roman Art, and similar departments that have well-populated geography fields.
isHighlightNoWhen true, restricts to objects the Met has designated as highlights — major works central to the collection.
departmentIdNoRestrict results to one curatorial department. Valid IDs come from met_list_departments — the Met exposes a sparse set (roughly 1–21, with gaps); an unrecognized ID is rejected with an invalid_department error rather than silently returning no matches. Can be combined with other filters; combining with isPublicDomain works but returns far fewer results than expected.
isPublicDomainNoWhen true, restricts results to objects released under CC0 open access — free to use without permission or attribution. These objects return direct high-resolution image URLs in met_get_object. Combining with departmentId works but returns far fewer results, since the search index covers only a subset of public-domain objects per department.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
totalNoTotal number of matching objects in the Met collection (may far exceed the returned IDs).
returnedNoCount of object IDs in this response — may be less than `total` when the full result set was truncated by `limit`.
objectIDsNoObject IDs for this page, up to `limit` results.
remainingNoCount of matching object IDs after this page: total − (offset + returned), floored at 0. 0 means this is the last page.
truncatedNoTrue when matching IDs remain beyond this page (offset + returned < total); false when this page is the last.
nextOffsetNoThe offset to pass on the next call to continue paging, or null when the result set is exhausted (truncated is false).

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations (readOnly, idempotent) are consistent with the description, which adds behavioral details such as error behavior (invalid_department), paging behavior (empty page at offset beyond total), and limitations (public-domain subset per department).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is organized parameter-by-parameter, with each sentence adding concrete value. Though lengthy, it avoids redundancy and packs essential operational details into a compact, scannable structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the return format (total count, page of object IDs), error conditions, parameter interdependencies, and combination effects. It is fully self-sufficient for an agent to invoke the tool correctly without needing further context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the description enriches every parameter with additional context—e.g., medium maps to classification, dateBegin/dateEnd are paired and accept negative BCE, geoLocation is AND-combined, offset semantics, and the distinction between hasImages and isPublicDomain.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches the Met collection by keyword and optional filters, returns a total match count and a page of object IDs, and differentiates itself from sibling tools (met_get_object retrieves full records, met_list_departments lists departments).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly explains when to use the tool, how to narrow results with filters, and warns about pitfalls like broad-query timeout risk, offset paging semantics, and the need to use met_get_object for full records. It also clarifies when to use alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool has a clearly distinct role: listing departments, searching for object IDs, and resolving those IDs to full records. There is no overlap, and the descriptions explicitly connect search results and department values to the other tools.

Naming Consistency5/5

All tool names use the same met_ prefix and follow a consistent verb_noun pattern: met_get_object, met_list_departments, met_search_collections. The naming makes the tool's action obvious and predictable.

Tool Count5/5

Three tools is a well-scoped set for a museum collection lookup server; each tool earns its place in the search-to-details workflow. The count is not excessive, and no redundant convenience tools inflate the surface.

Completeness5/5

The server covers the full read-oriented lifecycle of the Met API workflow: discover valid departments, search for matching object IDs, and fetch complete object records. There are no obvious dead ends, and the described interlocking of the tools gives agents everything needed to work with the collection.