Loading ToolBench
The Etsy MCP server has 9 tools with basic structure but significant quality gaps. Most tools lack comprehensive descriptions and several have incomplete or missing parameter documentation. Tool naming follows action-verb conventions (get_, create_, list_, set_) which is positive. However, parameter descriptions are often minimal, schema completeness varies, and error handling guidance is absent. The server relies on Zod for validation at definition time, which is good, but the definitions themselves lack the depth needed for optimal LLM reasoning. Most tools score in the 40-60 range, bringing the overall average to the low-50s, typical of community servers with working implementations but incomplete quality specifications.
Initiate authentication with Etsy via browser.
Create a new listing in your Etsy shop
Create a new shipping profile for a shop
Gets the currently configured default Etsy shop ID and name.
Get all active listings for a shop
Get details for a specific shop
Get shipping profiles for a specific shop
Multiple tools have empty or minimal input schemas (set_default_shop, get_default_shop, authenticate). While these happen to be correct for these tools, the code uses `@ts-ignore` comments to suppress SDK type errors, indicating schema definitions may be incomplete or misaligned with the SDK. This creates technical debt and makes the schema less discoverable.
Output schemas are NOT documented for any tool. The rubric baseline requires 100% of A+ tools to have documented return types. Tools like get_listings, get_shop_details, list_shop_shipping_profiles return API response objects, but the agent has no visibility into the structure of those responses, field names, types, nested objects. This forces LLMs to infer output structure and wastes tokens on guesswork.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Fetches your Etsy shops and sets the first one found as default. If you have multiple shops, it will use the first one returned by Etsy.
Upload an image for a listing from a local file path
create_shop_shipping_profile accepts a generic 'profile_data' object with description 'Shipping profile data' but provides no schema for the nested object structure. The LLM has no guidance on what fields are required, their types, or constraints. This is a critical gap for a write operation, the agent cannot validate input before attempting to create a resource.
Error handling is minimal. Tools catch errors and call a generic handleError() method, but the code does not show what that method returns or whether it provides actionable guidance. Examples: 'Authentication required. Please run authenticate first.' (good) but most tools would return raw API errors without context. The rubric baseline requires error responses to tell the LLM what to do next.
No pagination or result limiting is visible for list_shop_shipping_profiles or get_listings. If a shop has hundreds of listings or shipping profiles, returning all of them in one response blows the context window. The rubric baseline requires pagination with limit/offset parameters and a total count.
Tool descriptions lack depth and LLM-optimization guidance. Examples: 'Get all active listings for a shop' (60 chars, acceptable but minimal); 'Create a new listing in your Etsy shop' (40 chars, under the 50-char baseline for complexity); 'Get shipping profiles for a specific shop' (43 chars). None explain WHEN to use the tool vs. alternatives, what fields are returned, or prerequisite steps. Per the rubric, descriptions should be 10 - 1024 chars and answer WHAT, WHEN, and RETURNS.
Parameters lack descriptions in several cases. Examples: authenticate, set_default_shop, get_default_shop have empty input objects (no parameters), but the schema definition is not self-documenting. More importantly, create_listing's listing_data parameter is a complex nested object, while the nested fields have descriptions, the parent 'listing_data' parameter itself lacks guidance on when and how to call this tool.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present, per the feature report. The MCP spec (2026-07-28) rewards tool annotations for clarifying intent and safety. Destructive tools like create_listing, delete operations (not present here but could be added) should carry annotations. This is a current pattern gap.
Credentials and tokens are managed server-side (TokenStorage, OAuth flow), which is correct. However, there is no visible audit logging or permission checks. The rubric requires tools to log who called what, with which parameters, at what time, and what happened. The code does not show this.