smithsonian-mcp-server
Server Details
Search 19.4M Smithsonian Open Access objects, get CC0 images, find cross-collection connections.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.7/5 across 6 of 6 tools scored.
Each tool has a clearly distinct purpose: search, browse, get details, get media, find related, and list vocabulary. No overlapping functionality.
All tools follow the 'smithsonian_' prefix with a consistent verb_noun pattern (e.g., smithsonian_search, smithsonian_get_object). Naming is predictable and clear.
Six tools is appropriate for the domain of museum collection exploration, covering entry point browsing, detailed retrieval, media, relations, and vocabulary without being excessive.
The tool set covers the full lifecycle of exploration: search, browse, get details, get media, find related, and list terms. No obvious gaps for a read-only API.
Available Tools
6 toolssmithsonian_exploreExplore Smithsonian by CategoryARead-onlyIdempotentInspect
Browse Smithsonian collections by category to answer "what does the Smithsonian have about X?" questions. Constructs and executes a category-constrained search, then returns an overview: total count, a curated set of sample objects, and a breakdown of which museums hold matching objects. Four browse modes: museum (by unit code or name), culture (by culture term), period (by decade), medium (by object type). Use as the entry point for open-ended research.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | Browse dimension: "museum" (by unit code/name), "culture" (by culture term), "period" (by decade like "1940s"), "medium" (by object type like "Paintings"). | |
| rows | No | Number of sample objects to return (default 10, max 50). | |
| value | Yes | Category value appropriate to the mode. museum: unit code ("NMNH") or full name ("National Museum of Natural History"). culture: term, often plural or qualified ("Aztecs", "Plains Indian"). period: decade ("1940s", "1860s"). medium: object type, usually plural ("Paintings", "Aircraft"). Smithsonian uses a controlled vocabulary — for culture, place, or unit_code, call smithsonian_list_terms to find exact terms. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The rows cap that was applied. |
| mode | Yes | Browse dimension used for this request (one of "museum", "culture", "period", "medium"). |
| shown | No | Number of sample objects returned. |
| value | Yes | Category value queried, as provided in the request. |
| truncated | No | True when the sample was capped by the rows parameter. |
| total_count | Yes | Total number of Smithsonian objects matching this category. |
| sample_objects | Yes | Representative objects from the category. |
| museum_breakdown | Yes | When mode is not "museum": top contributing museums from the sample, helping plan museum-focused follow-up searches. |
| truncationCeiling | No | Total matching objects (upper bound for omitted items). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds behavioral details: it constructs a constrained search, returns an overview with count, sample objects, and museum breakdown. It also mentions the controlled vocabulary and recommends using smithsonian_list_terms for exact terms. No contradictions.
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 concise and well-structured. The first sentence captures the core purpose. It then explains the return and lists the four modes. Every sentence adds value without redundancy.
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 fully covers the tool's functionality, including the four modes, controlled vocabulary usage, and the nature of the return. It references the sibling tool for term lookup, making it contextually complete. Even without an output schema, the description explains what is returned.
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 coverage is 100% with descriptions for all three parameters. The description adds significant value: it explains the modes with examples (e.g., 'NMNH' for museum, '1940s' for period), clarifies that values should be plural/qualified, and explicitly recommends smithsonian_list_terms for exact terms. This goes well beyond the schema.
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 browses Smithsonian collections by category to answer specific questions. It specifies the four modes (museum, culture, period, medium) and what the tool returns (count, sample objects, museum breakdown). This distinguishes it from sibling tools like smithsonian_search and smithsonian_list_terms.
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?
Explicitly states 'Use as the entry point for open-ended research.' It also advises calling smithsonian_list_terms to find exact terms for controlled vocabulary, providing clear when-to-use and when-not-to-use guidance relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
smithsonian_get_mediaGet Smithsonian Object MediaARead-onlyIdempotentInspect
Return all available CC0 images for a Smithsonian object at multiple resolutions. Only CC0 (open access) images are returned; an object whose media is entirely non-CC0 yields no downloadable images. Each image entry includes thumbnail (~120px), screen-size (~800px), and high-resolution JPEG/TIFF URLs with pixel dimensions. The cc0_only filter on smithsonian_search surfaces objects that have downloadable CC0 images.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | record_id of the object (e.g. "nasm_A19670093000") from smithsonian_search or smithsonian_get_object. |
Output Schema
| Name | Required | Description |
|---|---|---|
| title | Yes | Object title from the catalog record. |
| images | Yes | CC0-licensed images for this object. |
| is_cc0 | Yes | True when the object-level metadata is CC0. |
| record_id | Yes | Smithsonian catalog record ID for the object. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides detailed behavioral traits: only CC0 images are returned, non-CC0 objects yield no images, each entry includes thumbnail and high-res URLs with pixel dimensions. This adds significant context beyond the annotations (readOnlyHint, openWorldHint, idempotentHint), which already indicate safety and idempotency.
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 three focused sentences, each earning its place: main action, limitation (non-CC0), output details, and related search filter. No unnecessary words or repetition.
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's simplicity (one parameter), an output schema exists, and the description covers return contents, limitations, and relationship to sibling tools. It lacks mention of authorization or max images, but these are partially covered by annotations (openWorldHint). Overall, it is sufficiently complete for the complexity level.
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?
With 100% schema coverage, the schema already explains the 'id' parameter as a record_id. The description adds value by specifying that 'id' comes from smithsonian_search or smithsonian_get_object, providing extra context beyond the schema's own description.
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 identifies the tool's purpose: returning all available CC0 images for a Smithsonian object at multiple resolutions. It specifies the resource (CC0 images) and the action (return), and distinguishes from siblings by mentioning the cc0_only filter on smithsonian_search for finding objects with downloadable images.
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 implies when to use this tool (after getting an object id) and mentions the cc0_only filter for searching, but it does not explicitly state when not to use it or provide direct comparisons with siblings like smithsonian_get_object. The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
smithsonian_get_objectGet Smithsonian ObjectARead-onlyIdempotentInspect
Fetch a normalized catalog metadata projection for a Smithsonian object by its record_id (from smithsonian_search results). Returns the exposed catalog fields — title, dates, description, makers, materials, dimensions, place and culture associations, topics, exhibition history, credit line, accession identifiers, rights statement, and a media summary. The media summary is a count; full image URLs come from smithsonian_get_media.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Object record_id from smithsonian_search results (e.g. "nasm_A19670093000"). |
Output Schema
| Name | Required | Description |
|---|---|---|
| dates | Yes | All date fields in the catalog record. |
| place | Yes | Geographic place associations. |
| title | Yes | Object title. |
| is_cc0 | Yes | True when the object metadata is CC0 (open access). Call smithsonian_get_media to get images. |
| makers | Yes | All named parties associated with this object. |
| topics | Yes | Subject and topic terms. |
| culture | Yes | Culture associations. |
| materials | Yes | Physical material descriptions. |
| record_id | Yes | Unique object identifier. |
| unit_code | Yes | Museum unit code. |
| dimensions | Yes | Dimension and measurement strings. |
| credit_line | No | Attribution or credit string. |
| description | No | Best available prose description (Summary, Physical Description, or Brief Description notes). |
| exhibitions | Yes | Exhibition history. |
| identifiers | Yes | All accession and catalog identifiers. |
| museum_name | Yes | Full museum name. |
| record_link | No | Canonical Smithsonian Institution URL for this object. |
| media_summary | Yes | Media availability summary. Call smithsonian_get_media for full image URLs. |
| object_rights | No | Rights statement from the catalog. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, openWorldHint, idempotentHint. The description adds that the media summary is only a count, not URLs, aligning with the openWorldHint for potential changes. No contradictions.
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?
Four sentences, front-loaded with purpose, no fluff. Every sentence provides essential information: purpose, input, output fields, and supplementary tool referral.
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?
With an output schema present, the description covers all necessary aspects: input, output fields, limitations (media count vs URLs), making it complete for selection and invocation.
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?
With 100% schema coverage, the description adds value by specifying that 'id' is the record_id from smithsonian_search and giving an example format, exceeding the schema's description.
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's purpose: 'Fetch a normalized catalog metadata projection for a Smithsonian object by its record_id'. It specifies the input (record_id from search results) and distinguishes from sibling tools like smithsonian_get_media and smithsonian_search.
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 indicates that the tool is used after smithsonian_search to fetch detailed metadata. It also notes that for full image URLs, one should use smithsonian_get_media instead, providing clear differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
smithsonian_list_termsList Valid Filter TermsARead-onlyIdempotentInspect
Enumerate the valid term vocabulary for an indexed Smithsonian filter field (unit_code, culture, place, date, online_media_type). Smithsonian uses a controlled vocabulary where terms are often plural or qualified (e.g. "Paintings", not "Painting"), so filter values guessed rather than drawn from this vocabulary tend to return empty results. Returns a page of the field's distinct term values; large vocabularies (place has 100k+ terms) page via start and rows.
| Name | Required | Description | Default |
|---|---|---|---|
| rows | No | Number of terms to return per page (default 50, max 100). | |
| field | Yes | Indexed field to enumerate. Choices: unit_code (museum codes like "NASM"), culture (e.g. "Aztecs"), place (geographic terms), date (decade/era values like "1920s"), online_media_type (media formats like "Images", "3D Models"). | |
| start | No | Pagination offset (0-indexed). Use with rows to page through large vocabularies. | |
| contains | No | Case-insensitive substring filter on the term vocabulary — resolve a filter value (e.g. "greek") to its exact controlled-vocabulary term(s). |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The rows cap that was applied. |
| field | Yes | The enumerated field, as provided in the request. |
| shown | No | Number of terms returned in this page. |
| terms | Yes | The field's distinct term values for this page, in the Smithsonian index's native order. No per-term object counts are available upstream. |
| total | Yes | Total number of distinct terms for this field (the full vocabulary size; terms is one page of it). |
| notice | No | Guidance when a contains filter matched no terms — how to broaden or drop the filter. |
| truncated | No | True when the term list was capped by the rows parameter. |
| truncationCeiling | No | Distinct terms available for this query (the full vocabulary, or the contains-match count) — upper bound for omitted items. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond readOnlyHint, openWorldHint, and idempotentHint annotations: pagination via start and rows, large vocabularies (place has 100k+ terms), and that results are a page of distinct term values. No contradiction with annotations.
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 two sentences, front-loaded with the core purpose, and every sentence adds essential information. No fluff.
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 4 parameters and an output schema, the description covers the tool's purpose, usage context, behavioral details, and parameter semantics comprehensively. Nothing critical is missing.
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 coverage is 100%, but the description adds meaningful context: controlled vocabulary, why exact terms matter (plural/qualified), and how the 'contains' parameter resolves filter values. This adds value beyond the schema's property descriptions.
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 title 'List Valid Filter Terms' and description 'Enumerate the valid term vocabulary for an indexed Smithsonian filter field (unit_code, culture, place, date, online_media_type)' clearly state the verb and resource. It distinguishes from sibling search tools by focusing on vocabulary enumeration.
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 explains that Smithsonians uses controlled vocabulary and that guessing terms leads to empty results, implying the tool should be used to obtain correct filter values before searching. It could explicitly mention when not to use or name alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
smithsonian_searchSearch Smithsonian CollectionsARead-onlyIdempotentInspect
Search across 19.4 million Smithsonian objects by text query and optional filters. Filters narrow by museum unit, object type, decade, culture, geographic place, 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.
| Name | Required | Description | Default |
|---|---|---|---|
| rows | No | Page size (default 20, max 100). | |
| query | Yes | Free-text search. Use specific terms for precision ("Tlingit totem pole") or broad terms for browsing ("quilt"). | |
| start | No | Pagination offset — 0-indexed. Use with rows for paging through large result sets. | |
| filters | No | Optional structured filters to narrow the search. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | No | The rows cap that was applied. |
| shown | No | Number of objects returned in this page. |
| objects | Yes | Curated object summaries for the current page. |
| truncated | No | True when the result set was capped by the rows parameter. |
| total_count | Yes | Total matching objects in the Smithsonian catalog before pagination. |
| truncationCeiling | No | Total matching objects (upper bound for omitted items). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds behavioral context such as returning curated summaries with specific fields, total match count, and pagination details, going 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 concise yet comprehensive, front-loading the core purpose and then efficiently listing filters and their nuances. Every sentence adds value without redundancy.
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 presence of an output schema (mentioned in context), the description adequately covers return format and pagination. It also addresses filter enumeration and special usage notes, making it complete for a complex search tool.
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?
Although schema coverage is 100%, the description adds significant meaning: for 'query' it advises on specific vs. broad terms; for 'object_type' it warns about plural forms; for filter values it explains how to obtain valid values via sibling tools or from search results.
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 it searches across 19.4 million Smithsonian objects with text and optional filters. It distinguishes from siblings by noting that the returned record_id is used for smithsonian_get_object, smithsonian_find_related, and smithsonian_get_media.
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?
Explicit guidance is given on when to use specific filters (e.g., cc0_only before calling smithsonian_get_media) and how to enumerate filter values using sibling tools (e.g., smithsonian_list_terms). It also advises on query precision vs. broad browsing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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.
Discussions
No comments yet. Be the first to start the discussion!