Compare 2–5 public products side by side (price, stock, min/max, sold, category) with a quick summary (cheapest / most stock / best seller). So sánh 2–5 sản phẩm cạnh nhau để khách chốt nhanh. Chỉ field công khai (giá VND).
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | Danh sách 2–5 product id cần so sánh, vd [943, 1004]. Cũng chấp nhận chuỗi "943,1004". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It discloses that only public fields are used, prices are in VND, and the tool produces a summary (cheapest / most stock / best seller), which gives an agent useful expectations despite no output schema.
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 English opening sentence is dense and front-loaded with the core behavior. The two Vietnamese sentences add user purpose and the public/price-only constraint, though they slightly overlap with content already stated.
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 straightforward comparison tool with one parameter and no output schema, the description covers inputs, the count constraint, the compared fields, and the high-level output summary. It foo not specify exact output formatting or invalid-ID behavior, but that is a minor gap.
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 already documents the `ids` parameter fully, including the 2–5 count and the accepted string format. The main description reinforces the count, but adds little beyond what the schema and description already provide.
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 action (compare), resource (public products), and scope (2–5) with the compared fields (price, stock, min/max, sold, category) plus summary outputs. This clearly distinguishes it from single-product or search-style siblings.
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 gives a clear use context: comparing 2–5 public products side by side so a customer can decide quickly. It also implies a scope constraint (public products only), though it does not explicitly name alternative sibling tools to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Product discovery tools such as best_sellers, latest_products, recommend_products, and similar_products have related listing purposes and could be confused, though descriptions clarify sorting and filtering criteria. Social-check tools also overlap: check_live_facebook, deep_inspect, and check_health_bulk can all verify Facebook accounts. Most tools are distinct, but the boundaries are not always crisp.
The dominant convention is snake_case verb_noun, e.g. buy_product, search_products, list_categories, check_order_status. A few names deviate, such as best_sellers, latest_products, similar_products, how_to_start, and deep_inspect, but they are still readable and predictable.
With 19 tools, the set falls into the 16-25 heavy range and could be trimmed: there are nine product-listing/search/recommend tools and three overlapping social-check tools. The count is not extreme, and the combined commerce-plus-verification scope is covered, but it feels heavier than necessary.
The core commerce workflow is complete: discover products, quote, confirm purchase, check order status, and view balance. Minor gaps include no order-history tool, no cancellation tool, and no actual top-up execution, but these are workaroundable for the stated shop purpose.