Skip to main content
Glama

smithsonian-mcp-server

by io.github.cyanheads

List Valid Filter Terms

smithsonian_list_terms
Read-onlyIdempotent

Enumerate 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rowsNoNumber of terms to return per page (default 50, max 100).
fieldYesIndexed 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).
startNoPagination offset (0-indexed). Use with rows to page through large vocabularies.
containsNoCase-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".

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
capNoThe rows cap that was applied.
errorNoPresent when the call failed. Absent on success.
fieldNoThe enumerated field, as provided in the request.
shownNoNumber of terms returned in this page.
termsNoThe field's distinct term values for this page, in the Smithsonian index's native order. No per-term object counts are available upstream.
totalNoTotal number of distinct terms for this field (the full vocabulary size; terms is one page of it).
labelsNoMuseum 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.
noticeNoGuidance naming the input that retrieves the terms this page omitted, or how to broaden a contains filter that matched nothing.
truncatedNoTrue when matching terms remain past this page. False on a terminal or past-the-end page, where nothing is being withheld.
truncationCeilingNoDistinct terms available for this query (the full vocabulary, or the contains-match count) — upper bound for omitted items.

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description is not burdened with the basic safety profile. It adds valuable behavioral details: pagination through large vocabularies (topic 133k, place 114k), and the special unit_code behavior (returning museum names and matching on them). This goes beyond the schema and annotations, giving the agent a realistic expectation of output and quirks.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is detailed but every sentence contributes. The purpose is front-loaded, and the vocabulary-size caveat is strategically placed. While it runs longer than typical, the complexity of the tool (multiple fields, pagination, contains behavior) justifies the length. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity and that an output schema exists (so return format is covered), the description is thorough. It explains the controlled-vocabulary caveat, pagination needs, and the special unit_code behavior. One minor gap: it does not mention whether results are sorted or whether there are any rate limits, but these are not critical for correct invocation. Overall, complete enough for an agent to use effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description enriches the parameters with concrete examples for each field enum (e.g., unit_code 'NASM', topic 'Quilts'), explains the 'contains' parameter's substring behavior including case-insensitivity and unit_code name matching, and clarifies pagination with start/rows. This adds practical value beyond the schema's bare definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Enumerate' and the resource 'valid term vocabulary for an indexed Smithsonian filter field', listing the specific fields. This unambiguously distinguishes it from the sibling tools like search_objects or browse_category, which handle different operations. The purpose is specific and actionable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains why this tool is needed (controlled vocabulary means guessed filters often fail) and implies when to use it (before constructing filter queries). It does not explicitly name alternatives or exclusion conditions, but the context is clear enough that an agent would know to use this to resolve valid filter values. Slight deduction for not explicitly contrasting with siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All smithsonian-mcp-server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
Disambiguation5/5

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

Naming Consistency5/5

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

Tool Count5/5

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

Completeness5/5

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

Resources