search_productsJPYC EC Platform 上の公開商品を横断検索する。減農薬米・地酒・伝統工芸品など、生産者から直接 JPYC で購入できる商品が対象。text は自然言語のキーワード（例: 『丹波 米』）で、商品名と説明に部分一致する。category / tag（産地・認証種別など）、価格帯（min_price / max_price、JPYC）、shop_slug で絞り込める。売上順で最大 50 件返す。
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | 商品タグ（産地・認証種別など）の完全一致 | |
| text | No | 自然言語のキーワード（商品名・説明に部分一致） | |
| limit | No | 最大件数（1-50、既定 20） | |
| category | No | 商品カテゴリーの完全一致 | |
| max_price | No | 最高価格（JPYC） | |
| min_price | No | 最低価格（JPYC） | |
| shop_slug | No | 特定ショップに絞り込む |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses sorting by sales and a maximum of 50 results, but does not mention authentication, error behavior, or pagination. This is adequate but not comprehensive.
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?
The description is a single, well-structured paragraph that starts with the primary purpose, then lists examples, then details each parameter. Every sentence adds useful information with 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?
With 7 parameters and no output schema, the description covers purpose, parameters, sorting, and limit. It does not describe the return structure, but the agent can infer from sibling tools. Additional detail on default behavior (e.g., default limit of 20) would improve completeness.
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%, so baseline is 3. The description adds value by providing examples ('text' with '丹波 米'), clarifying 'tag' as region/certification, and noting that prices are in JPYC. This goes beyond the schema descriptions.
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 identifies the tool as a cross-search across public products on the JPYC EC Platform, with examples of product types (e.g., reduced-pesticide rice, sake, crafts). It distinguishes from sibling tools like list_products_in_shop (per-shop) and get_product (single product) by specifying cross-shop scope.
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 implies usage for broad product discovery across multiple shops, with filtering options. It does not explicitly state when not to use or provide alternatives, but the sibling context and filtering parameters (e.g., shop_slug) guide appropriate use.
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.
Each tool has a clearly distinct purpose: order status, product details, shop details, listing products, listing shops, checkout quoting, searching, and payment submission. No overlap or ambiguity.
All tool names follow a consistent 'verb_noun' pattern in English, using lowercase with underscores (e.g., get_product, list_shops, submit_payment). The naming is predictable and uniform.
With 8 tools, the server is well-scoped for an e-commerce storefront. Each tool is necessary and focuses on core customer-facing operations (browse, search, checkout, payment, order status).
The tools cover the full customer journey: browsing shops and products, searching, initiating checkout with quote_checkout, submitting payment, and retrieving order status. No obvious gaps for the intended domain.