MET Museum collection via MCP — 500K+ artworks, metadata, provenance, open-access images.
Fetch full records for one or more Met Museum object IDs. Accepts up to 20 IDs per call and returns partial success — a single 404 does not fail the whole batch; per-ID failures are reported separately. Object IDs come from met_search_collections. Non-public-domain objects return empty image URLs. The constituents array is null for anonymous or unattributed works; tags is null for untagged objects.
| Name | Required | Description | Default |
|---|---|---|---|
| objectIDs | Yes | One or more Met object IDs to fetch. Maximum 20 per call. IDs come from met_search_collections. Partial failures are reported per ID rather than failing the whole batch. |
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| failed | No | Object IDs that failed to fetch with per-ID error context. |
| objects | No | Successfully fetched objects. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate read-only and idempotent behavior, so the description carries the burden of disclosing runtime behaviors. It does so thoroughly: partial success semantics, per-ID 404 handling, empty image URLs for non-public-domain objects, and null conditions for constituents and tags. This is rich, non-obvious behavioral detail that helps an agent set expectations and interpret results.
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?
Every sentence earns its place: purpose, batch size, failure semantics, ID source, and null/empty-field behavior. The most decision-relevant facts are front-loaded, and there is no repetitive or promotional filler.
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 single-parameter read-only tool with an output schema, the description covers all critical calling concerns: input source, batch limits, failure handling, and response field edge cases. An agent has everything it needs to call this tool correctly and interpret the response, and the sibling context completes the surrounding workflow.
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?
The input schema already documents the single parameter with 100% coverage, including the source of IDs, the 20-item maximum, and partial-failure behavior. The description adds no new parameter-level meaning, so the baseline 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?
The description opens with a specific verb and resource: 'Fetch full records for one or more Met Museum object IDs.' It clearly distinguishes the tool from siblings met_list_departments and met_search_collections, which are about listing departments and searching rather than retrieving records by ID.
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 clear workflow context by stating that object IDs come from met_search_collections, telling the agent when this tool is appropriate after a search. It does not explicitly list when-not-to-use scenarios or alternatives, but the intended usage is unmistakable from the purpose and ID provenance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the 19 curatorial departments at The Metropolitan Museum of Art, each with its numeric departmentId and display name — the valid values for the met_search_collections departmentId filter.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| departments | No | All 19 curatorial departments at The Metropolitan Museum of Art. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows this is a safe, repeatable read operation. The description adds only the count (19) and the format (id + name) but doesn't disclose whether results are sorted, which is minor. It doesn't contradict annotations, and the added context is useful but minimal 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?
The description is a single compact sentence that front-loads the purpose and output format, and immediately connects to the sibling tool's usage. No wasted words; every clause 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 is parameterless and has an output schema, there is very little the description must cover. It fully explains the purpose, the data returned, and how the data is used in relation to a sibling. It could mention sorting or that it's a static list, but that is a minor gap; the description is complete for practical agent use.
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?
The tool has 0 parameters, so there is nothing to document. The description adds clarity about what the return data is (id and display name) even though no parameters exist. This gives the agent confidence about the output shape, which is valuable since the schema for parameters is empty.
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 states a specific verb ('Return'), a specific resource ('19 curatorial departments'), and the exact output ('numeric departmentId and display name'). It also distinguishes itself from siblings by noting these are the valid values for the met_search_collections departmentId filter, making it clear this is a reference/enumeration tool, not a search or retrieval tool.
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 explicitly says the output provides valid values for the met_search_collections departmentId filter, which tells the agent when to use this tool: when it needs to know allowed department IDs for filtering. It implies this is a preliminary lookup step before using search. It also indirectly contrasts with the siblings (get for single objects, search for queries).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Keyword query, matched across title, artist name, culture, medium, tags, and other text fields. Broad terms return large ID sets. | |
| limit | No | Maximum 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. | |
| medium | No | Filter 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". | |
| offset | No | Zero-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. | |
| dateEnd | No | Latest object date (year, inclusive). Negative integers for BCE. Requires dateBegin. | |
| isOnView | No | When 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. | |
| dateBegin | No | Earliest object date (year, inclusive). Negative integers for BCE (e.g., -500 for 500 BCE). Requires dateEnd. | |
| hasImages | No | When 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. | |
| geoLocation | No | Filter 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. | |
| isHighlight | No | When true, restricts to objects the Met has designated as highlights — major works central to the collection. | |
| departmentId | No | Restrict 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. | |
| isPublicDomain | No | When 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. |
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| total | No | Total number of matching objects in the Met collection (may far exceed the returned IDs). |
| returned | No | Count of object IDs in this response — may be less than `total` when the full result set was truncated by `limit`. |
| objectIDs | No | Object IDs for this page, up to `limit` results. |
| remaining | No | Count of matching object IDs after this page: total − (offset + returned), floored at 0. 0 means this is the last page. |
| truncated | No | True when matching IDs remain beyond this page (offset + returned < total); false when this page is the last. |
| nextOffset | No | The offset to pass on the next call to continue paging, or null when the result set is exhausted (truncated is false). |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
met_get_object6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "objects",
+ "failed"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode. Declared by this tool: `all_not_found`: Every requested objectID returned a 404 — all IDs are stale or invalid. `all_failed`: Every requested objectID failed due to network errors or API downtime. Other values are possible when a failure originates below the handler.",
+ "examples": [
+ "all_not_found",
+ "all_failed"
+ ],
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "objects",
- "failed"
-]met_list_departments6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "departments"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode.",
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / requiredRemoved value: -[
- "departments"
-]met_search_collections7 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesAdded value: +falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / anyOfAdded value: +[
+ {
+ "not": {
+ "required": [
+ "error"
+ ]
+ },
+ "required": [
+ "total",
+ "objectIDs",
+ "returned",
+ "truncated",
+ "remaining",
+ "nextOffset"
+ ]
+ },
+ {
+ "required": [
+ "error"
+ ]
+ }
+]Output schema / properties / errorAdded value: +{
+ "additionalProperties": {},
+ "description": "Present when the call failed. Absent on success.",
+ "properties": {
+ "code": {
+ "description": "JSON-RPC error code for this failure.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "data": {
+ "additionalProperties": {},
+ "properties": {
+ "reason": {
+ "description": "Machine-readable failure mode. Declared by this tool: `no_results`: total is 0 — the API returned null objectIDs for this query+filter combination. `invalid_date_range`: dateBegin or dateEnd is provided without the other, or dateBegin > dateEnd. `invalid_department`: departmentId is provided but is not one of the Met department IDs. `search_timeout`: The result set is too large to download within the request timeout — a broad, unfiltered query. Other values are possible when a failure originates below the handler.",
+ "examples": [
+ "no_results",
+ "invalid_date_range",
+ "invalid_department",
+ "search_timeout"
+ ],
+ "type": "string"
+ },
+ "recovery": {
+ "additionalProperties": {},
+ "description": "Actionable next step for the caller.",
+ "properties": {
+ "hint": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hint"
+ ],
+ "type": "object"
+ },
+ "retryable": {
+ "description": "Whether retrying may succeed.",
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "message": {
+ "description": "Human-readable description of what went wrong.",
+ "type": "string"
+ }
+ },
+ "required": [
+ "code",
+ "message"
+ ],
+ "type": "object"
+}Output schema / properties / objectIDs / descriptionPrevious value: -"Object IDs for the first `limit` results."New value: +"Object IDs for this page, up to `limit` results."Output schema / requiredRemoved value: -[
- "total",
- "objectIDs",
- "returned",
- "truncated",
- "remaining",
- "nextOffset"
-]met_get_object2 fields changedInput schema / properties / objectIDs / descriptionPrevious value: -"One or more Met object IDs to fetch. Maximum 20 per call. IDs come from met_search_collections. Fetches run in parallel (concurrency-limited); partial failures are reported per ID rather than failing the whole batch."New value: +"One or more Met object IDs to fetch. Maximum 20 per call. IDs come from met_search_collections. Partial failures are reported per ID rather than failing the whole batch."Output schema / properties / objects / items / properties / objectBeginDate / descriptionPrevious value: -"Earliest date as an integer year (negative = BCE). Use for date range comparisons."New value: +"Earliest date as an integer year (negative = BCE)."met_search_collections12 fields changedInput schema / properties / departmentId / descriptionPrevious value: -"Restrict results to one curatorial department. Call met_list_departments to get valid IDs — the Met exposes a sparse set (roughly 1–21, with gaps), and 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 — use isPublicDomain alone when CC0 coverage is the goal."New value: +"Restrict 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."Input schema / properties / geoLocation / descriptionPrevious value: -"Filter 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; use a single value for broader results. Works best with the Egyptian Art, Greek and Roman Art, and similar departments that have well-populated geography fields."New value: +"Filter 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."Input schema / properties / hasImages / descriptionPrevious value: -"When true, restricts results to objects that have at least one associated image. For freely reusable CC0 images, use isPublicDomain instead — hasImages includes copyrighted works whose images cannot be reproduced."New value: +"When 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."Input schema / properties / isHighlight / descriptionPrevious value: -"When true, restricts to objects the Met has designated as highlights — major works central to the collection. Use to surface iconic pieces rather than browsing the full corpus."New value: +"When true, restricts to objects the Met has designated as highlights — major works central to the collection."Input schema / properties / isOnView / descriptionPrevious value: -"When 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. Combine with a keyword to answer \"what is on display right now?\" — pairs well with isHighlight for must-see works."New value: +"When 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."Input schema / properties / isPublicDomain / descriptionPrevious value: -"When 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. Can be combined with departmentId but severely restricts results (the search index only indexes a subset of public-domain objects per department); prefer using isPublicDomain alone and filtering by department from the returned object records."New value: +"When 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."Input schema / properties / limit / descriptionPrevious value: -"Maximum number of object IDs to return from the full result set. The API returns all matches (up to tens of thousands) — this caps what is handed back. Chain the returned IDs to met_get_object in batches of up to 20."New value: +"Maximum 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."Input schema / properties / offset / descriptionPrevious value: -"Zero-based index into the full result set to start from (default 0). Paginate by passing the nextOffset returned by a previous call; each page re-runs the upstream search and applies the offset locally, so a broad query carries the same timeout risk on every page — narrow it with filters if paging times out. An offset at or beyond total returns an empty page, not an error."New value: +"Zero-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."Input schema / properties / q / descriptionPrevious value: -"Keyword query. Searched across title, artist name, culture, medium, tags, and other text fields. Use concise, specific terms — broad queries return large ID sets. Tip: departmentId and geoLocation sharpen results far more than a longer query string."New value: +"Keyword query, matched across title, artist name, culture, medium, tags, and other text fields. Broad terms return large ID sets."Output schema / properties / objectIDs / descriptionPrevious value: -"Object IDs for the first `limit` results. Pass to met_get_object (up to 20 at a time) to retrieve full records."New value: +"Object IDs for the first `limit` results."Output schema / properties / objectIDs / items / descriptionPrevious value: -"A Met object ID. Pass to met_get_object to retrieve the full record."New value: +"A Met object ID."Output schema / properties / truncated / descriptionPrevious value: -"True when matching IDs remain beyond this page (offset + returned < total). Pass nextOffset as offset to fetch the next page, increase limit, or refine filters to narrow results."New value: +"True when matching IDs remain beyond this page (offset + returned < total); false when this page is the last."met_search_collections6 fields changedInput schema / properties / departmentId / descriptionPrevious value: -"Restrict results to one curatorial department. Use met_list_departments to get valid IDs (1–21, not all integers are valid). Can be combined with other filters; combining with isPublicDomain works but returns far fewer results than expected — use isPublicDomain alone when CC0 coverage is the goal."New value: +"Restrict results to one curatorial department. Call met_list_departments to get valid IDs — the Met exposes a sparse set (roughly 1–21, with gaps), and 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 — use isPublicDomain alone when CC0 coverage is the goal."Input schema / properties / offsetAdded value: +{
+ "default": 0,
+ "description": "Zero-based index into the full result set to start from (default 0). Paginate by passing the nextOffset returned by a previous call; each page re-runs the upstream search and applies the offset locally, so a broad query carries the same timeout risk on every page — narrow it with filters if paging times out. An offset at or beyond total returns an empty page, not an error.",
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+}Output schema / properties / nextOffsetAdded value: +{
+ "anyOf": [
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "The offset to pass on the next call to continue paging, or null when the result set is exhausted (truncated is false)."
+}Output schema / properties / remainingAdded value: +{
+ "description": "Count of matching object IDs after this page: total − (offset + returned), floored at 0. 0 means this is the last page.",
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+}Output schema / properties / truncated / descriptionPrevious value: -"True when total > returned. Increase `limit`, refine filters, or add keywords to narrow results."New value: +"True when matching IDs remain beyond this page (offset + returned < total). Pass nextOffset as offset to fetch the next page, increase limit, or refine filters to narrow results."Output schema / requiredPrevious value: -[
- "total",
- "objectIDs",
- "returned",
- "truncated"
-]New value: +[
+ "total",
+ "objectIDs",
+ "returned",
+ "truncated",
+ "remaining",
+ "nextOffset"
+]met_get_object3 fields changedInput schema / properties / objectIDs / descriptionPrevious value: -"One or more Met object IDs to fetch. Maximum 20 per call. IDs come from met_search. Fetches run in parallel (concurrency-limited); partial failures are reported per ID rather than failing the whole batch."New value: +"One or more Met object IDs to fetch. Maximum 20 per call. IDs come from met_search_collections. Fetches run in parallel (concurrency-limited); partial failures are reported per ID rather than failing the whole batch."Input schema / properties / objectIDs / items / descriptionPrevious value: -"A Met object ID from met_search."New value: +"A Met object ID from met_search_collections."Output schema / properties / objects / items / properties / hasCC0Image / descriptionPrevious value: -"True when a CC0 open-access image URL is available (primaryImage is non-empty). Distinct from met_search's hasImages filter, which matches objects that have any image including copyrighted works."New value: +"True when a CC0 open-access image URL is available (primaryImage is non-empty). Distinct from met_search_collections's hasImages filter, which matches objects that have any image including copyrighted works."met_list_departments1 field changedOutput schema / properties / departments / items / properties / departmentId / descriptionPrevious value: -"Numeric department ID for use in the met_search departmentId parameter."New value: +"Numeric department ID for use in the met_search_collections departmentId parameter."met_searchmet_search_collectionsmet_get_object3 fields changedOutput schema / properties / objects / items / properties / hasCC0ImageAdded value: +{
+ "description": "True when a CC0 open-access image URL is available (primaryImage is non-empty). Distinct from met_search's hasImages filter, which matches objects that have any image including copyrighted works.",
+ "type": "boolean"
+}Output schema / properties / objects / items / properties / hasImagesRemoved value: -{
- "description": "True when primaryImage is non-empty.",
- "type": "boolean"
-}Output schema / properties / objects / items / requiredPrevious value: -[
- "objectID",
- "title",
- "isPublicDomain",
- "hasImages",
- "primaryImage",
- "primaryImageSmall",
- "additionalImages",
- "objectURL",
- "department",
- "objectName",
- "classification",
- "isHighlight",
- "isTimelineWork",
- "artistDisplayName",
- "artistDisplayBio",
- "artistNationality",
- "artistBeginDate",
- "artistEndDate",
- "constituents",
- "objectDate",
- "objectBeginDate",
- "objectEndDate",
- "medium",
- "dimensions",
- "culture",
- "period",
- "dynasty",
- "accessionNumber",
- "creditLine",
- "country",
- "region",
- "tags",
- "objectWikidata_URL",
- "GalleryNumber"
-]New value: +[
+ "objectID",
+ "title",
+ "isPublicDomain",
+ "hasCC0Image",
+ "primaryImage",
+ "primaryImageSmall",
+ "additionalImages",
+ "objectURL",
+ "department",
+ "objectName",
+ "classification",
+ "isHighlight",
+ "isTimelineWork",
+ "artistDisplayName",
+ "artistDisplayBio",
+ "artistNationality",
+ "artistBeginDate",
+ "artistEndDate",
+ "constituents",
+ "objectDate",
+ "objectBeginDate",
+ "objectEndDate",
+ "medium",
+ "dimensions",
+ "culture",
+ "period",
+ "dynasty",
+ "accessionNumber",
+ "creditLine",
+ "country",
+ "region",
+ "tags",
+ "objectWikidata_URL",
+ "GalleryNumber"
+]met_get_objectmet_list_departmentsmet_searchClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Art MCP — Metropolitan Museum of Art Collection API (free, no auth)
Cleveland Museum of Art Open Access API (~63k artworks, many CC0)
Unlock a world of art with the Met Museum MCP! Use the 'search_artworks' API to find stunning
Add one secure layer between your agents and this server.
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.
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.
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.
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.