identify_product「この写真の棚は何？」「持ってる棚に合うボックスを知りたい」のときに呼ぶ。Vision AIで画像から抽出した特徴テキスト(ブランド/色/段数/素材/推定サイズ)を渡すと、カタログ＋楽天から候補を返す。型番特定時は内寸・消耗品・互換ボックス情報付き。
| Name | Required | Description | Default |
|---|---|---|---|
| intent | Yes | 【必須】なぜ特定したいか | |
| features | Yes | 画像から読み取った特徴テキスト（ブランド、色、段数、素材、推定サイズ、形状特徴等） | |
| brand_hint | No | ブランド名ヒント（ロゴが見えた場合） | |
| dimensions_hint | No | 推定寸法（mm）分かる範囲で | |
| include_compatible | No | 互換収納・消耗品情報も含めるか（デフォルト: true） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool expects pre-extracted feature text (not raw images), searches catalog + Rakuten, and returns candidates conditionally (with extra info when model number is identified). However, it does not mention any limitations, error handling, or side effects, and since it's a quest-like operation, the lack of explicit read-only confirmation is a minor gap.
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 highly concise, consisting of two sentences that pack in the trigger scenarios, input format, data sources, and output characteristics. It is front-loaded with usage examples and avoids unnecessary fluff, making it easy to scan and understand quickly.
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?
The tool has no output schema, so the description must explain return values. It does mention that candidates are returned and that internal dimensions, consumables, and compatible box info are included when model number is identified. However, it lacks details on the structure of the response or how to interpret multiple candidates, which is a minor gap given the tool's complexity.
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 description coverage is 100%, so the baseline is 3. The description adds context that the 'features' parameter should contain brand/color/number of shelves/material/estimated size, aligning with the schema. It does not provide additional syntax or format details beyond what the schema already documents, but it reinforces the intended usage of the parameters.
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 states the tool's purpose: identifying a product from photo-derived feature text, with specific example queries ('この写真の棚は何？'). It specifies the resource (products from catalog + Rakuten) and distinguishes itself from generic search tools by focusing on image-based identification. The addition of model number, internal dimensions, and consumables info further clarifies its specialized role.
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 explicitly says when to call it ('「この写真の棚は何？」「持ってる棚に合うボックスを知りたい」のときに呼ぶ'), providing clear use cases. It does not explicitly mention alternatives or when not to use it, but the context is specific enough that an agent can infer differentiation from sibling search tools.
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.
Multiple tools handle product discovery (search_products, search_rakuten_products, search_amazon_products, suggest_by_space, find_replacement), and their boundaries require careful description reading. diagnose_ai_visibility is completely unrelated to furniture, adding confusion. Most tools are distinct, but the search cluster is ambiguous.
Tool names consistently use snake_case with verb prefixes (get_, search_, find_, list_, etc.). While some verbs overlap (search vs find), the pattern is predictable and no mixed styles exist.
18 tools is on the higher side but reasonable for a rich domain. However, several search variants and the unrelated diagnose_ai_visibility tool could be consolidated, making it slightly bloated.
The furniture hub covers the full user journey: search, detail, compare, related, photo measurement, space planning, storage, replacements, and even demand analysis. Missing features like direct purchase are handled via affiliate links. The unrelated AI visibility tool doesn't create a gap in furniture functionality.