met-museum-mcp-server

List Met Objects

met_list_objects

Read-onlyIdempotent

Browse the Metropolitan Museum of Art collection without a keyword: every object ID in one curatorial department, every object whose record was created or revised on or after a date, or both together. Returns the total count and one page of IDs in ascending order, which met_get_object resolves to full records. With no filter the list is the whole collection (over 500,000 IDs). departmentId takes an ID from met_list_departments; updatedSince takes a YYYY-MM-DD date and answers "what has the Met added or revised since this day". Paging has no depth limit — pass nextOffset to continue. For keyword, classification, place, or object-date filters use met_search_collections instead. A list is cached for up to an hour, so a record revised within the last hour may not appear yet.

Input Schema

Name	Required	Description
`limit`	No	Maximum number of object IDs to return in this page. A page holds at most 500 IDs: a larger value reads a 500-ID page and the notice says so — continue from nextOffset.
`offset`	No	Zero-based index of the first ID to return (default 0); pass the nextOffset from a previous response to continue paging. IDs are in ascending order and every one is reachable; an offset at or past total returns an empty page rather than an error.
`departmentId`	No	Restrict the list 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 answered with an empty list.
`updatedSince`	No	List only objects whose record was created or revised on or after this date, the day itself included, as YYYY-MM-DD (e.g., "2026-09-01") — no time part and no other date format. It compares the UTC date of each record's metadataDate, which met_get_object returns. A date later than the newest update returns an empty list, not an error.

Output Schema

Name	Required	Description
`error`	No	Present when the call failed. Absent on success.
`total`	No	Total number of objects matching the filters. Paging reaches every one of them — there is no 10,000 window here.
`notice`	No	Present when total is 0: names the filters that matched nothing and how to widen the list. Also present when a limit above 500 was read as a 500-ID page with IDs still remaining: says the page was read with limit 500 and to continue from nextOffset.
`offset`	No	The resolved offset this page was read from — the offset input after its default of 0. When it is at or beyond a nonzero total, the page is empty because the offset ran past the list, not because nothing matched.
`returned`	No	Count of object IDs in this page.
`objectIDs`	No	Object IDs for this page in ascending order, up to `limit` results and never more than 500.
`remaining`	No	Count of IDs after this page: total minus (offset + returned), floored at 0. 0 means no further page exists.
`truncated`	No	True when IDs remain after this page (offset + returned < total); false when this page ends the list.
`nextOffset`	No	The offset to pass on the next call to continue paging, or null when this page ends the list (truncated is false).
`effectiveQuery`	No	The filters as applied, as name=value pairs with JSON-encoded values — an updatedSince before 1753-01-01 shows as 1753-01-01, the date sent — or "no filter (whole collection)". limit and offset are left out.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 4, 2026

changedInput schema / properties / limit / description

Previous value: -"Maximum number of object IDs to return in this page. A page holds at most 500 IDs: a larger value, up to 10,000, reads a 500-ID page and the notice says so — continue from nextOffset."New value: +"Maximum number of object IDs to return in this page. A page holds at most 500 IDs: a larger value reads a 500-ID page and the notice says so — continue from nextOffset."

removedInput schema / properties / limit / maximum
```
Removed value: -10000
```

Changed6 schema fields changedOct 15, 2026

changedInput schema / properties / limit / description

Previous value: -"Maximum number of object IDs to return in this page."New value: +"Maximum number of object IDs to return in this page. A page holds at most 500 IDs: a larger value, up to 10,000, reads a 500-ID page and the notice says so — continue from nextOffset."

changedInput schema / properties / limit / maximum
```
Previous value: -500New value: +10000
```

changedOutput schema / properties / error / properties / data / properties / reason / description

Previous value: -"Machine-readable failure mode. Declared by this tool: `invalid_department`: departmentId is provided but is not one of the Met department IDs. `invalid_date`: updatedSince has the YYYY-MM-DD shape but names no calendar day, such as 2026-02-30. `upstream_blocked`: The Met API's firewall refused the request with HTTP 403 — it blocks this server's address, not one endpoint. `upstream_unavailable`: The Met API answered HTTP 500, 502, 503, or 504 to the department lookup or the ID list until the retry ladder ran out — an outage on its side. `retry_deadline_exceeded`: The call's time budget ran out, retries and backoff included, before the Met API returned a successful response to the department lookup or the ID list. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `invalid_department`: departmentId is provided but is not one of the Met department IDs. `invalid_date`: updatedSince has the YYYY-MM-DD shape but names no calendar day, such as 2026-02-30. `upstream_blocked`: The Met API's firewall refused the request with HTTP 403 — it blocks this server's address, not one endpoint. `upstream_unavailable`: The Met API answered HTTP 500, 502, 503, or 504 to the department lookup or the ID list until the retry ladder ran out — an outage on its side. `upstream_rate_limited`: The Met API answered HTTP 429 to the department lookup or the ID list until the retry ladder ran out, or asked for a wait longer than the ladder or the call's time budget allows — it throttles this server's address, not one filter. `retry_deadline_exceeded`: The call's time budget ran out, retries and backoff included, before the Met API returned a successful response to the department lookup or the ID list. Other values are possible when a failure originates below the handler."

changedOutput schema / properties / error / properties / data / properties / reason / examples

