Skip to main content
Glama

smithsonian-mcp-server

by io.github.cyanheads

Find Related Smithsonian Objects

smithsonian_find_related
Read-onlyIdempotent

Discover objects across Smithsonian collections related to a given anchor object, matched on shared metadata signals — culture, period, object type, named parties, and topic terms. Each related object is tagged with the signals that connected it to the anchor; a named-party signal carries the catalog's own role for that party (maker, Collector, Donor, issuing authority, …), not a fixed "maker" label. Matches surface across museums — an NASM aerospace anchor can pull related objects from NMNHPALEO, SAAM, and NMAH.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesrecord_id of the anchor object (e.g. "nasm_A19670093000") from smithsonian_search_objects or smithsonian_get_object.
limitNoMaximum number of related objects to return (default 10, max 20).
startNoPagination offset — 0-indexed. Page contiguously with start = page × limit; each signal is reachable to a depth of 5000 objects, beyond which truncated stays true but deeper pages aren't retrievable.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
capNoThe limit cap that was applied.
errorNoPresent when the call failed. Absent on success.
shownNoNumber of related objects returned.
anchorNoSummary of the anchor object used to drive the fan-out searches.
noticeNoGuidance naming the inputs that retrieve the related objects this page omitted — start for the next page, signals[].search_continuation for a signal past this tool's reach.
relatedNoRelated objects interleaved across the fan-out signals so each signal contributes. Empty when no related objects were found across all fan-out searches.
signalsNoPer-signal breakdown of every fan-out that returned. Use search_continuation with smithsonian_search_objects to retrieve a signal's matches past this tool's 5000-per-signal reach. A signal whose upstream call failed is omitted.
truncatedNoTrue when the related list is incomplete — either capped by the limit or more results exist upstream past the current page (advance start to retrieve them).
truncationCeilingNoUpper bound on the related objects reachable by paging with start. Cross-signal overlaps are not subtracted, so it can overcount. Signals larger than this tool's per-signal reach are counted at that reach — see signals[].row_count for their true size.
search_signals_usedNoMetadata fields that drove the fan-out searches.

TDQS

A4.3/5.0
Behavior4/5

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

The description adds context beyond the readOnlyHint, openWorldHint, and idempotentHint annotations by explaining the matching logic, the dynamic role field for named parties, and the cross-museum behavior. It does not contradict any annotations. The description is informative but could mention error conditions or the depth limit on pagination, though that is also in the schema. Overall, it complements the annotations well.

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

Conciseness5/5

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

The description is two sentences with no fluff: the first sentence states the core function and matching signals, and the second adds the cross-museum nuance and the role semantics. Information is front-loaded, and every clause adds value. The length is appropriate for the complexity.

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

Completeness5/5

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

Given the output schema exists (so return format is covered) and the description explains the matching signals, the role field nuance, and cross-museum behavior, an agent has enough contextual information to decide when to call this tool and what to expect. The example anchors to other tools (search/get) also helps. No critical missing context is apparent for the tool's complexity.

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

Parameters3/5

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

Schema coverage is 100%, with each parameter (id, limit, start) having a clear description in the schema. The tool description does not add additional parameter semantics beyond what the schema already provides. It explains the anchor's example and the meaning of signals, but that relates to output and context, not parameter meaning. Baseline 3 is appropriate since the schema handles the documentation.

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 tool's purpose: discovering related objects across Smithsonian collections based on shared metadata signals. It lists specific signal types and gives a cross-museum example, making it distinct from search, get, browse, and list tools. This is a specific verb-resource-scope combination that an agent can immediately understand.

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?

It provides context about the input anchor (from smithsonian_search_objects or smithsonian_get_object) and explains the matching mechanism, including the cross-museum behavior. However, it does not explicitly say when to avoid this tool or compare it to alternatives like browse_category or list_terms. The purpose is clear enough that an agent can infer usage, but explicit exclusions are missing.

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