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.5/5 across 6 of 6 tools scored.
Each tool has a clearly distinct purpose: search, browse by category, fetch full object record, retrieve media, find related objects, and list vocabulary terms. There is no functional overlap.
All tool names follow a consistent 'smithsonian_verb_noun' pattern (e.g., smithsonian_search, smithsonian_get_object), making them predictable and easy to learn.
With 6 tools, the server is well-scoped for exploring the Smithsonian collections. Each tool serves a necessary role without redundancy or unnecessary complexity.
The tool set covers the full lifecycle of exploration: vocabulary discovery (list_terms), search and browse (search, explore), detailed record retrieval (get_object), media access (get_media), and serendipitous discovery (find_related). No obvious gaps for the stated purpose.
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 "Painting"). | |
| 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 ("Aztec", "Sioux"). period: decade ("1940s", "1860s"). medium: object type ("Painting", "Aircraft", "Fossil"). |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | Yes | The rows cap that was applied. |
| mode | Yes | Browse dimension used for this request (one of "museum", "culture", "period", "medium"). |
| shown | Yes | Number of sample objects returned. |
| value | Yes | Category value queried, as provided in the request. |
| truncated | Yes | 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, openWorldHint. Description adds that it constructs a category-constrained search and returns an overview, providing useful behavioral context without contradicting 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?
Two sentences cover purpose, output, modes, and usage recommendation. Entirely front-loaded with no redundant information.
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 moderate complexity (3 parameters, 4 modes, overview output), the description covers purpose, output summary, and entry point recommendation. Output schema handles return structure details, so description is sufficient.
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%, providing baseline of 3. Description adds examples and detailed usage guidance for each mode and value format (e.g., unit codes, decade strings), enhancing understanding beyond schema alone.
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?
Description clearly states that the tool browses Smithsonian collections by category to answer open-ended questions, and specifies the return overview: total count, sample objects, and museum breakdown. It distinguishes itself from sibling tools by being the entry point for open-ended research.
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?
Description explicitly recommends using as entry point for open-ended research, implying it's for broad exploration rather than specific queries. Does not explicitly contrast with sibling tools, but the context of alternatives is clear enough from their names.
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 — throws Forbidden when an object has media but none of it is CC0. Each image entry includes thumbnail (~120px), screen-size (~800px), and high-resolution JPEG/TIFF URLs with pixel dimensions. Use smithsonian_search with filters.cc0_only to find CC0 objects before calling this tool.
| 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?
Goes beyond annotations by detailing the CC0-only restriction, the Forbidden error behavior, and the exact resolution URLs returned. Annotations already indicate idempotent and read-only, but description adds valuable behavioral context.
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?
Three sentences: first states purpose, second explains restrictions and error, third gives usage guidance. Front-loaded, no redundant words.
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 tool with output schema, the description is very complete: covers behavior, restrictions, error, and upstream tool usage. Sibling tools are referenced appropriately.
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 the description of the 'id' parameter. The tool description repeats the schema info without adding new semantic meaning beyond what is already in 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?
Clearly states the tool returns all CC0 images for a Smithsonian object at multiple resolutions, with specific details about resolution sizes. It distinguishes itself from siblings by referencing 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?
Explicitly advises using smithsonian_search with filters.cc0_only before calling this tool. Clearly describes the error condition when no CC0 media exists. Does not explicitly mention when not to use, but 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_get_objectGet Smithsonian ObjectARead-onlyIdempotentInspect
Fetch the full catalog record for a Smithsonian object by its record_id (from smithsonian_search results). Returns all available metadata: title, dates, materials, dimensions, provenance, exhibition history, credit line, accession identifiers, and a media summary. Call smithsonian_get_media for full image URLs. Use record_id values from smithsonian_search — do not manually construct IDs.
| 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 already indicate readOnly, openWorld, and idempotent. The description adds value by listing returned metadata fields (title, dates, etc.) and clarifying that the media summary is not full images, providing context beyond 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?
Two sentences, each purposeful. Front-loaded with action and resource, followed by details, then a warning. 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?
With only one parameter and an output schema available, the description is complete. It covers what the tool does, what it returns, where to get input, and what related tool to use for media.
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%. Description explains the parameter's source (search results) and provides an example format, adding meaning beyond the schema's type and 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?
Description clearly states the tool fetches the full catalog record for a Smithsonian object using a record_id. It distinguishes from sibling tools like smithsonian_search (for searching) and smithsonian_get_media (for media), and explicitly references the source of IDs.
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?
Provides explicit guidance: use record_id from smithsonian_search results, do not manually construct IDs, and calls smithsonian_get_media for full images. This helps the agent choose the correct tool and avoid errors.
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. Call this before using smithsonian_search or smithsonian_explore filters to discover exact term strings — guessing filter values produces empty results. Returns the distinct terms sorted by object count descending, so the most-populated terms appear first.
| Name | Required | Description | Default |
|---|---|---|---|
| rows | No | Number of terms to return per page (default 50, max 100). | |
| field | Yes | Indexed field to enumerate. Common choices: unit_code (museum codes like "NASM"), object_type (artifact categories like "Aircraft"), culture (e.g. "Aztec"), place (geographic terms), date (decade values like "1920s"). | |
| start | No | Pagination offset (0-indexed). Use with rows to page through large vocabularies. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cap | Yes | The rows cap that was applied. |
| field | Yes | The enumerated field, as provided in the request. |
| shown | Yes | Number of terms returned in this page. |
| terms | Yes | Valid term vocabulary for the field, sorted by count descending. |
| total | Yes | Total number of distinct terms for this field in the Smithsonian index. |
| truncated | Yes | True when the term list was capped by the rows parameter. |
| truncationCeiling | No | Total distinct terms for the field (upper bound for omitted items). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, openWorldHint, idempotentHint, which are consistent. Description adds that results are sorted by object count descending, revealing the ordering behavior beyond what annotations convey.
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 succinct, using three sentences to convey purpose, usage order, and result ordering. No extraneous words, front-loaded with action verb 'Enumerate'.
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 and annotations covering safety, the description adequately covers usage context, sorting behavior, and scenario. No gaps remain for a lookup 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?
Schema coverage is 100%, so baseline 3. Description enriches field parameter with examples like 'NASM' and 'Aircraft', and explains pagination offset use, adding significant contextual value 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 enumerates valid term vocabulary for an indexed field. It distinguishes itself from sibling tools like smithsonian_search and smithsonian_explore by specifying its role as a prerequisite lookup.
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 instructs to use before smithsonian_search or smithsonian_explore to discover exact term strings, warning that guessing leads to empty results. This provides clear when-to-use and when-not-to-use guidance.
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 | Yes | The rows cap that was applied. |
| shown | Yes | Number of objects returned in this page. |
| objects | Yes | Curated object summaries for the current page. |
| truncated | Yes | 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, idempotentHint, openWorldHint. The description adds useful behavior: returns curated summaries with specific fields and total match count, and explains pagination via start and rows. No contradictions 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 a single paragraph that is front-loaded with purpose, then filters, then return info, then ID usage. Every sentence adds value without redundancy. Efficient and well-structured for an AI agent.
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 has an output schema (implied by 'curated summaries'), the description fully covers what is needed: query + filters, pagination, and how to use results with sibling tools. No gaps 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?
Schema coverage is 100% with descriptions, but the description adds significant guidance: examples for query ('Tlingit totem pole'), explains each filter and how to get valid values using list_terms, and clarifies pagination semantics (0-indexed). This greatly aids parameter understanding.
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 19.4 million objects by text query and optional filters, and distinguishes from siblings by noting record_id is used for get_object, find_related, and get_media. Specific verb 'search' plus resource 'Smithsonian Collections' with scope.
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?
Provides context on when to use filters and how to enumerate valid values via smithsonian_list_terms, and mentions using results with sibling tools. However, does not explicitly differentiate from smithsonian_explore, which could be a comparable tool for 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!