台灣電商情報與商品比價：跨通路查 momo、PChome、品牌官網即時價格與歷史最低價、偵測網站電商技術、搜尋電商知識庫。資料來源 ecpro.tw。
查某個商品品類在台灣的整體行情：最低價、中位數、平均、最高價與各價格帶。使用者問「○○大概多少錢」「○○行情」「多少預算能買到○○」時使用。
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | 品類，例如「藍牙喇叭」「氣炸鍋」「除濕機」 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool returns price statistics but does not explain behavior such as authentication, rate limits, data freshness, or what happens if category is invalid. Adequate but lacks depth.
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?
Two sentences, front-loaded with purpose, no redundant information. Every word 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's simplicity (1 param, no output schema), the description adequately explains purpose and usage. Could optionally describe return format, but not critical for invocation.
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 covers 100% of parameters with a clear description for 'category'. Description reuses the same examples as the schema, adding minimal extra meaning. 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?
Description clearly states the tool returns market price statistics (lowest, median, average, highest) for a product category in Taiwan, and explicitly lists example user queries that trigger its use. Distinguishes from siblings like 'compare_prices' or 'find_deals'.
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?
Description gives concrete usage scenarios (e.g., 'How much does XX cost?'), implying when to use the tool. It does not explicitly mention when not to use or provide alternatives, but the context is clear enough for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
檢查一個台灣網購網站是否安全：比對 8.8 萬筆詐騙通報名單、是否已收錄建檔、有無營運公司登記。使用者買東西前問「這網站安全嗎／是不是詐騙／可以信任嗎」時使用。
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | 網站網址或網域，例如 example.com.tw |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the three checks performed (fraud list, recording, company registration). It implies a safe read operation. It does not mention output format or limitations (e.g., Taiwan-only), but the core behavior is transparent.
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?
Two sentences, front-loaded with the main action and key details. No redundant information.
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 tool with one parameter and no output schema, the description covers purpose, usage scenario, and behavior. Could explicitly mention output nature, but not essential.
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% with domain described as '網站網址或網域'. The tool description adds context about Taiwan online shopping but adds minimal meaning 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?
The description clearly states the tool's function: checking the safety of a Taiwan online shopping website by comparing against fraud lists, checking archiving, and company registration. It distinguishes itself from sibling tools (prices, products, tech) by focusing on security/scam verification.
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 states when to use (when users ask about safety/scam/trust before buying). It does not explicitly state when not to use or list alternatives, but the sibling tool list context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
比較某商品在 momo、PChome 與台灣品牌官網的價格，回傳整體最低價、各通路最低價與候選清單。使用者問「哪裡買最便宜」「幫我比價」時使用。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 商品關鍵字，越精確越好，例如「SONY SRS-XB100」 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry behavioral details. It describes outputs (lowest overall, per-store, candidate list) but lacks information on data freshness, caching, authorization needs, or side effects. The read-only nature is implied but not explicit.
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?
Single sentence (in Chinese) covers tool scope, outputs, and usage context. No wasted words; front-loaded with key information.
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 single-parameter tool with no output schema, the description adequately explains outputs (lowest prices, candidate list) and use case. Could mention result format or data source timeliness, but sufficient for typical agent use.
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% with a single 'query' parameter already well-described in the schema. The description does not add new meaning or constraints beyond the schema's example and advice.
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?
Description clearly specifies the tool compares prices across momo, PChome, and Taiwanese brand official sites, and returns overall lowest price, per-store lowest price, and candidate list. This distinguishes it clearly from siblings like 'category_price_range' and 'price_match_check'.
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?
Explicitly states when to use: when user asks 'where to buy cheapest' or 'help me compare prices'. However, does not provide exclusions or mention alternative tools for similar queries.
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 |
|---|---|---|---|
| amount_twd | Yes | 台幣金額 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims conversion to major currencies but does not specify how the target currency is selected (no parameter for it). The input schema only includes 'amount_twd', leaving ambiguity about whether the tool returns all currencies or only one. No annotations are provided to clarify safety or behavior.
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 two sentences, immediately front-loading the purpose and usage context. Every word earns its place, with no wasted text.
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?
No output schema is provided, and the description does not explain what the tool returns (e.g., conversion result, list of currencies). The ambiguity about target currency selection makes it incomplete for a straightforward conversion tool.
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% with a clear description for 'amount_twd' ('台幣金額'). The tool description adds that it is the amount to convert, but no further semantics like bounds or validation. Score at baseline as schema already documents the parameter.
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 converts TWD to major foreign currencies (USD, JPY, RMB) using real-time exchange rates. It distinguishes itself from sibling tools, which are e-commerce and price comparison focused.
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 tells when to use the tool: when users ask 'how much in USD/JPY' or for cross-border price comparison. It does not explicitly mention when not to use, but the context is clear and no alternative tools are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
找出同一款商品在 momo、PChome、品牌官網之間價差最大的排行：選對通路能省最多的商品清單。使用者問「哪些東西不同通路差很多」「同款哪裡買最便宜」時使用。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 回傳筆數，預設 15，最多 30 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description holds full responsibility. It implies a read-only operation (ranking) but does not disclose data source, update frequency, or behavior when no gaps exist. Minimal behavioral context beyond purpose.
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 concise and front-loaded with the action, but it is a single run-on sentence. Could be improved with clearer structure, but no unnecessary 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?
Given the tool has one parameter and no output schema, the description covers purpose and usage scenarios adequately. It could explain output format or edge cases, but for a simple ranking tool, it is nearly 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 coverage is 100% for the single 'limit' parameter, which is fully documented in the schema. The description adds no additional information about the parameter, so 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 specifically states it finds rankings of price gaps for the same product across momo, PChome, and brand official websites, and provides example user queries. This clearly distinguishes it from sibling tools like compare_prices, which does general comparison, and find_deals.
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 includes example queries ('哪些東西不同通路差很多' and '同款哪裡買最便宜') to guide when to use the tool. However, it does not explicitly mention when not to use it or suggest alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
即時偵測任一網站使用的電商技術：開店平台（SHOPLINE / 91APP / Shopify / WooCommerce 等）、金流、廣告像素、分析追蹤與行銷工具。輸入網址或網域。
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | 網址或網域，例如 example.com.tw |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only mentions real-time detection and lists technology categories. It does not disclose return format, error handling, rate limits, or authentication needs, leaving significant 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?
The description is brief with two sentences, but the second sentence ('輸入網址或網域') is redundant with the parameter schema. It is concise but could be slightly improved by removing redundancy.
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?
Despite no output schema or annotations, the description fails to describe the return structure of detected technologies. It only lists input and examples, leaving the agent unaware of the output format, which is essential for correct invocation.
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 'url' parameter, and the description simply restates '輸入網址或網域' without adding new semantic value. Baseline score of 3 is appropriate as the schema already provides sufficient definition.
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 detects e-commerce technologies (storefront platforms, payment gateways, ad pixels, analytics) for any website, using a specific verb ('偵測') and resource ('網站使用的電商技術'). It distinguishes itself from sibling tools like 'find_sites_by_tech' which solves the inverse problem.
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 no explicit guidance on when to use this tool versus alternatives such as 'check_store_safety' or 'find_sites_by_tech'. It only describes the core function without contextual selection advice.
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 |
|---|---|---|---|
| type | No | 優惠類型：lowest（跌到歷史新低，預設）｜discount（折扣最深） | |
| limit | No | 回傳筆數，預設 15，最多 30 | |
| category | No | 可選，指定品類看該品類最低價，例如「氣炸鍋」「藍牙喇叭」 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It explains what the tool does (find deals) but does not disclose data freshness, source limitations, rate limits, or any side effects. For a read-only tool, this is moderate but lacks depth.
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 a concise paragraph that front-loads purpose and then gives usage guidance. Every sentence is informative with no wasted words. It could be slightly more structured but is effective.
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 no output schema and no annotations, the description covers tool purpose, parameters, and usage context adequately. However, it does not describe the return format or any error/edge case behavior, leaving some 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 100% with parameter descriptions. The description adds value by indicating defaults (type='lowest', limit=15) and providing usage examples (e.g., category for specific items). This goes beyond the schema alone.
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 finds deals (historical lows, deepest discounts, category lowest price). It specifies the domain (Taiwan e-commerce) and resource (deals). However, it does not explicitly differentiate from sibling tools like category_price_range or compare_prices.
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 states when to use: when the user asks about daily deals/discounts or cheap items. This provides clear usage context but omits when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
反查台灣有哪些網站使用某個電商技術（開店平台、金流、廣告像素、分析工具）。使用者問「用 SHOPLINE 的台灣網站有哪些」「哪些站在用綠界金流」時使用。
| Name | Required | Description | Default |
|---|---|---|---|
| tech | Yes | 技術名稱，例如「SHOPLINE」「CYBERBIZ」「綠界」「Meta Pixel」 | |
| limit | No | 回傳筆數，預設 20，最多 50 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the use case and does not mention any behavioral traits like read-only nature, authentication requirements, rate limits, or what the output contains. This lack of transparency is a significant gap for a query 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?
The description is a single, front-loaded sentence with examples. It is concise and contains no superfluous words. Every part serves to clarify the tool's purpose.
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's simplicity (2 parameters, no nested objects), the description covers the basic purpose and example usage. However, it lacks information about the output format or any limitations. Since there is no output schema, the description should explain what the tool returns, but it does not.
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% as both parameters have descriptions. The description does not add meaningful extra information beyond the schema; it merely repeats example values. With high schema coverage, the baseline is 3, and no additional value is provided.
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: to find Taiwanese websites using a specific e-commerce technology. It provides concrete examples like 'SHOPLINE' and '綠界金流', making the function unambiguous. It also distinguishes from sibling tools like 'detect_site_tech' which does the reverse operation.
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 specifies when to use the tool (when users ask for sites using a particular tech) and gives example queries. However, it does not mention when not to use it or potential alternatives, such as using 'detect_site_tech' for the opposite direction. The usage context is clear but lacks exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
用 slug 取得 ECPRO 電商博士單篇文章的完整內容（純文字），含常見問答（FAQ）。先用 search_ecommerce_articles 找到 slug 再呼叫。
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | 文章 slug，例如 aov-average-order-value-optimization |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool returns plain text content including FAQ, but does not mention authentication needs, rate limits, or any side effects. For a simple read operation, this is adequate but not comprehensive.
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?
Two sentences with no wasted words. Front-loaded with the action and key details: what it retrieves (content, FAQ) and how to use (find slug first). Efficient and scannable.
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 simple tool with one parameter and no output schema, the description covers the essential workflow and output. It could mention potential error cases or response format details, but is sufficiently complete for an AI agent to use correctly.
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 description explains the purpose of the slug parameter (to identify the article found via search) and provides an example value. Schema coverage is 100%, but the description adds contextual usage guidance beyond the schema's basic description.
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 retrieves the complete plain text content of a single ECPRO article by slug, including FAQ. It distinguishes itself from sibling tool search_ecommerce_articles by specifying that the slug must be obtained from that search first.
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?
Explicitly instructs to first use search_ecommerce_articles to find the slug before calling this tool. Provides clear prerequisite context, though it does not elaborate on when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
取得單一商品的歷史價格走勢（日期＋價格），判斷現在是不是低點、是不是真優惠。offer_id 由 search_products / compare_prices 的結果取得。
| Name | Required | Description | Default |
|---|---|---|---|
| offer_id | Yes | 商品 offer_id，例如 momo:15014911 |
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 the output (date and price) and the analytical purpose, making the tool's behavior transparent. It could explicitly mention that it is a read-only operation, but the context implies no side effects.
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 extremely concise: two sentences that cover purpose, output, and parameter source. 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?
Despite the lack of an output schema, the description explains the return value (historical price trend with date and price) and the tool's purpose. For a simple tool with one parameter, this is 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 coverage is 100% with a description and example for offer_id. The tool description adds value by explaining where to obtain the offer_id, enhancing understanding 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?
The description clearly states the tool retrieves historical price trends (date + price) and helps determine if a product is at a low point or truly discounted. It distinguishes from siblings like compare_prices by focusing on history.
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 tells the agent to derive offer_id from search_products or compare_prices, providing clear context for usage. However, it does not explicitly state when not to use this tool, but the purpose is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出 ECPRO 電商博士知識庫的所有文章分類與各分類文章數，用來了解知識庫涵蓋範圍。
| 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 full burden. It implies a read-only listing operation with no side effects, which is consistent with the no-parameter, no-output-schema context. However, it lacks explicit statements about authentication, rate limits, or data freshness, but given the simplicity, this is acceptable.
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 a single, clear sentence that conveys the entire purpose without unnecessary words. It is appropriately sized and front-loaded.
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 tool with zero parameters and no output schema, the description fully explains what it does and its purpose. No additional context is needed.
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 are no parameters, so the input schema provides complete coverage. The description adds no parameter details, but none are needed. Baseline score of 4 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 the tool lists all article categories and their article counts in the ECPRO knowledge base, specifying the resource and purpose (understanding coverage). It distinguishes from sibling tools like get_ecommerce_article or search_ecommerce_articles by focusing on categories overview.
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 implies usage for understanding knowledge base coverage but provides no explicit guidance on when to use this tool versus alternatives like category_price_range or search_ecommerce_articles. No when-not or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
用商品條碼查食品的成分、營養、過敏原（Open Food Facts 全球食品資料庫）。使用者掃到條碼、問食品成分/營養時使用。
| Name | Required | Description | Default |
|---|---|---|---|
| barcode | Yes | 商品條碼（EAN/UPC 數字） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It names the database (Open Food Facts) and implies it is a read operation, but does not disclose behavior on invalid barcodes, rate limits, or whether it requires authentication. Minimal but adequate.
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?
Two compact sentences, no filler. All information is front-loaded and relevant.
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 lookup tool with one parameter and no output schema, the description does well: it lists the data returned (ingredients, nutrition, allergens) and the database. Could mention handling of unknown barcodes or response format, but fine overall.
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% with one parameter 'barcode' described as '商品條碼（EAN/UPC 數字）'. The tool description adds context about using barcode to query food data, which overlaps with the schema description. Baseline score of 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?
Description clearly states the tool uses a barcode to look up food ingredients, nutrition, and allergens from Open Food Facts. It provides a specific verb-resource pair and distinguishes itself from sibling tools focused on e-commerce and pricing.
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?
Description explicitly says when to use: when user scans a barcode or asks about food ingredients/nutrition. It does not state when not to use or list alternatives, but the context is clear enough.
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 |
|---|---|---|---|
| product | Yes | 商品名稱或關鍵字 | |
| paid_price | Yes | 你付的價格（元） |
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 describes the tool's action and return type (cheaper prices and savings) but does not disclose data sources, accuracy, or any side effects. The behavior is implied but not explicitly detailed.
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 a single sentence that efficiently conveys purpose and usage context with no redundant words. It is front-loaded with the core action and includes useful example queries.
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's simplicity (2 basic string/number parameters, no output schema) and the presence of many sibling tools, the description is nearly complete: it states what it does and when to use it. It could be improved by clarifying what '其他通路' refers to, but it is still sufficient for an agent to understand its basic function.
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%, and the description restates the parameter purposes ('商品名稱或關鍵字' and '你付的價格（元）'), matching the schema. No additional semantic information is added beyond what the schema provides.
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 with a specific verb ('檢查' check) and resource ('商品是否買貴' price match), and provides example queries that distinguish it from sibling tools like compare_prices or cross_channel_gaps.
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 includes explicit trigger phrases ('使用者問「我買的○○貴了嗎」「這價格合理嗎」') that indicate when to use this tool, but does not explicitly mention when not to use it or differentiate from all sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
依預算和情境推薦台灣商品：送禮、學生、租屋族、居家辦公等。使用者問「X 元送禮推薦什麼」「租屋族該買什麼」「學生 3C 推薦」時使用。
| Name | Required | Description | Default |
|---|---|---|---|
| scene | No | 可選情境關鍵字，例如「送禮」「租屋」「學生」「露營」「居家辦公」 | |
| budget | Yes | 預算上限（元） | |
| category | No | 可選，指定品類，例如「藍牙耳機」 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description implies a read-only recommendation operation but does not explicitly state read-only behavior or any side effects. For a tool with no annotations, the description could be more transparent.
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 concise, with a single sentence stating the purpose and two example queries. It is front-loaded and easy to parse, though it could slightly benefit from a clearer structure.
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 no output schema, the description does not explain the return format or any additional context. However, for a simple recommendation tool, the core purpose and parameters are sufficiently covered.
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 description adds no extra meaning beyond what the schema already provides. The description's mention of scenarios aligns with the 'scene' parameter but does not enhance understanding of 'budget' or 'category'.
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: recommending Taiwanese products by budget and scenario, with specific examples like gift-giving, students, renters, and work-from-home. It distinguishes itself from sibling tools like search_products or find_deals by focusing on scenario-based recommendations.
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 explicit usage examples (e.g., 'X元送禮推薦', '租屋族該買什麼'), helping the agent know when to invoke it. However, it does not specify when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜尋 ECPRO 電商博士的電商經營知識文章（繁體中文，涵蓋行銷、傳播、品牌、廣告流量、轉換優化、會員回購、金流財務、物流營運、數據 KPI、跨境通路、AI 應用等）。回傳標題、摘要、分類與網址。回答台灣電商經營、開店、行銷、廣告、數據等問題時使用。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 回傳筆數，預設 8，最多 20 | |
| query | Yes | 關鍵字，例如「客單價」「Meta 廣告」「跨境」「復購」 | |
| category | No | 可選分類，例如「廣告與流量」「金流定價財務」「會員與回購」 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses return fields (title, summary, category, URL) but lacks details on side effects, rate limits, or whether it is read-only (likely read-only). Basic behavioral context is present but not comprehensive.
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?
Two sentences, no wasted words. The first sentence defines the tool's purpose and scope, the second adds return fields and usage context. Front-loaded and efficient.
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 no output schema, the description adequately states return fields. It covers the main use case but omits details on pagination, ordering, or result limits beyond the 'limit' parameter. Acceptable for a search tool.
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 baseline is 3. The description adds value by providing concrete examples for 'query' and explicit category values, going beyond the schema's basic descriptions.
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 it searches for e-commerce knowledge articles in Traditional Chinese, covering a broad range of topics. It distinguishes itself from siblings like 'get_ecommerce_article' and 'list_article_categories' by specifying the search functionality.
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?
Provides explicit context: '回答台灣電商經營、開店、行銷、廣告、數據等問題時使用' (use when answering questions about Taiwan e-commerce). However, it does not mention when not to use it or compare with sibling tools like 'get_ecommerce_article'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜尋台灣電商商品與價格（涵蓋 momo、PChome 24h 與台灣品牌官網）。回傳商品名、目前價格、通路與購買連結，依價格由低到高。使用者想買某商品、問價格、要推薦選購時使用。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 回傳筆數，預設 10，最多 20 | |
| query | Yes | 商品關鍵字，例如「藍牙喇叭」「氣炸鍋」「Marshall 喇叭」 | |
| channel | No | 限定通路：momo｜pchome｜official（品牌官網），可選 | |
| max_price | No | 價格上限（元），可選 | |
| min_price | No | 價格下限（元），可選 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It states return fields and sorting behavior ('依價格由低到高'), implying a read-only search. It does not explicitly disclose idempotency or safety, but the semantics are clear enough for a search 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?
Three sentences: what it does, what it returns, when to use. No wasted words, front-loaded with essential information.
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?
No output schema, but description explains return structure (product name, price, channel, link) and sorting. It covers all key aspects for a search tool, though pagination or limit behavior could be mentioned.
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% and parameter descriptions are clear. The tool description adds context about result sorting (by price low to high) not in schema, but otherwise does not add meaning beyond schema. 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 states a specific verb ('搜尋'), resource ('台灣電商商品與價格'), and scope ('涵蓋 momo、PChome 24h 與台灣品牌官網'). It distinguishes from siblings by focusing on cross-channel product search for Taiwan e-commerce, unlike compare_prices or find_deals.
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 use ('使用者想買某商品、問價格、要推薦選購時使用'). It provides clear context but does not mention when not to use or alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
判斷某商品現在是不是買點：用歷史價與近期趨勢分析「該買還是等」。使用者問「○○現在該買嗎」「這價格划算嗎」「還會再降嗎」時使用。offer_id 由 search_products / compare_prices 取得。
| Name | Required | Description | Default |
|---|---|---|---|
| offer_id | Yes | 商品 offer_id，例如 momo:15014911 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must handle transparency fully. It mentions using historical prices and trends but does not disclose if the tool is read-only, any rate limits, or what the output looks like. More detail on behavior would be beneficial.
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 extremely concise with two sentences plus a note. It is front-loaded with the core purpose and use cases, and every sentence adds value without 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?
Given the tool has only one parameter and no output schema, the description covers purpose, usage, and parameter source. However, it does not describe the return format or any failure modes, which would improve completeness for a tool that produces a decision.
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 has 100% description coverage for the single parameter (offer_id). The description additionally explains where to obtain the offer_id, providing context beyond the schema. This warrants a score above baseline.
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: to determine if a product is a good buy now using historical prices and trends. It provides specific example user queries (e.g., 'Should I buy XX now?', 'Is this price good?') and distinguishes itself from siblings by focusing on the buy/wait decision.
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 specifies when to use the tool (when users ask about buying decisions) and explains how to obtain the required parameter (offer_id from search_products/compare_prices). It does not explicitly state when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Search 86 US retailers — 260M+ products with real-time pricing, stock, and price history.
Price comparison across partner retailers. Read-only, 90-day history, disclosed affiliate.
一心eSIM商品目錄查詢與下單服務：查詢各國eSIM上網方案的即時價格與庫存、依旅遊天數與用量推薦方案、協助建立訂單並取得LinePay或ECPay付款連結。
Cross-merchant product search with real price history, comparisons, and demand signals.
Add one secure layer between your agents and this server.
Most tools have clearly distinct purposes, such as price comparison vs. price history vs. store safety. However, there is some overlap between compare_prices, cross_channel_gaps, and price_match_check, which all involve comparing prices across channels. The descriptions help differentiate them, but ambiguity remains for agents.
Tool names use snake_case but vary in structure: some start with verbs (compare_prices, find_deals), others with nouns (category_price_range, price_match_check). There is no strict verb_noun pattern, and 'should_i_buy_now' is a full phrase, breaking consistency.
17 tools cover a wide range of e-commerce assistance tasks without being overwhelming. The count is appropriate for the domain, though a few tools (e.g., price_match_check vs. should_i_buy_now) could potentially be merged without losing functionality.
The tool set covers most common user needs in Taiwanese e-commerce: product search, price comparison, historical trends, deals, store safety, tech detection, and currency conversion. Missing operations include user-specific features (e.g., watchlist) but the core lifecycle is well-represented.
