台灣購物網站 3C、美妝、家電商品目前售價（新台幣）與歷史價格查詢。
Scored across 4 tools
Each tool targets a distinct action and resource: searching products, fetching detailed price history for one product, listing categories, and listing price drops. Boundaries are clear with no overlapping purposes.
All tool names follow a consistent snake_case verb_noun pattern: get_product_price, list_categories, list_price_drops, search_products. The convention is predictable across the set.
Four tools are well-scoped for a price comparison lookup server. Each tool has a clear role and there is no redundant or filler operation.
The core workflows for finding products, checking individual price details, browsing categories, and spotting price drops are covered. A minor gap is the lack of browsing products within a category, but agents can work around this via search.
取得單一商品的目前最低價、各商店報價，以及近 90 天最低、最高、平均價。
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | 商品 id，例如 pchome:DYAJCH-1900JLHPE |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure, and it does describe the returned metrics (current low, per-store quotes, 90-day stats) — useful since there is no output schema. However, it says nothing about auth requirements, rate limits, caching, or whether prices are live, leaving meaningful behavioral gaps.
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?
A single tightly-packed sentence that front-loads the core result (current lowest price) before the secondary metrics. No wasted words.
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?
For a one-parameter, annotation-free read tool with no output schema, the description adequately conveys what the agent will receive (current minimum, per-store quotes, 90-day stats). Only the omission of usage routing and behavioral caveats keeps it from being fully complete.
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% and the only parameter 'id' is documented with an example (pchome:DYAJCH-1900JLHPE) in the schema itself. The description adds no further meaning about the id format or provider prefix, so the baseline 3 applies.
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+resource (取得單一商品...價格) and enumerates exactly what is returned: current lowest price, per-store quotes, and 90-day min/max/average. The word '單一' (single) implicitly distinguishes it from the list/search siblings, but it does not name an alternative, so it stops short of full sibling differentiation.
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?
Usage is only implied: the required 'id' makes clear you need a known product id, but the description never says when to choose this over search_products or list_price_drops, nor how to obtain the id. There are no explicit when-to-use or exclusion statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出收錄的商品分類。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and says nothing beyond the bare operation. It doesn't state that this is a read-only operation, whether results are paginated, how many categories are typical, or in what order they come.
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?
A single short sentence with no filler, appropriately sized for a zero-parameter list tool. It is terse rather than padded.
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?
For a simple no-arg list tool this is close to sufficient, but with no output schema and no annotations, the description could have said what the categories look like or whether they map to category IDs used elsewhere.
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 tool takes zero parameters, so the baseline is 4. There are no inputs whose semantics the description needs to clarify.
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?
States a specific verb+resource (列出商品分類), which is unambiguous on its own. It does not explicitly distinguish itself from siblings like search_products, but the resource is narrow enough that overlap is unlikely.
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?
No indication of when to use this versus search_products or the other siblings, and no prerequisites or context. Usage is only implied by the verb 'list'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出今天降價 3% 以上或創 30 天新低的商品。
| Name | Required | Description | Default |
|---|---|---|---|
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the exact selection thresholds (3% drop, 30-day low), which is real behavioral context, but says nothing about ordering, result limits, pagination, or return shape for a list tool.
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?
A single front-loaded sentence with the criteria stated up front and zero filler. Nothing to trim.
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?
For a simple, low-complexity list tool with no output schema, the core behavior is conveyed adequately. The gap is the undocumented 'category' parameter and the absence of any mention of result formatting or limits.
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?
There is one 'category' parameter with an enum but 0% schema description coverage, and the description never mentions category at all. The description explains the filtering thresholds but leaves the sole parameter's meaning entirely to the enum values.
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+resource ('列出...商品') and sharpens it with concrete selection criteria (≥3% drop today or 30-day low), so an agent knows exactly what this returns. It does not, however, distinguish itself from siblings like search_products or get_product_price, leaving that differentiation implicit.
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 'today / 3% / 30-day low' framing implies the scenario in which this tool is relevant, but there is no explicit when-to-use, when-not-to-use, or reference to an alternative sibling. Usage is inferable but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜尋台灣購物網站商品（3C、美妝保養、家電）目前售價（新台幣），回傳商品、商店、價格與確認時間。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 關鍵字，例如 AirPods Pro | |
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses return contents including 確認時間 (confirmation/verification time), implying price freshness, but says nothing about permissions, result limits, rate limits, or whether prices are cached vs live.
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?
A single, front-loaded sentence that packs purpose, scope, currency, and return fields with no wasted words. It is appropriately sized for a two-parameter search tool.
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 correctly describes the return fields, which is valuable. But it omits any treatment of the category parameter and provides no differentiation from sibling price tools, leaving meaningful gaps for a search tool in a crowded namespace.
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 50%: the query parameter is documented in the schema, but category is only an enum with no explanatory text. The description obliquely references category groupings (3C、美妝保養、家電) but does not explain how they map to the enum values. Baseline 3 is appropriate given partial coverage.
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?
Names a specific verb (搜尋/search) and resource (台灣購物網站商品) with concrete scope: categories covered (3C、美妝保養、家電) and currency (新台幣). However, it does not differentiate itself from the sibling get_product_price, which also returns pricing, so an agent cannot tell them apart from the description alone.
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 states what the tool does but gives no when-to-use guidance, no exclusions, and no routing to alternatives such as get_product_price or list_price_drops. The agent must infer that keyword search is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_product_pricelist_categorieslist_price_dropssearch_products台灣電商情報與商品比價：跨通路查 momo、PChome、品牌官網即時價格與歷史最低價、偵測網站電商技術、搜尋電商知識庫。資料來源 ecpro.tw。
Price comparison across partner retailers. Read-only, 90-day history, disclosed affiliate.
Search 86 US retailers — 260M+ products with real-time pricing, stock, and price history.
Add one secure layer between your agents and this server.
