Skip to main content
Glama

smithsonian-mcp-server

Search Smithsonian Objects

smithsonian_search_objects
Read-onlyIdempotent

Recommended first step for open-ended or topic discovery: free-text search across 14.5 million Smithsonian objects, with optional exact filters. Filters narrow by museum unit, object type, indexed date term, culture, geographic place, subject topic, named party, and online/CC0 availability. Returns curated summaries (title, date, museum, thumbnail URL, CC0 flag) with the total match count. The record_id in each result is the identifier for smithsonian_get_object, smithsonian_find_related, and smithsonian_get_media. To browse one exact category — a single museum, culture, date term, object type, or topic — use smithsonian_browse_category instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rowsNoPage size (default 20, max 100).
queryYesFree-text search. Use specific terms for precision ("Tlingit totem pole") or broad terms for browsing ("quilt").
startNoPagination offset — 0-indexed. Use with rows for paging through large result sets.
filtersNoOptional structured filters to narrow the search.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
capNoThe rows cap that was applied.
errorNoPresent when the call failed. Absent on success.
shownNoNumber of objects returned in this page.
noticeNoGuidance naming the input that retrieves the objects this page omitted.
objectsNoCurated object summaries for the current page.
truncatedNoTrue when matching objects remain past this page. False on a terminal or past-the-end page, where nothing is being withheld.
total_countNoTotal matching objects in the Smithsonian catalog before pagination.
truncationCeilingNoTotal matching objects (upper bound for omitted items).

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed6 schema fields changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • addedInput schema / additionalProperties
      Added value: +false
    • changedOutput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • addedOutput schema / anyOf
      Added value: +[
      +  {
      +    "not": {
      +      "required": [
      +        "error"
      +      ]
      +    },
      +    "required": [
      +      "objects",
      +      "total_count"
      +    ]
      +  },
      +  {
      +    "required": [
      +      "error"
      +    ]
      +  }
      +]
    • addedOutput schema / properties / error
      Added 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`: An unfiltered query matched no objects. `invalid_filter`: A filtered search matched nothing — most often a filter value outside the Smithsonian controlled vocabulary (e.g. a singular \"Painting\" instead of \"Paintings\"). Other values are possible when a failure originates below the handler.",
      +          "examples": [
      +            "no_results",
      +            "invalid_filter"
      +          ],
      +          "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"
      +}
    • removedOutput schema / required
      Removed value: -[
      -  "objects",
      -  "total_count"
      -]
  2. Changed2 schema fields changed
    • changedInput schema / properties / filters / properties / object_type / description
      Previous value: -"Object type term from Smithsonian's controlled vocabulary — commonly plural (e.g. \"Paintings\", \"Photographs\", \"Aircraft\"). Singular everyday forms like \"Painting\" usually return nothing. This field is not enumerable via smithsonian_list_terms; harvest valid values from the object_type field in smithsonian_search_objects results."New value: +"Object type term from Smithsonian's controlled vocabulary — commonly plural (e.g. \"Paintings\", \"Photographs\", \"Aircraft\"). Singular everyday forms like \"Painting\" usually return nothing. This field is not enumerable via smithsonian_list_terms; harvest valid values from the object_type field in smithsonian_search_objects results. Matched exactly and case-sensitively, and casing variants are indexed as SEPARATE categories — \"button\" and \"Button\" each hold their own records, and neither casing is reliably the larger — so probe a harvested value's other casings rather than assuming one covers the concept."
    • changedOutput schema / properties / objects / items / properties / object_type / description
      Previous value: -"Object type term (e.g. \"Aircraft\", \"Paintings\", \"Photographs\")."New value: +"Object type term (e.g. \"Aircraft\", \"Paintings\", \"Photographs\"). Harvest it here to filter a later search, but it is case-sensitive and casing variants are separate categories upstream — this row carries one casing of the concept, not all of it."
  3. Changed2 schema fields changed
    • addedInput schema / properties / filters / properties / name
      Added value: +{
      +  "description": "Indexed named party — maker, collector, donor, issuing authority, or any other role the catalog records. Written surname-first (e.g. \"Warhol, Andy\"). This field is not enumerable via smithsonian_list_terms. A smithsonian_find_related name signal carries the indexed form verbatim and is the reliable source; smithsonian_get_object's makers[] is the catalog's free-text form of the same parties and is often written differently (\"Major J. A. L. Möller (Jacob A.L. Möller/Monty Möller), Non-Indian, 1883-1957\" for the indexed \"Möller, Major J. A. L.\"), so treat it as a starting guess.",
      +  "type": "string"
      +}
    • addedInput schema / properties / filters / properties / topic
      Added value: +{
      +  "description": "Subject term from the controlled vocabulary (e.g. \"Quilts\", \"Aviation\"). Matches the topics[] values smithsonian_get_object returns, and is a hard constraint — topic \"Quilts\" matches 1,134 objects where the same word as free text matches 2,677. The full set is enumerable via smithsonian_list_terms (field \"topic\").",
      +  "type": "string"
      +}
  4. Changed5 schema fields changed
    • changedInput schema / properties / filters / properties / cc0_only / description
      Previous value: -"When true, restrict to CC0 open-access objects. Useful before calling smithsonian_get_media."New value: +"When true, restrict to records that have CC0-licensed media attached (the Lucene term media_usage:CC0). This selects on media presence, not license status — the roughly 9.2M records it excludes are CC0 too, they simply have nothing digitized. Read has_media on each result to decide whether smithsonian_get_media will return anything."
    • addedInput schema / properties / filters / properties / date
      Added value: +{
      +  "description": "Indexed date term. Decades (\"1920s\", \"1960s\") are the most common form, but the vocabulary also carries year ranges (\"500-1500\"), century terms (\"21st century\"), and BCE forms (\"-2500\", \"BCE 1000s\"). The value must be an exact term — the full set is enumerable via smithsonian_list_terms (field \"date\").",
      +  "type": "string"
      +}
    • removedInput schema / properties / filters / properties / date_decade
      Removed value: -{
      -  "description": "Decade filter (e.g. \"1920s\", \"1960s\"). Must match the \"NNNNs\" format exactly. Indexed decades are enumerable via smithsonian_list_terms (field \"date\").",
      -  "pattern": "^\\d{4}s$",
      -  "type": "string"
      -}
    • changedOutput schema / properties / objects / items / properties / date / description
      Previous value: -"Decade-level date the catalog indexes for the object (e.g. \"1960s\"). Sparse — omitted when the record has no indexed date."New value: +"Indexed date term for the object — commonly a decade (\"1960s\"), but the vocabulary also carries year ranges (\"500-1500\"), century terms (\"21st century\"), and BCE forms (\"-2500\", \"BCE 1000s\"). Sparse — omitted when the record has no indexed date."
    • changedOutput schema / properties / objects / items / properties / is_cc0 / description
      Previous value: -"True when the object metadata is CC0 (open access). Use smithsonian_get_media for CC0 image downloads."New value: +"True when the object metadata is CC0 (open access). The Smithsonian Open Access corpus is CC0 throughout, so this flag rarely varies and cannot gate an image download — read has_media for that."
  5. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already establish readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile with no contradiction from the description. Beyond that, the description adds substantive behavioral context: it states the return format ('curated summaries (title, date, museum, thumbnail URL, CC0 flag) with the total match count'), the cc0_only filter's media-presence-not-license semantics, online_only's surrogate vocabulary behavior, and the record_id threading to three downstream tools. Even with strong annotations, this description adds real value beyond the structured fields.

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?

Three sentences with zero waste, and the most decision-relevant fact — role as first discovery step — is front-loaded ahead of the filter list and alternative routing. Every sentence earns its place: purpose, filter capability, return format, cross-tool linkage, and the exclusion are each collapsed into one efficient clause. No redundancy with the schema's own descriptions.

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?

Given the complexity (4 top-level params plus a nested 8-field filters object), the presence of an output schema, and strong annotations, the description is complete. The schema exhaustively documents every parameter, the output schema covers return values, and the description positions the tool as a discovery entry point and links it to downstream tools. For a search tool whose safety profile (read-only, idempotent, open-world) is already declared, nothing an agent needs to invoke it correctly is missing.

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?

Schema description coverage is 100%, and the schema itself carries exceptionally rich parameter definitions — date-term vocabulary forms, name vocabulary discrepancies, topic hard-constraint counts, object_type case-sensitivity behavior. With coverage above 80%, the baseline of 3 applies: the description carries the load via the schema rather than its own text. The description does add light framing ('optional exact filters' signals exact-match semantics, record_id linkage tells the agent how to thread results), but parameter-level meaning lives almost entirely in the schema, so 3 is the fair score.

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-plus-resource statement — 'free-text search across 14.5 million Smithsonian objects, with optional exact filters' — and immediately frames the tool's role ('Recommended first step for open-ended or topic discovery'). It names the sibling it is not by routing exact-category browsing to smithsonian_browse_category, making the distinction explicit. Nothing about what this tool does is ambiguous.

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?

Explicit when-to-use guidance is front-loaded ('Recommended first step for open-ended or topic discovery') and the when-not-to-use case is stated outright: 'To browse one exact category — a single museum, culture, date term, object type, or topic — use smithsonian_browse_category instead.' The alternative tool is named and the selection condition is concrete, leaving no inference required.

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.6/5.0
Disambiguation5/5

Each tool has a clearly distinct role: browsing an exact category, searching free-text, retrieving object metadata, fetching media, listing vocabulary, and finding related objects. Overlaps like browse_category vs search_objects are well-explained with explicit guidance on when to use each, eliminating ambiguity.

Naming Consistency5/5

All tools follow the same pattern: 'smithsonian_' prefix with lowercase snake_case verb_noun names (e.g., browse_category, get_media, list_terms). The naming is perfectly uniform and intuitive.

Tool Count5/5

Six tools cover the full spectrum of Smithsonian discovery and retrieval without bloat. Each tool addresses a distinct need, and the count is well-scoped for a read-only museum API.

Completeness5/5

The surface covers search, exact-category browsing, term vocabulary enumeration, object metadata retrieval, media access, and related-object discovery. There are no obvious dead ends—record IDs flow from search to other tools, and gaps like non-CC0 media are explicitly handled.