購物比價紀錄：3C、美妝、家電價格比較。台灣繁體中文 MCP 工具。
Scored across 7 tools
Several tools retrieve prices for a keyword or product: compare_chain_prices, search_products, and get_product_price all overlap, and list_lowest_prices vs list_price_drops both surface low/declining prices. Descriptions do help distinguish chain-store comparison from web-site search and single-product detail, but an agent could still misselect.
Every tool follows a consistent snake_case verb_noun pattern (compare_*, get_*, list_*, search_*). The verb prefixes accurately reflect read/query semantics throughout.
Seven tools is well-scoped for a read-only price-comparison domain. Each tool maps to a distinct query mode (search, compare, detail, categories, promos, lowest, drops) without bloat.
The read-only surface is broadly complete: search, cross-store comparison, per-product detail with 90-day stats, categories, promos, lowest-price aggregation, and drop alerts. A price-history-over-time tool or per-store listing could round it out, but core workflows are covered.
同一商品在各連鎖通路的售價比較（輸入商品關鍵字，例如：舒酸定）。
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | 商品關鍵字 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden, yet it says nothing about read-only nature, permissions, rate limits, or result shape. 'Comparison' hints at a multi-chain result but the agent cannot infer whether output covers all chains or is ranked.
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 compact sentence with the core verb+resource front-loaded and the input guidance trailing. Efficient, though the example occupies space without adding much beyond what the schema already implies.
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-param read tool with no output schema and no annotations, the description covers the input side adequately but omits what the comparison returns (per-chain list? lowest price? sorted?). Given the dense sibling set of price-related tools, that gap matters.
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% (single param q = 商品關鍵字), so the baseline is 3. The description echoes that semantics and adds a concrete example ('舒酸定'), but contributes no format or matching-behavior detail beyond the schema.
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 (compare) and resource (same product's price across chain stores), which is distinguishable from siblings like get_product_price and list_lowest_prices. However, it never names or contrasts those siblings, so differentiation is inferential rather than explicit.
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 parenthetical implies the input is a product keyword and gives a concrete example (舒酸定), which signals usage. But there is no statement of when to prefer this over get_product_price or list_lowest_prices, and no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
取得單一商品的目前最低價、各商店報價，以及近 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.
台灣熱門連鎖通路（寶雅、康是美、屈臣氏、全聯、家樂福、Costco 等）目前公開的優惠活動整理，每筆附資料來源；以官方公告為準。
| Name | Required | Description | Default |
|---|---|---|---|
| chain | 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 data provenance ('each entry includes a source') and a timeliness caveat (official announcements prevail), which is real behavioral context, but it omits scope, freshness window, result count, and return-shape details for what is clearly a read-only listing.
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?
One dense sentence that front-loads the resource, then supplies examples and the official-announcement caveat. No filler, though the chained parenthetical and clause stacking make it slightly run-on.
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 no-annotation, no-output-schema listing tool with one optional parameter, the description covers what the data is and where it comes from, which is the essential minimum. It still leaves the agent guessing about how many entries return, ordering, and pagination behavior that an apparently simple list tool may exhibit.
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% for the single optional 'chain' filter, so the baseline is 3. The description's list of channel names (寶雅, 康是美, 屈臣氏, 全聯, 家樂福, Costco) loosely hints at valid filter values, but it is framed as examples ending in '等' rather than an authoritative set, adding only marginal value over the schema.
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 names a specific resource (currently public promotional offers from major Taiwanese chain stores) and enumerates representative retailers, so an agent can distinguish it from price-oriented siblings like get_product_price and list_lowest_prices. The verb is only implied by the tool name rather than stated, and no sibling is named, so it stops short of a 5.
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?
There is no explicit when-to-use or when-not-to-use guidance, and no alternative such as compare_chain_prices or search_products is mentioned. The only directional clause, '以官方公告為準' (subject to official announcements), is a data-reliability caveat rather than usage instructions.
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?
No annotations are provided, so the description carries the behavioral burden. It discloses the computation basis (daily records) and that results cover a record period, which is useful context, but it does not state return format, pagination, or any limits. Baseline adequacy with notable 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 compact sentence that front-loads the computation basis and enumerates the three outputs. No filler, though the lack of any usage sentence limits its practical utility.
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 parameterless read tool with no output schema, the description explains what is computed but omits scope boundaries (which period, which products) and result format, which the agent needs to invoke it confidently.
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 there is nothing for the description to document and no risk of missing parameter semantics. Baseline 4 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 computation (最低價、原價折扣) derived from daily price records (每日記錄售價), so the resource and verb are identifiable. It does not, however, distinguish this from sibling tools like list_price_drops or compare_chain_prices, leaving overlap unclear.
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?
There is no explicit when-to-use, when-not-to-use, or reference to any alternative such as list_price_drops or compare_chain_prices. An agent must infer the scope from the description alone.
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?
No annotations are provided, so the description carries the full burden. It discloses the filter thresholds, which is useful, but says nothing about ordering (e.g., sorted by drop percentage), result limits, pagination, or whether it is a read-only listing — for a zero-annotation tool this is a notable 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?
One compact sentence with no filler, and the core filter criteria are front-loaded. Nothing is wasted, though the brevity is also what leaves the gaps elsewhere.
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 annotations, no output schema, and an undocumented parameter, the description should do more work than it does. It never explains result ordering, count, or the category filter, so an agent still lacks information needed to invoke it confidently.
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 0% and the description never mentions the single `category` parameter or its allowed enum values. The enum values are self-describing in the schema, but the description adds no meaning about how category narrows the result set, leaving the parameter semantics undocumented.
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 (降價/創新低的商品) with concrete thresholds (3% drop, 30-day low), so the agent knows exactly what set is returned. It does not, however, contrast this with siblings like search_products or get_product_price, so differentiation is left to inference.
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 when-to-use guidance is given relative to the sibling tools (get_product_price, list_categories, search_products). The criteria describe what is returned rather than when an agent should pick this tool over a general product search, so usage must be guessed.
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 behavioral burden. It usefully discloses the return fields (product, store, price, confirmation time) in place of a missing output schema, but says nothing about data freshness, caching, rate limits, or whether the confirmation time is a live check.
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 sentence front-loads the action and scope, then the return payload. It is dense but every clause carries information, with no filler or repetition.
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 annotations and no output schema, the description does cover purpose, scope, currency, and return fields, which is adequate for a 2-parameter search tool. However, it omits how results are ranked/limited, pagination, and any freshness caveat around the confirmation time, leaving real gaps.
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%: query is documented in the schema and category is an enum without per-value descriptions. The description only loosely maps its parenthetical categories (3C, beauty, appliances) onto the enum values, so it adds marginal meaning rather than compensating for the coverage gap. Baseline 3 fits.
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?
Specific verb+resource (搜尋...商品) with clear scope: Taiwan shopping sites, three product categories, NTD pricing, and the returned fields. An agent can tell it searches rather than retrieves a single price, but the description never explicitly contrasts itself with siblings like get_product_price or list_price_drops.
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?
There is no when-to-use or when-not-to-use guidance at all. The sibling get_product_price is highly overlapping (both surface a price), yet the description gives no rule for choosing between them, leaving the agent to infer from the names alone.
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.
compare_chain_priceslist_chain_promoslist_lowest_priceslist_price_drops1 field changedInput schema / properties / category / enumPrevious value: -[
- "earbuds",
- "powerbank",
- "smartwatch",
- "ssd",
- "monitor",
- "skincare",
- "makeup",
- "kitchen",
- "home-appliance"
-]New value: +[
+ "earbuds",
+ "powerbank",
+ "smartwatch",
+ "ssd",
+ "monitor",
+ "skincare",
+ "makeup",
+ "kitchen",
+ "home-appliance",
+ "daily"
+]search_products1 field changedInput schema / properties / category / enumPrevious value: -[
- "earbuds",
- "powerbank",
- "smartwatch",
- "ssd",
- "monitor",
- "skincare",
- "makeup",
- "kitchen",
- "home-appliance"
-]New value: +[
+ "earbuds",
+ "powerbank",
+ "smartwatch",
+ "ssd",
+ "monitor",
+ "skincare",
+ "makeup",
+ "kitchen",
+ "home-appliance",
+ "daily"
+]get_product_pricelist_categorieslist_price_dropssearch_products台灣電商情報與商品比價：跨通路查 momo、PChome、品牌官網即時價格與歷史最低價、偵測網站電商技術、搜尋電商知識庫。資料來源 ecpro.tw。
Add one secure layer between your agents and this server.
