find_sites_by_tech
反查台灣有哪些網站使用某個電商技術（開店平台、金流、廣告像素、分析工具）。使用者問「用 SHOPLINE 的台灣網站有哪些」「哪些站在用綠界金流」時使用。
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tech | Yes | 技術名稱，例如「SHOPLINE」「CYBERBIZ」「綠界」「Meta Pixel」 | |
| limit | No | 回傳筆數，預設 20，最多 50 |
ecpro-mcp
TDQS
A3.7/5.0
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A3.7/5.0
Disambiguation4/5
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.
Naming Consistency3/5
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.
Tool Count4/5
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.
Completeness4/5
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.