searchSearch the Smithsonian Open Access collection by keyword. Returns matching items with ids (pass an id to object), titles, creators, dates and image links.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (1-based, default 1). | |
| limit | No | Max results (1-100, default 20). | |
| query | Yes | Keyword(s), e.g. "rembrandt", "ceramics", "moon landing". | |
| _apiKey | No | Smithsonian Open Access API key (auto-injected by the platform; or pass your own). |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / examplesAdded value: +[
+ {
+ "query": "rembrandt paintings"
+ },
+ {
+ "limit": 10,
+ "page": 1,
+ "query": "moon landing"
+ }
+]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only and idempotent. The description adds context about return fields and pagination (via parameter hints), which is valuable beyond the 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 that are direct and front-loaded. Every sentence adds value: first states purpose, second states return details. 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?
For a simple search tool with no output schema, the description covers input (keyword) and output (fields). Pagination is implied via parameters. Missing error handling or rate limit info, but general completeness is high given the tool's simplicity.
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 parameter descriptions. The tool description adds meaning by explaining return fields and how 'id' can be used to retrieve an object, going beyond basic schema info.
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 resource (Smithsonian Open Access collection), action (search by keyword), and return fields (ids, titles, creators, dates, image links). It is specific and distinguishes from sibling tools like 'search_within' by naming the collection.
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 says when to use (keyword search of Smithsonian collection) but does not specify when not to use or compare to alternative sibling tools like 'search_within'. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Many tools serve overlapping purposes, such as the three ask_pipeworx variants (stable, beta, grounded) and the six Polymarket-specific tools. While detailed descriptions help distinguish them, an agent could still confuse bet_research with polymarket_edges or the ask_pipeworx versions.
Naming is highly inconsistent: verb_noun (ask_pipeworx, compare_entities), noun_noun (bet_research, entity_profile), single verbs (forget, recall, search), and adjective_noun (recent_alerts, deep_research). No clear pattern emerges across the set.
33 tools is on the high side for a server named 'Smithsonian' that actually covers a broad range of data sources (SEC, FDA, Polymarket, npm, etc.). The number feels borderline heavy but is still manageable if the server's true purpose is general research.
The tool set covers multiple domains (company financials, drugs, economics, prediction markets, npm, museum data) with reasonable depth. Minor gaps exist, such as lack of PyPI scanning or missing update/delete operations for some memory features, but core workflows are well-supported.