The Etsy MCP server provides 7 tools with consistent naming, clear descriptions, and well-defined input schemas. All tools follow verb_noun naming conventions (search_, get_) and have substantive descriptions (90-190 chars). Input schemas are complete with proper JSON Schema types, enums, and min/max constraints. However, the server lacks output schema documentation, error handling guidance, and some parameter descriptions could be more specific about expected formats. No security patterns are evident (API key exposure, no permission gates). The server is STDIO-only, which caps protocol readiness at 50.
Get detailed information about a specific Etsy listing by its ID.
Get information about an Etsy shop by its shop name.
Get all active listings from a specific Etsy shop.
Get reviews for a specific Etsy shop.
Get trending listings on Etsy. Returns currently popular items.
Search for active listings on Etsy. Returns product listings matching the search criteria.
No output schema documentation. Tool descriptions state what they do, but LLMs cannot plan downstream operations without knowing the exact response structure. Missing fields that chain to other tools (e.g., shop_id from search_shops for use in get_shop_listings) force extra lookup calls.
No error handling guidance. The server exposes axios error responses without transformation. LLMs receive raw HTTP errors (404, 401, 429, 5xx) with no actionable recovery steps. E.g., 'API rate limited' should suggest 'wait and retry' or 'batch requests differently', not an error stack.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
Search for Etsy shops by name or keywords.
API credentials exposed as environment variable (ETSY_API_KEY). While not passed as a tool parameter, the pattern matches anti-pattern: credentials could leak if the MCP server process is introspected or logs are captured. No evidence of secure secret injection or vault integration.
No output result limits enforced. Tools accept limit params (1-100) but code does not validate or truncate responses. Etsy API may return paginated results, if an agent requests limit=100 repeatedly, context window exhaustion is possible. No mention of pagination handling in descriptions.
Parameter descriptions lack format/constraint details. E.g., 'shop_name' (get_shop_by_name) is described as 'The name/slug of the shop' but does not clarify: case sensitivity? URL-encoded? Max length? These are inferred from the Etsy API docs, not from the MCP server definition, forcing LLMs to guess or make unsafe assumptions.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All tools are read-only against Etsy (no mutations), but this is never declared. Lack of annotations forces LLMs to reason about side effects rather than rely on explicit metadata. Current MCP spec (2026-07-28) supports tool annotations for safety classification.