io.github.cyanheads/smithsonian-mcp-server

It requires SMITHSONIAN_API_KEY, which is a sensitive credential; if configured poorly or logged excessively, it could be exposed and abused to access the related API. MCP_LOG_LEVEL is not a secret, but verbose logging may increase the chance of sensitive data appearing in logs.

The materials show outbound connections to smithsonian.caseyjhand.com, indicating external network transmission. Based on the stated function, this is likely for Smithsonian data queries, but the materials do not explain request contents, whether user queries or context are forwarded, or how this domain relates to Smithsonian officially, so the scope of data egress warrants attention.

System checks indicate that the tool executes code or runs a local process, which is standard behavior for an MCP server. The available materials do not show requests for system privileges clearly beyond what would be expected for a collection-search tool, so this is not high risk by itself, but it should still be run with least privilege.

Beyond environment variables, the materials do not specify which local files, caches, or log locations are read or written, so the local data access boundary is not fully transparent. There is no explicit evidence of overbroad access, but it should be assumed to access at least the local configuration and logging environment exposed to the running process.

Positive factors include being listed in the official registry, open source, and updated within the last year, which materially lowers supply-chain risk because the code is in principle auditable. Points to watch are the near-empty README, undeclared license, and 0 stars, meaning weaker public usage and review signals; overall this supports a caution rating rather than high risk.