Skip to main content
Glama
deenesjakoruzh
alveyautomation

etsy-mcp

by alveyautomation
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

etsy-mcp

第一个用于 Etsy 的生产级模型上下文协议 (MCP) 服务器。在五分钟内将 Claude 连接到您的 Etsy 店铺商品、库存、订单和统计信息 —— 仅限读取。

License: MIT Python 3.10+ MCP

为什么会有这个项目

Etsy 的 Open API v3 文档齐全且稳定，但每个想要在店铺之上使用 LLM 的卖家最终都要从零开始编写相同的 OAuth 和分页逻辑。现有的 MCP 集成大多是简单的演示，缺少令牌刷新、重试逻辑以及 Etsy 实际要求的按店铺分页功能。

如果您在 Etsy 上销售，并且希望 Claude（或任何支持 MCP 的 AI 助手）能够直接了解您店铺的情况 —— 比如有哪些商品、昨天发了什么货、哪些库存不足 —— 那么这个差距就是“开箱即用地总结今日订单”与“需要自定义集成才能总结今日订单”之间的区别。

etsy-mcp 填补了这一空白。它是一个轻量级、经过充分测试且采用 MIT 许可的 MCP 服务器，向任何 MCP 客户端公开了八个只读的 Etsy 端点。它基于多年大规模运行电子商务自动化的经验构建。

Related MCP server: @mcpengine/etsy

您可以用它做什么

将此服务器连接到 Claude Code、Claude Desktop 或任何 MCP 主机，然后询问如下问题：

  • “在我的店铺中搜索标题中带有 vintage 字样的商品，并告诉我哪些库存少于 5 件。”

  • “我昨天收到了多少订单？按买家和总收入分组。”

  • “拉取收据 5550001，告诉我哪些交易已发货，还有哪些尚未发货。”

  • “过去 30 天我的店铺统计数据如何？比较订单、收藏者和在售商品数量。”

  • “对于商品 1234567890，向我展示每一个变体、其 SKU 和当前数量。”

Claude 直接读取您的店铺。无需复制粘贴，无需电子表格，无需自定义流水线。

工具 (v0.1，均为只读)

工具

功能

etsy_search_listings

在在售商品中进行关键词搜索，可选择店铺范围。

etsy_get_listing

通过 ID 获取单个商品。

etsy_get_shop

获取店铺记录（名称、货币、计数、休假状态等）。

etsy_search_orders

列出指定日期窗口内一个店铺的收据（订单）。

etsy_get_order

通过 ID 获取单个收据，包括行项目交易。

etsy_get_inventory

获取商品的变体级库存（SKU、数量、价格）。

etsy_get_shop_stats

组合周期汇总：订单、收藏者、收入、商品。

etsy_get_active_listings

店铺中所有在售商品的分页列表。

写入端点（创建草稿商品、更新库存、标记收据已发货）在 v0.1 中特意未包含。一旦只读功能稳定，计划在 v0.2 中加入。

安装

pip install etsy-mcp

v0.1 从此仓库发布。PyPI 发布正在进行中 —— 目前，请使用 pip install git+https://github.com/alveyautomation/etsy-mcp 安装，或克隆并在本地运行 pip install -e .。

配置凭据

服务器从环境变量中读取所有内容。将 .env.example 复制到 .env 并填写您的租户信息：

ETSY_API_URL=https://api.etsy.com/v3/application/   # default; usually leave alone
ETSY_API_KEY=your-keystring-from-etsy-developers
ETSY_REFRESH_TOKEN=oauth2-refresh-token-for-your-shop
ETSY_DEFAULT_SHOP_ID=                               # optional fallback
ETSY_HTTP_TIMEOUT=60                                # optional, seconds
ETSY_MAX_RETRIES=3                                  # optional

获取 Etsy API 密钥

  1. 访问 https://www.etsy.com/developers/your-apps 并注册一个应用。

  2. 复制 Keystring —— 这就是 ETSY_API_KEY。

  3. 为您的一次性 OAuth 引导配置重定向 URI（例如 http://localhost:3000/callback）。

