Search 14.5M Smithsonian Open Access objects across 20+ museums via MCP, and retrieve CC0 images for the 5.2M that carry openly-licensed media. STDIO or Streamable HTTP.
Five well-named, read-only tools with clear descriptions (avg 156 chars) and complete input schemas. All parameters are typed and described. Tool names follow verb_noun convention (browse, find, get, list). Schemas use proper enums for constrained inputs (mode, field). Output schemas are not explicitly documented in the source provided, limiting visibility into response structure. Error handling and recovery guidance are not evident in the tool definitions. No tool annotations (readOnlyHint) despite all being read-only operations.
Browse objects within one exact Smithsonian category by museum, culture, period, medium, or topic. Returns paginated results with recovery hints for zero-match categories.
Discover objects across Smithsonian collections related to a given anchor object, matched on shared metadata signals — culture, period, object type, named parties, and topic terms. Each related object is tagged with the signals that connected it to the anchor.
Return every CC0 (open-access) image for a Smithsonian object at multiple resolutions. Each image entry includes thumbnail (~120px), screen-size (~800px), and high-resolution JPEG/TIFF URLs with pixel dimensions.
Fetch a normalized catalog metadata projection for a Smithsonian object by its record_id. Returns the exposed catalog fields — title, dates, description, makers, materials, dimensions, places, cultures, topics, exhibitions, credit line, identifiers, rights, and a media summary.
Enumerate the valid term vocabulary for an indexed Smithsonian filter field (unit_code, culture, place, date, online_media_type, topic). Returns a page of the field's distinct term values; large vocabularies page via start and rows.
Output schemas not documented in source. Tool descriptions state what is returned (e.g., 'paginated results', 'CC0 images at multiple resolutions') but formal response schemas are not visible. LLMs cannot plan downstream tool calls or extract specific fields without knowing the response structure.
No error handling or recovery guidance in tool definitions. Descriptions do not explain what happens on invalid input (e.g., non-existent category, invalid record_id) or how the LLM should recover. Pattern 'recovery-guide' requires actionable error messages.
Tool annotations missing. All five tools are read-only (no state modification), but readOnlyHint is not declared in the tool definitions. This forces the LLM to infer safety from descriptions rather than machine-readable metadata.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 79 | 2026-07-28+ | v2 |
Parameter descriptions lack format/constraint details. 'limit' and 'start' parameters state defaults and max values in descriptions, but 'id' and 'value' parameters do not explain expected format (e.g., 'record_id format: museum_code + alphanumeric ID'). This invites invalid input from LLMs.
No pagination guidance in descriptions. Tools accept 'limit' and 'start' parameters but descriptions do not explain the pagination contract (e.g., 'Returns total count or next_cursor for chaining calls'). Agents cannot reliably iterate through large result sets.