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 5 of 5 tools scored.
Each tool has a uniquely defined purpose: browse by category, text search, full object record, media retrieval, and related objects discovery. No two tools overlap in functionality, making it easy for an agent to choose the correct one.
All tools follow a consistent pattern of 'smithsonian_' prefix followed by a descriptive verb in snake_case (explore, find_related, get_media, get_object, search). The naming is uniform and predictable.
With five tools, the server covers all essential operations for interacting with the Smithsonian collections—search, browse, detail retrieval, media access, and related discovery—without being bloated or sparse.
The tool surface provides a full workflow: entering through search or browse, retrieving full object records, accessing media, and finding related items. No obvious gaps exist for typical use cases.
Available Tools
5 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 |
|---|---|---|
| mode | Yes | Browse dimension used for this request (one of "museum", "culture", "period", "medium"). |
| value | Yes | Category value queried, as provided in the request. |
| 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, openWorld, and idempotent hints. The description adds behavioral context: it constructs a category-constrained search, returns an overview with total count, sample objects, and museum breakdown. 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 three sentences with no wasted words. It front-loads the purpose, then the output structure, then enumerates modes. Every sentence contributes essential 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 presence of an output schema and annotations, the description covers the main use case and output components. It could mention potential error states or limitations, but overall it is sufficient for a tool with three well-documented parameters.
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 provides additional usage tips for the 'value' parameter per mode (e.g., unit code vs full name for museum, decade format for period), enhancing clarity beyond the 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?
The description clearly states it browses Smithsonian collections by category to answer 'what does the Smithsonian have about X?' questions, specifying four distinct browse modes (museum, culture, period, medium). It distinguishes itself from sibling tools like 'smithsonian_search' by focusing on category-constrained exploration.
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 recommends using this tool as an entry point for open-ended research and clarifies each browse mode with examples. While it doesn't explicitly contrast with sibling tools or state when not to use, the context and mode enumeration provide sufficient guidance.
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 declare readOnlyHint, openWorldHint, and idempotentHint, which cover safety and idempotency. The description adds value by listing the specific metadata fields returned (title, dates, etc.), beyond what annotations provide. 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?
Two sentences, front-loaded with purpose, no wasted words. Every sentence serves a distinct function: purpose, return summary, usage instruction.
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 a single parameter, complete schema coverage, existence of output schema, and annotations covering behavioral traits, the description is fully adequate. It tells how to get the id, what is returned, and directs to a sibling tool for related functionality.
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% and includes a description for the 'id' parameter. The description adds crucial context: use values from smithsonian_search, don't manually construct, and gives an example format. This adds value beyond the 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?
The description clearly states the action ('Fetch the full catalog record'), specifies the resource ('Smithsonian object'), and distinguishes from sibling tools like smithsonian_get_media. It uses the specific verb 'Fetch' and identifies the required input (record_id from search results).
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 explicitly tells when to use this tool (after smithsonian_search), what not to do (manually construct IDs), and points to an alternative (smithsonian_get_media for image URLs). This provides clear guidance for agent decision-making.
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 |
|---|---|---|
| objects | Yes | Curated object summaries for the current page. |
| total_count | Yes | Total matching objects in the Smithsonian catalog before pagination. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, openWorldHint, idempotentHint. The description adds behavioral details: results spill to DataCanvas, max page size 100, pagination offset, and filtering constraints. 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?
Extremely concise (3-4 sentences) and well-structured: purpose first, then filters, output summary, and integration hint. Every sentence adds essential information with no 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 complexity (5 parameters, nested filters, output schema exists), the description covers search behavior, filter usage, output format, and sibling tool integration. Output schema handles return details, so no gap.
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%. The description enhances parameter meaning with examples (e.g., 'Tlingit totem pole'), format rules (date_decade must be 'NNNNs'), and behavior (rows beyond 20 spill to DataCanvas). Adds significant 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 searches across 19.4 million Smithsonian objects by text query and optional filters. It specifies the resource (Smithsonian objects) and action (search), and distinguishes from siblings by linking record_id to other tools.
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 clear context on when to use (text query with optional filters) and hints about filtering (search first for valid values). Lacks explicit when-not-to-use or direct alternatives, but the integration hints with sibling tools are helpful.
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!