获取刷新令牌

Etsy 使用 带有 PKCE 的 OAuth 2.0。要进行引导，请使用以下参数运行一次标准的 OAuth-PKCE 流程：

  • response_type=code

  • client_id=<您的 keystring>

  • redirect_uri=<您注册的 URI>

  • scope=listings_r shops_r transactions_r（只读 —— 这是此服务器所需的最低权限）

  • state=<随机字符串>

  • code_challenge=<PKCE> 和 code_challenge_method=S256

将生成的授权码在 POST https://api.etsy.com/v3/public/oauth/token 处交换以获取访问令牌 + 刷新令牌。将 刷新令牌 保存为 ETSY_REFRESH_TOKEN。服务器将自动使用它来生成短期的访问令牌。

使用最小权限的只读令牌。 v0.1 仅调用 GET 端点，但纵深防御意味着您永远不应授予服务器刷新令牌写入权限 (*_w)。当 v0.2 推出写入工具时，通过生成一个新的更高权限令牌来选择加入 —— 永远不要反过来操作。

连接到 Claude Code

添加到 ~/.claude/claude_code_config.json（或您项目的 MCP 配置）：

{
  "mcpServers": {
    "etsy": {
      "command": "etsy-mcp",
      "env": {
        "ETSY_API_KEY": "your-keystring",
        "ETSY_REFRESH_TOKEN": "your-refresh-token",
        "ETSY_DEFAULT_SHOP_ID": "12345678"
      }
    }
  }
}

重启 Claude Code。八个 etsy_* 工具将出现在任何新会话中。

连接到 Claude Desktop

编辑 ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) 或 %APPDATA%\Claude\claude_desktop_config.json (Windows)，并添加与上述相同的 mcpServers 块。重启桌面应用。

工具参考

每个工具都返回一个 JSON 信封：

{ "ok": true,  "data": { ... } }
{ "ok": false, "error": "human-readable message" }

etsy_search_listings

etsy_search_listings(
    query: str,                          # required
    shop_id: int | None = None,          # scope to a single shop
    limit: int = 50,                     # max 100 (Etsy server cap)
)

当提供 shop_id 时，它会访问 /shops/{shop_id}/listings/active。否则，它会访问全局 /listings/active 索引。

etsy_get_listing

etsy_get_listing(listing_id: int)

返回商品记录，如果 404 则返回 data: null。

etsy_get_shop

etsy_get_shop(shop_id: int)

店铺记录包括 shop_name、currency_code、listing_active_count、num_favorers、is_vacation 等。

etsy_search_orders

etsy_search_orders(
    date_from: str,                      # ISO date "YYYY-MM-DD"
    date_to: str,                        # ISO date "YYYY-MM-DD"
    shop_id: int | None = None,          # falls back to default
    status: str | None = None,           # 'open' | 'unshipped' | 'completed' | 'all'
    limit: int = 200,                    # max 1000
)

Etsy 将页面大小限制为 100；分页是透明的。当 limit 是截断点时，响应包含 limit_reached: true。

etsy_get_order

etsy_get_order(receipt_id: int, shop_id: int | None = None)

返回完整收据（包含 transactions[]），如果 404 则返回 data: null。

etsy_get_inventory

etsy_get_inventory(listing_id: int)

返回包含 sku、property_values 和 offerings[]（数量、价格、启用状态）的 products[]。使用 offering 数量作为每个变体的规范“可售数量”。

etsy_get_shop_stats

etsy_get_shop_stats(shop_id: int, period: str = "30d")

一个组合汇总。Etsy 在 v3 中没有公开一流的 shop/stats 端点，因此这是从店铺记录（收藏者、在售商品数量）和窗口内的收据中合成的。返回形状：

{
  "shop_id": 12345678,
  "period": "30d",
  "period_days": 30,
  "date_from": "2026-03-27",
  "date_to": "2026-04-26",
  "favorers": 314,
  "active_listings": 87,
  "orders": 42,
  "revenue_minor_units": 152400,
  "currency_code": "USD"
}

