Search 14.5M Smithsonian Open Access objects, get CC0 images, find cross-collection connections.
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.
Average 4.6/5 across 6 of 6 tools scored.
Each tool has a clearly distinct purpose: search_objects for free-text exploration, browse_category for exact category browsing, get_object for full metadata, get_media for images, find_related for discovering related objects, and list_terms for vocabulary enumeration. Cross-references in descriptions clarify when to use each.
All tool names follow the consistent verb_noun pattern in snake_case (e.g., smithsonian_search_objects, smithsonian_get_media), with the prefix 'smithsonian_' for all. No mixing of conventions or vague verbs.
With 6 tools, the server is well-scoped for the purpose of accessing the Smithsonian collection. Each tool serves a distinct and necessary function without overlap or omission, covering search, detail retrieval, media, related objects, and vocabulary exploration.
The tool surface covers all essential operations for interacting with a read-only museum API: free-text search, exact category browsing, object metadata, image media, related object discovery, and controlled vocabulary enumeration. No obvious gaps remain for the stated domain.
smithsonian_browse_categoryBrowse Smithsonian by CategoryABrowse Smithsonian objects within one exact category — a single museum (mode "museum"), culture, indexed date term (mode "period"), object type (mode "medium"), or subject term (mode "topic"). The value must be an exact indexed category term, not free text: resolve museum, culture, period, and topic vocabulary with smithsonian_list_terms first (object_type is not enumerable there — harvest it from smithsonian_search_objects results, and treat each casing as its own category, since a harvested object_type covers only the casing it was written in). Returns the category total count, a page of matching objects, and a museum breakdown of that page; page the full category with start and rows. For open-ended or topic discovery, start with smithsonian_search_objects instead.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | Browse dimension: "museum" (by unit code), "culture" (by culture term), "period" (by indexed date term like "1940s" or "500-1500"), "medium" (by object type like "Paintings"), "topic" (by subject term like "Quilts"). | |
| rows | No | Number of sample objects to return (default 10, max 50). | |
| start | No | Pagination offset — 0-indexed. Page contiguously with start = page × rows. | |
| value | Yes | Category value appropriate to the mode. museum: a unit code like "NASM", "SAAM", or "NMNHBIRDS", matched literally and case-sensitively — not a museum name. culture: term, often plural or qualified ("Aztecs", "Plains Indian"). period: an indexed date term — commonly a decade ("1940s", "1860s"), but year ranges ("500-1500"), century terms ("21st century"), and BCE forms ("-2500", "BCE 1000s") are indexed too. medium: object type, usually plural ("Paintings", "Aircraft"). topic: subject term ("Quilts", "Aviation"). Smithsonian uses a controlled vocabulary — for museum (unit_code), culture, period (date), and topic, call smithsonian_list_terms to find exact terms; medium (object_type) is not enumerable there, so harvest it from smithsonian_search_objects results. Every mode matches its value exactly and case-sensitively, and for medium that split is load-bearing: casing variants are indexed as SEPARATE categories, each reporting its own total_count ("button" and "Button" are different categories, and neither casing is reliably the larger), so browse the variants of a harvested value rather than assuming one covers the concept. |
| 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", "topic"). |
| shown | No | Number of sample objects returned. |
| value | Yes | Category value queried, as provided in the request. |
| notice | No | Guidance naming the input that retrieves the objects this page omitted. |
| truncated | No | True when matching objects remain past this page. False on a terminal or past-the-end page, where nothing is being withheld. |
| total_count | Yes | Total number of Smithsonian objects matching this category. |
| sample_objects | Yes | The requested page of objects matching the category, in upstream order. Empty when start is past the end of 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). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotation hints (readOnly, openWorld, idempotent), the description adds critical behavioral details: values must be exact indexed terms, matching is case-sensitive, and casing variants are separate categories each with unique counts. It also clarifies pagination and the need to harvest medium terms from search results.
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 dense paragraph that front-loads the core purpose, then supplies constraints, then gives alternative guidance. Every sentence contributes information, with no fluff or repetition of schema content.
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 needn't detail return fields, but it still describes what the output includes (total count, page, museum breakdown), discusses pagination via start/rows, and addresses edge cases like casing and vocabulary resolution. It is fully complete for a browse tool of this complexity.
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?
Even though schema covers all parameters, the description adds essential cross-tool guidance (e.g., call smithsonian_list_terms first, harvest object_type from search results) and explains the output composition (total count, page, museum breakdown). It enriches the raw schema definitions with practical usage context.
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 objects within one exact category, enumerating all five modes (museum, culture, period, medium, topic) and explicitly distinguishing itself from smithsonian_search_objects by advising that open-ended discovery use that tool instead. This is a specific verb+resource statement that differentiates it from siblings.
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?
It provides explicit when-to-use guidance: resolve vocabulary with smithsonian_list_terms for museum/culture/period/topic, harvest object_type from smithsonian_search_objects, and use smithsonian_search_objects for open-ended discovery. Exclusions and alternatives are named clearly.
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 MediaAReturn every CC0 (open-access) image for a Smithsonian object at multiple resolutions. The tool never returns an empty list — it names the reason instead: an object with nothing digitized, an object whose media is entirely non-image (scanned books, 3D models, sound recordings), and an object whose images are entirely non-CC0 each fail with their own reason. 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_objects 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_objects or smithsonian_get_object. |
| 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. The Open Access corpus is CC0 throughout, so this rarely varies; the per-image is_cc0 flag is what gates delivery. |
| record_id | Yes | Smithsonian catalog record ID for the object. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals key behaviors not covered by annotations: it never returns an empty list, names specific failure reasons (non-digitized, non-image, non-CC0), and details the resolution levels (thumbnail, screen-size, high-res with pixel dimensions). This adds substantial context beyond the readOnly/idempotent hints.
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 compact and front-loaded. The first sentence states the core function; the second explains exceptional behaviors; the third connects to the sibling search tool. Each sentence adds unique value 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 tool has a single parameter, an output schema, and rich annotations, the description covers all essential context: what it returns (multiple resolutions), how failures are reported, and how to find objects with CC0 media. Nothing critical is missing for an agent to select and invoke this tool correctly.
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 the description does not add meaning beyond the schema's parameter description. The schema already explains that id is the record_id and shows an example. Since the schema carries the full weight, the baseline 3 is appropriate.
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 begins with a specific verb+resource: 'Return every CC0 (open-access) image for a Smithsonian object at multiple resolutions.' This clearly distinguishes from sibling tools like smithsonian_get_object (metadata) and smithsonian_search_objects (search), and even references the CC0 filter on the search tool, making the tool's unique purpose unmistakable.
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 clearly implies when to use this tool (when you need media for a specific object) and references smithsonian_search_objects' cc0_only filter as a way to find objects with downloadable CC0 images. However, it doesn't explicitly exclude scenarios or name alternatives for other media types beyond images, so it lacks a complete when-not-to-use statement.
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 ObjectAFetch a normalized catalog metadata projection for a Smithsonian object by its record_id (from smithsonian_search_objects results). Returns the exposed catalog fields — title, dates, description, makers, materials, dimensions, places, cultures, topics, exhibitions, credit line, identifiers, rights, 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_objects results (e.g. "nasm_A19670093000"). |
| 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). The Smithsonian Open Access corpus is CC0 throughout, so this flag rarely varies — read media_summary.has_cc0_images to predict whether smithsonian_get_media returns 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. A few rarely-indexed archive sub-unit codes have no mapped name and fall back to the raw unit code. |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and openWorld; the description adds meaningful details by listing the exposed catalog fields and clarifying that the media summary is a count. This goes beyond the annotations by explaining output structure and a behavioral nuance (count vs. URLs), though it doesn't discuss further side effects or required permissions.
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: the first states the core action and input source, the second enumerates return fields and the media caveat. Every sentence adds value and the structure is front-loaded.
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?
An output schema exists, so the description does not need to itemize return formatting. It effectively covers the purpose, input source, output scope, and relationship to the media tool, making it complete for this simple single-parameter 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?
The schema already covers the single 'id' parameter with a description and example, so the description adds no new parameter-level semantics beyond tying it to search results. With 100% schema coverage, the baseline of 3 is appropriate.
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 fetches a 'normalized catalog metadata projection' by record_id, specifying the exact resource and action. It distinguishes itself from sibling tools like smithsonian_get_media by noting that full image URLs are obtained there.
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?
It explicitly ties the input to results from smithsonian_search_objects and points to smithsonian_get_media for images, giving clear contextual guidance. It does not explicitly state when not to use the tool, but the linkage to search results and media tool provides strong usage context.
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 TermsAEnumerate the valid term vocabulary for an indexed Smithsonian filter field (unit_code, culture, place, date, online_media_type, topic). Terms are a controlled vocabulary — often plural or qualified (e.g. "Paintings", not "Painting") — so guessed filter values tend to return nothing. Returns a page of the field's distinct term values; large vocabularies (topic has 133k terms, place 114k) page via start and rows. For unit_code, each code is returned with its museum name and contains matches the name as well as the code, so a museum name resolves to its code in one call.
| 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"), topic (subject terms like "Quilts" — 133k terms, so pair it with contains). | |
| 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). For unit_code the substring also matches each code's museum name, so "National Air and Space" resolves to "NASM". |
| 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). |
| labels | No | Museum name for each unit_code on this page that has one — present only when field is "unit_code". A few rarely-indexed archive sub-unit codes have no mapped name and are absent from this map; their term is still returned in terms. |
| notice | No | Guidance naming the input that retrieves the terms this page omitted, or how to broaden a contains filter that matched nothing. |
| truncated | No | True when matching terms remain past this page. False on a terminal or past-the-end page, where nothing is being withheld. |
| truncationCeiling | No | Distinct terms available for this query (the full vocabulary, or the contains-match count) — upper bound for omitted items. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnly/openWorld/idempotent hints, and the description adds crucial behavioral context: controlled vocabulary with plural/qualified terms, pagination behavior, and unit_code museum-name matching. 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?
Three sentences with no fluff. It front-loads the purpose, then provides essential caveats and special-case behavior. Every sentence contributes concrete guidance.
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 thorough annotations, the description covers all necessary aspects: purpose, controlled vocabulary pitfalls, pagination, and unit_code behavior. It is fully complete for an enumeration 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%, but the description adds significant semantic value: it explains why guessed values fail, how 'contains' works with unit_code museum names, and the scale of topic/place vocabularies for pagination—beyond what the schema descriptions state.
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 the valid term vocabulary for indexed Smithsonian filter fields, listing the specific fields. It distinguishes this from sibling tools by focusing on vocabulary enumeration rather than object retrieval or browsing.
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?
It explains that guessed filter values return nothing, implying the tool should be used to obtain valid terms before filtering. It also gives pagination guidance for large vocabularies and notes unit_code museum-name resolution, but it does not explicitly name alternative tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
smithsonian_search_objectsSearch Smithsonian ObjectsARecommended 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.
| 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. |
| Name | Required | Description |
|---|---|---|
| cap | No | The rows cap that was applied. |
| shown | No | Number of objects returned in this page. |
| notice | No | Guidance naming the input that retrieves the objects this page omitted. |
| objects | Yes | Curated object summaries for the current page. |
| truncated | No | True when matching objects remain past this page. False on a terminal or past-the-end page, where nothing is being withheld. |
| total_count | Yes | Total matching objects in the Smithsonian catalog before pagination. |
| truncationCeiling | No | Total matching objects (upper bound for omitted items). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety and side-effect profile is covered. The description adds non-obvious behavioral details such as returning 'curated summaries (title, date, museum, thumbnail URL, CC0 flag) with the total match count' and that record_id is the identifier for related tools. This goes beyond the annotations and enriches the agent's understanding, though it does not delve deeply into pagination or edge-case behavior.
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 front-loaded with the primary use case. It consists of four focused sentences, each earning its place: the tool's purpose and scope, filter capabilities, return format and cross-links, and an explicit alternative. No filler or redundant content is present.
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 complexity (free-text + complex filters, nested objects) and the presence of a rich output schema, the description is complete: it states when to use it, what it returns, how it connects to sibling tools, and when to use an alternative. The schema details cover parameter specifics, and the description covers operational context, making it fully sufficient for an AI agent.
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?
The input schema covers 100% of parameters with detailed descriptions, including nuanced guidance on enumerable fields, case sensitivity, and exact matching. The tool description itself only generically mentions 'optional exact filters' and lists filter types without adding parameter-specific semantics beyond the schema. Therefore, the baseline of 3 applies because the schema carries the heavy lifting.
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 opens with 'Recommended first step for open-ended or topic discovery: free-text search across 14.5 million Smithsonian objects, with optional exact filters.' This clearly identifies the tool as a search operation with a specific resource and scope. It also distinguishes itself from the sibling tool smithsonian_browse_category by explicitly recommending the alternative for exact-category browsing.
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 provides explicit usage guidance: it is the 'recommended first step for open-ended or topic discovery' and states that for browsing a single exact category, one should use smithsonian_browse_category instead. It also mentions that record_id links to smithsonian_get_object, smithsonian_find_related, and smithsonian_get_media, which helps the agent decide when to use this tool as a precursor.
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.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.