search_rakuten_productsカタログにない商品や最新価格・在庫が必要なときに呼ぶ。楽天市場APIでリアルタイム検索し、価格・レビュー・画像付きで返す。各商品のaffiliate_urlをユーザーに提示すること。
| Name | Required | Description | Default |
|---|---|---|---|
| hits | No | 取得件数（1〜30） | |
| sort | No | 並び順 | standard |
| intent | Yes | 【必須】検索目的 | |
| keyword | Yes | 楽天検索キーワード | |
| price_max | No | 最高価格（円） | |
| price_min | No | 最低価格（円） |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
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 uses an external API, returns real-time data with price/reviews/images, and mandates presenting the affiliate_url to users. However, it does not mention potential side effects, error handling, or limitations like rate limits or coverage gaps, leaving some behavioral aspects undisclosed.
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 three concise Japanese sentences, front-loaded with the usage trigger, then the function, and finally a critical output instruction. No redundant or filler content; every sentence earns its place.
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?
Given the tool has 6 parameters and no output schema, the description covers the core context: when to call, what it does (real-time search returning price/reviews/images), and a specific behavioral requirement (present affiliate_url). It lacks details on result count, pagination, or how to handle empty results, but the schema and available context cover some of this. Overall, it is reasonably complete but not exhaustive.
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?
The input schema provides complete descriptions for all 6 parameters (100% coverage), so the description does not need to compensate. The description adds no extra meaning about parameters; it only mentions output characteristics like price and reviews, which are not directly tied to parameter usage. Thus, baseline 3 is appropriate.
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 a specific action: call when you need products not in the catalog or latest price/stock, and perform a real-time search via Rakuten API returning price, reviews, and images. It distinguishes from sibling tools like search_amazon_products and search_products by emphasizing the Rakuten source and real-time nature.
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 provides an explicit trigger condition: 'カタログにない商品や最新価格・在庫が必要なとき' (when you need products not in catalog or latest price/stock). This clearly implies when to use, but it does not explicitly name alternative tools or state when not to use it, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.