period 接受 <N>d 格式，最多 365 天。

etsy_get_active_listings

etsy_get_active_listings(shop_id: int, limit: int = 200)

店铺中所有在售商品的分页转储。对于全目录推理（“审计我的标题中缺失的关键词”）很有用。软上限为 1000，以保持单次工具调用的边界。

本地开发

git clone https://github.com/alveyautomation/etsy-mcp
cd etsy-mcp
python -m venv .venv && source .venv/bin/activate    # Windows: .venv\Scripts\activate
pip install -e ".[dev]"
pytest                                                # 49 tests, ~3s

预提交钩子（gitleaks, trufflehog, ruff, formatter, 租户指纹清理器）：

pip install pre-commit
pre-commit install

针对真实 Etsy 沙盒的集成测试受 ETSY_INTEGRATION_TESTS=1 控制。正常贡献不需要它们。

故障排除

Failed to refresh Etsy access token —— 您的刷新令牌已过期或被撤销。Etsy 刷新令牌自签发之日起 90 天内有效，但前提是必须定期使用。重新运行 OAuth-PKCE 引导以生成新的令牌。

Missing required environment variables —— 服务器在加载 .env 之前尝试启动。请在父 shell 中导出变量，或确保您的 MCP 主机配置在 env 块中包含了它们。

HTTP 403 on receipts/transactions —— 刷新令牌的范围缺少 transactions_r。使用上述列出的只读范围重新引导。

Empty results despite known data —— 确认 shop_id。Etsy 的 /shops/{shop_id}/... 端点仅返回 OAuth 令牌已授权的店铺的数据。

Pagination feels slow —— Etsy 将每个请求的页面大小限制为 100，而不是我们。对于较大的日期窗口（长订单历史记录），预计会有多次往返。降低 limit 参数以限制调用。

贡献

欢迎提交问题和拉取请求。请：

  • 在打开 PR 之前运行 pytest (pip install -e ".[dev]")。

  • 运行 pre-commit run --all-files。

  • 将 v0.1 的新增内容保持在只读范围内。写入端点将在 v0.2 中加入。

  • 测试中仅使用合成数据 —— 不要使用真实的店铺名称、商品 ID 或收据编号。

许可证

MIT —— 参见 LICENSE。

免责声明

etsy-mcp 是一个非官方的第三方集成。它未得到 Etsy, Inc. 的认可、关联或支持。“Etsy”是 Etsy, Inc. 的商标。使用风险自负；在依赖它进行生产决策之前，请先针对您的店铺验证其行为。

Available Tools

8 tools
etsy_get_active_listingsA

List active listings for a shop, paginating transparently.

Args: shop_id: Etsy ShopID. limit: Soft cap on yielded listings (default 200, max 1000).

Returns: JSON envelope. data.listings is the list of active-listing records.

ParametersJSON Schema
NameRequiredDescriptionDefault
shop_idYes
limitNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

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

Since no annotations are provided, the description carries full burden. It notes pagination behavior and a soft cap on limit, but does not clarify that the operation is read-only or mention any other behavioral traits, which is insufficient for a tool with no annotations.

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?

Very concise, using a clear docstring format with Args and Returns. Every sentence adds value; no wasted words.

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

Completeness4/5

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

Given 2 parameters and an output schema (not shown but present), the description adequately covers the tool's functionality. It explains return structure ('JSON envelope, data.listings'), which is sufficient with the output schema present.

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

Parameters4/5

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

Schema description coverage is 0%, so the description adds meaning beyond the schema. It defines shop_id as 'Etsy ShopID' (repetitive but confirms type) and explains limit as a 'soft cap' with default 200 and max 1000, providing valuable context not in the schema.

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?

Clearly states 'List active listings for a shop, paginating transparently' which specifies the action (list), resource (active listings), and scope (for a shop, with automatic pagination). Distinguishes from siblings like etsy_get_listing (single) and etsy_search_listings (search across shops).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implicitly describes usage for listing active listings of a shop, but provides no explicit guidance on when to use this tool versus alternatives, nor any conditions or exclusions among the 7 sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