Previous value: -[
-  "invalid_department",
-  "invalid_date",
-  "upstream_blocked",
-  "upstream_unavailable",
-  "retry_deadline_exceeded"
-]New value: +[
+  "invalid_department",
+  "invalid_date",
+  "upstream_blocked",
+  "upstream_unavailable",
+  "upstream_rate_limited",
+  "retry_deadline_exceeded"
+]

changedOutput schema / properties / notice / description

Previous value: -"Present only when total is 0: names the filters that matched nothing and how to widen the list."New value: +"Present when total is 0: names the filters that matched nothing and how to widen the list. Also present when a limit above 500 was read as a 500-ID page with IDs still remaining: says the page was read with limit 500 and to continue from nextOffset."

changedOutput schema / properties / objectIDs / description

Previous value: -"Object IDs for this page in ascending order, up to `limit` results."New value: +"Object IDs for this page in ascending order, up to `limit` results and never more than 500."

Changed4 schema fields changedOct 4, 2026

changedInput schema / properties / updatedSince / description

Previous value: -"List only objects whose record was created or revised on or after this date, the day itself included, as YYYY-MM-DD (e.g., \"2026-09-01\") — no time part and no other date format. A date later than the newest update returns an empty list, not an error."New value: +"List only objects whose record was created or revised on or after this date, the day itself included, as YYYY-MM-DD (e.g., \"2026-09-01\") — no time part and no other date format. It compares the UTC date of each record's metadataDate, which met_get_object returns. A date later than the newest update returns an empty list, not an error."

addedOutput schema / properties / effectiveQuery

Added value: +{
+  "description": "The filters as applied, as name=value pairs with JSON-encoded values — an updatedSince before 1753-01-01 shows as 1753-01-01, the date sent — or \"no filter (whole collection)\". limit and offset are left out.",
+  "type": "string"
+}

changedOutput schema / properties / error / properties / data / properties / reason / description

Previous value: -"Machine-readable failure mode. Declared by this tool: `invalid_department`: departmentId is provided but is not one of the Met department IDs. `invalid_date`: updatedSince has the YYYY-MM-DD shape but names no calendar day, such as 2026-02-30. `upstream_blocked`: The Met API's firewall refused the request with HTTP 403 — it blocks this server's address, not one endpoint. `retry_deadline_exceeded`: The call's time budget ran out, retries and backoff included, before the Met API returned a successful response to the department lookup or the ID list. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `invalid_department`: departmentId is provided but is not one of the Met department IDs. `invalid_date`: updatedSince has the YYYY-MM-DD shape but names no calendar day, such as 2026-02-30. `upstream_blocked`: The Met API's firewall refused the request with HTTP 403 — it blocks this server's address, not one endpoint. `upstream_unavailable`: The Met API answered HTTP 500, 502, 503, or 504 to the department lookup or the ID list until the retry ladder ran out — an outage on its side. `retry_deadline_exceeded`: The call's time budget ran out, retries and backoff included, before the Met API returned a successful response to the department lookup or the ID list. Other values are possible when a failure originates below the handler."

changedOutput schema / properties / error / properties / data / properties / reason / examples

Previous value: -[
-  "invalid_department",
-  "invalid_date",
-  "upstream_blocked",
-  "retry_deadline_exceeded"
-]New value: +[
+  "invalid_department",
+  "invalid_date",
+  "upstream_blocked",
+  "upstream_unavailable",
+  "retry_deadline_exceeded"
+]

AddedSep 30, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond readOnly/idempotent annotations, it discloses several behaviors an agent cannot infer: results are ascending IDs with a total count, pages are capped at 500 IDs, a one-hour cache can hide very recent revisions, an offset past total returns an empty page rather than an error, and department IDs are sparse (roughly 1–21 with gaps). These are precisely the non-obvious traits that affect call strategy.

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

Conciseness4/5

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

The most decision-relevant information — scope and the sibling alternative — is front-loaded, and every sentence carries content. There is minor duplication of schema facts (the 500-ID page cap and the YYYY-MM-DD format appear in both), which keeps it from being maximally tight, but nothing is padding.

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?

An output schema exists, so return values need not be explained, yet the description still sketches the shape (total count plus one page of IDs) and how met_get_object resolves them to full records. Combined with paging, caching, and error-behavior notes, nothing an agent needs in order to call this four-parameter tool correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds genuine intent-level meaning: departmentId is sourced from met_list_departments, updatedSince answers 'what has the Met added or revised since this day', and nextOffset is the paging cursor. It stops short of adding format detail beyond the schema (the YYYY-MM-DD and 500-page-cap facts are already in the schema text), so it is not a full 5.

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 opens with a specific verb+resource combination ('Browse the Metropolitan Museum of Art collection without a keyword') and immediately enumerates the exact scopes: one department, an updated-since date, or both. It explicitly separates itself from met_search_collections (keyword/classification/place/object-date) and met_list_departments (source of departmentId), so an agent can route correctly without opening a schema.

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?

It states when to use this tool (browse without a keyword), when to switch ('For keyword, classification, place, or object-date filters use met_search_collections instead'), and the alternative for department IDs. It also covers the no-filter case ('the whole collection, over 500,000 IDs') and paging continuation via nextOffset, which is exactly the guidance an agent needs before calling.

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

All met-museum-mcp-server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.