Skip to main content
Glama

met-museum-mcp-server

by io.github.cyanheads

Get Met Objects

met_get_object
Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
objectIDsYesOne 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

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
failedNoObject IDs that failed to fetch with per-ID error context.
objectsNoSuccessfully fetched objects.

TDQS

A4.5/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

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 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.

Usage Guidelines4/5

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.

All met-museum-mcp-server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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.

Resources