etsy_get_inventoryA

Fetch the current inventory record (variations + offerings) for a listing.

Args: listing_id: Etsy ListingID.

Returns: JSON envelope. data is the inventory record (with products[] carrying property values, SKU, price, and offerings[] with quantity), or null if absent.

ParametersJSON Schema
NameRequiredDescriptionDefault
listing_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

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

No annotations are provided, so the description must disclose behavioral traits. It mentions the return structure (JSON envelope, products, offerings) and that data can be null, but does not specify whether the operation is read-only, authentication needs, or rate limits. Adequate but not thorough.

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 extremely concise, with a clear header sentence and structured Args/Returns sections. No redundancy or unnecessary information.

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

Completeness4/5

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

Given the tool's simplicity (one parameter, output schema exists), the description covers purpose, parameter, and return value. It lacks usage guidelines, but for a straightforward fetch operation, it is largely complete.

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

Parameters4/5

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

The single parameter listing_id is described as 'Etsy ListingID', adding meaning beyond the schema title 'Listing Id'. The description explains its purpose clearly, compensating for the 0% schema description coverage.

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 action ('Fetch') and resource ('inventory record'), specifying it includes variations and offerings for a listing. It distinguishes from siblings like etsy_get_listing (listing details) and etsy_get_active_listings (list of listings).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains what the tool returns but does not explicitly state when to use it versus alternatives. No guidance on when not to use or prerequisites is provided, though the purpose is clear enough for an agent to infer usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

etsy_get_listingA

Fetch the full record for a single listing.

Args: listing_id: Etsy ListingID (integer).

Returns: JSON envelope. data is the listing record, or null if not found.

ParametersJSON Schema
NameRequiredDescriptionDefault
listing_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description carries full burden. It states it 'fetches' (read-only) and returns null if not found, which is helpful. However, it does not disclose any potential side effects, permissions, rate limits, or other behavioral traits.

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 extremely concise with no wasted words. It front-loads the purpose, then clearly lists args and returns. Every sentence serves a purpose.

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

Completeness4/5

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

Given the tool's simplicity (one parameter, no annotations, output schema exists), the description adequately covers the essentials. It mentions what the tool does, the argument needed, and the return format including the null case. Could mention error handling beyond null, but not necessary for basic completeness.

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

Parameters4/5

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

The description adds meaning beyond the schema by specifying 'Etsy ListingID (integer)' for the listing_id parameter. This clarifies the parameter's type and scope, which is valuable given the schema only provides 'Listing Id' and type integer.

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 'Fetch the full record for a single listing,' which is a specific verb+resource. It distinguishes from sibling tools like etsy_search_listings (which searches multiple) and etsy_get_active_listings (which gets multiple active listings).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide any guidance on when to use this tool versus alternatives. It lacks explicit when-to-use or when-not-to-use information, leaving the agent to infer from context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

etsy_get_orderB

Fetch full receipt (order) detail including transactions.

Args: receipt_id: Etsy ReceiptID (integer). shop_id: Etsy ShopID. Falls back to ETSY_DEFAULT_SHOP_ID if omitted.

Returns: JSON envelope. data is the receipt record, or null if missing.

ParametersJSON Schema
NameRequiredDescriptionDefault
receipt_idYes
shop_idNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.4/5.0
Behavior3/5

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

No annotations provided, so description carries the burden. It discloses the behavior (fetch receipt with transactions), fallback for shop_id, and return format. However, it omits information on authentication or rate limits.

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

Conciseness4/5

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

Description is short and structured with Args and Returns sections. No unnecessary words, but the overall structure is clear and efficient.

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

Completeness3/5

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

Given no annotations and an output schema (stated but not shown), description covers basics: purpose, parameters, return format. However, it lacks guidance on when to use this tool vs. search_orders, which is a gap.

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 0%, so description must add meaning. It explains receipt_id is an integer and shop_id is an integer with a fallback to default. This adds value, but could provide more detail on source of IDs.

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?

