cheapest
一番安い〇〇を1回で答える。自然な日本語(例:一番安い水、トイレットペーパー安いの、お米10キロ)を q に渡すと、品目・きょうの最安(1本あたり)・買えるリンク・ふつうの値段・日付・出典を1つのJSONで返す。日用品160品目と家電52種類。毎日更新、推定なし
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | 自然な言葉。例:一番安い水 |
一番安い〇〇を1回で答える。自然な日本語(例:一番安い水、トイレットペーパー安いの、お米10キロ)を q に渡すと、品目・きょうの最安(1本あたり)・買えるリンク・ふつうの値段・日付・出典を1つのJSONで返す。日用品160品目と家電52種類。毎日更新、推定なし
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | 自然な言葉。例:一番安い水 |
Changes observed during successful MCP inspections.
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 data freshness ('毎日更新' — updated daily), reliability ('推定なし' — no estimates), and the exact return format (item, per-unit cheapest, purchase link, normal price, date, source in one JSON). This is strong behavioral disclosure for an unannotated tool; only edge cases like unmatched queries are left unspecified.
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 one dense, well-ordered paragraph: purpose front-loaded, then examples, output format, scope, and freshness/reliability. Every clause earns its place with zero filler or tautology.
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 no output schema, the description compensates by spelling out the full JSON return fields. Single parameter fully covered, scope and freshness disclosed. Minor gap: no guidance on out-of-scope or unmatched queries, but for a simple single-param tool this is not critical.
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 the schema already documents q. The description adds genuine value with three distinct query examples showing flexibility: standard form (一番安い水), inverted word order (トイレットペーパー安いの), and quantity specification (お米10キロ). It also ties the parameter to the output behavior, going beyond the schema's single example.
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 states a specific verb and resource ('一番安い〇〇を1回で答える' — answers the cheapest item in one go) with concrete query examples (一番安い水, トイレットペーパー安いの, お米10キロ). It defines clear scope (160 daily necessities + 52 home appliance types) which distinguishes it from sibling item tools like hikaku, super_item, and oroshi_item.
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 examples and the phrase '1回で答える' (answer in one go) imply this is for direct single queries, and the scope statement (160 daily necessities, 52 home appliances) defines coverage. However, with numerous similar siblings (hikaku, cost_item, super_item, suii_item, lens_item), there is no explicit when-to-use vs. alternative guidance or exclusions.
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.