Description states 'Fetch full receipt (order) detail including transactions' with a clear verb and resource. It specifies that it includes transactions, distinguishing it from sibling tools like etsy_get_listing and etsy_search_orders.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like etsy_search_orders. The description only mentions fallback behavior for shop_id but does not provide context for tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

etsy_get_shopA

Fetch the shop record for a single shop.

Args: shop_id: Etsy ShopID (integer).

Returns: JSON envelope. data is the shop record (with name, currency_code, listing_active_count, num_favorers, etc.), or null if not found.

ParametersJSON Schema
NameRequiredDescriptionDefault
shop_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior4/5

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

No annotations provided, so description carries burden. It discloses return format (JSON envelope with data field), example fields (name, currency_code, etc.), and null behavior on not found. Lacks error or auth info, but sufficient for a simple read operation.

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?

Three sentences with args/returns section. Every sentence adds value: purpose, parameter, return details. No fluff.

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 simple tool (one param, no nested objects, output schema exists), description covers purpose, parameter, return structure and field examples. Sufficient for an agent to understand usage and outcome.

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

Parameters4/5

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

Only one parameter (shop_id) with 0% schema description coverage. Description adds 'Etsy ShopID (integer)' context, clarifying it's the shop identifier. Compensates for missing schema 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 states 'Fetch the shop record for a single shop,' which is a specific verb-resource pair. It clearly distinguishes from sibling tools like etsy_get_shop_stats (stats) or etsy_get_listing (listing entity).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus siblings. Does not mention alternatives or conditions like 'use this instead of etsy_get_shop_stats when only basic shop info is needed.'

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

etsy_get_shop_statsA

Return aggregated stats (orders, favorers, active listings, revenue) for a shop over the given period.

Args: shop_id: Etsy ShopID. period: Lookback window in the form 'd', e.g. '7d', '30d', '90d'. Maximum 365 days.

Returns: JSON envelope. data is a dict with orders, favorers, active_listings, revenue_minor_units, currency_code, and the resolved date_from / date_to.

ParametersJSON Schema
NameRequiredDescriptionDefault
shop_idYes
periodNo30d

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior2/5

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

With no annotations provided, the description bears full burden for behavioral disclosure. It describes the return format but omits any mention of side effects, error conditions, authorization requirements, or rate limits, limiting transparency.

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 concise with a clear structure using Args and Returns sections; every sentence adds value without redundancy.

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

Completeness4/5

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

Given two parameters and an output schema, the description adequately explains both parameters and the return structure, but lacks details on error conditions or authentication requirements.

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

Parameters5/5

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

The description adds substantial meaning beyond the input schema, explaining shop_id as 'Etsy ShopID' and period as a lookback window with format '<N>d' and maximum 365 days, compensating for 0% schema coverage.

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 verb 'Return' and the resource 'aggregated stats (orders, favorers, active listings, revenue) for a shop over a given period', and it is distinct from sibling tools that handle listings, inventory, orders, or searches.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites, leaving the agent to infer usage solely from the purpose.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

etsy_search_listingsA

Search active Etsy listings by keyword.

Args: query: Free-text keyword search across listing title and tags. shop_id: Optional Etsy ShopID to scope the search to a single shop. When omitted, queries the global active-listings index. limit: Cap on returned results (max 100 enforced by Etsy).

Returns: JSON envelope: {"ok": true, "data": {"results": [...], "count": N}}.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes
shop_idNo
limitNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

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

No annotations are provided, so the description must carry the burden. It discloses the return format (JSON envelope with ok, data, results, count) and an enforced limit of 100, but lacks details on authentication, rate limits, or any read-only guarantee.

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 concise and well-structured with Args and Returns sections. Every sentence adds value with no redundancy or fluff.

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

Completeness4/5

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

For a simple 3-parameter search tool with an output schema, the description covers purpose, parameters, and return format adequately. It lacks explicit comparison to siblings, but is otherwise complete.

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

Parameters5/5

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

Schema description coverage is 0%, but the description fully explains all three parameters: query as free-text, shop_id as optional scoping, and limit with a cap. This adds meaningful detail beyond the schema names.

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 'Search active Etsy listings by keyword' with a specific verb and resource. It distinguishes from siblings like 'etsy_get_listings' by focusing on keyword search and optional shop_id scoping.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides context that omitting shop_id queries the global index, but does not explicitly compare to sibling tools like 'etsy_get_active_listings' or give when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

etsy_search_ordersA

Search receipts (orders) created in the inclusive [date_from, date_to] window for a shop.

Args: date_from: ISO date (YYYY-MM-DD), start of window. date_to: ISO date (YYYY-MM-DD), end of window. shop_id: Etsy ShopID to scope the search to. Falls back to ETSY_DEFAULT_SHOP_ID if omitted. status: Optional receipt status filter ('open', 'unshipped', 'unpaid', 'completed', 'processing', 'all'). limit: Cap on yielded receipts (default 200, max 1000). Etsy caps page size at 100 per request; pagination is handled transparently.

Returns: JSON envelope. data.orders is the list of receipt records.

ParametersJSON Schema
NameRequiredDescriptionDefault
date_fromYes
date_toYes
shop_idNo
statusNo
limitNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

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

Without annotations, the description carries full burden. It discloses transparent pagination handling, limit cap (1000, with 100 per page), default shop_id fallback, and return format. It does not mention read-only nature or rate limits, but for a search tool the disclosed behaviors are substantial.

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 well-structured with a summary sentence followed by bullet-pointed parameter details. Every sentence adds value, no redundancy. It is concise yet comprehensive, fitting all necessary information into a compact format.

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 (not shown but indicated), the description adequately covers return structure ('JSON envelope with data.orders'). All parameters, default behaviors, and pagination are explained. No critical gaps remain for a search tool with moderate complexity.

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

Parameters5/5

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

The description adds extensive meaning beyond the input schema: date format (ISO), inclusive window semantics, shop_id fallback to ETSY_DEFAULT_SHOP_ID, status enum values, limit with transparent pagination. Schema coverage is 0%, so description fully compensates, making each parameter's purpose and constraints clear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it searches receipts/orders by date window for a shop. 'Search receipts (orders) created in the inclusive [date_from, date_to] window for a shop.' is a specific verb+resource+scope. However, it does not differentiate from sibling tools like etsy_get_order or etsy_search_listings, leaving ambiguity about when to use this versus alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for searching orders within a date range, with optional filters. Yet it provides no explicit guidance on when not to use it or references to sibling tools for alternative use cases. The context of searching by shop and date window is clear but lacks exclusionary criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 8 tool updatesv0.1.0
    • First observedetsy_get_active_listings
    • First observedetsy_get_inventory
    • First observedetsy_get_listing
    • First observedetsy_get_order
    • First observedetsy_get_shop
    • First observedetsy_get_shop_stats
    • First observedetsy_search_listings
    • First observedetsy_search_orders
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.8/5.0

Scored across 8 tools

Disambiguation5/5

Each tool targets a distinct resource (listings, inventory, shop, orders) and operation (get, search, stats), with no overlapping purposes.

Naming Consistency5/5

All tools follow the consistent pattern 'etsy_<verb>_<noun>', using snake_case and clear verbs (get, search) throughout.

Tool Count4/5

8 tools is reasonable for an Etsy API wrapper, covering key read operations without being excessive.

Completeness2/5

The server provides only read/search operations; missing critical mutation tools like create/update/delete listing or update order, leaving significant gaps for full lifecycle management.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • etsy-mcp-server

    DColl
    A
    license
    A
    quality
    D
    maintenance
    A full-featured MCP server for the Etsy Open API v3 that enables managing an Etsy shop, including listings, inventory, images, digital files, and orders, through Claude or any MCP-compatible client.
    26
    1
    MIT

  • MCP Tool Agent

    chigurupatiakhil5
    F
    license
    Not graded
    quality
    B
    maintenance
    A custom MCP server exposing database, ticketing, and external-API tools to both Claude Desktop and a self-built autonomous agent powered by Groq's free-tier LLaMA 3.3.
    -