Retrieve price-drop alerts from Shopee price monitoring, with options to filter unread notifications or a specific site and limit the number returned.
获取价格预警列表，查看系统推送过的所有降价预警。支持未读筛选和站点过滤。
用户可能的问法：
"有没有新的降价预警"
"最近有哪些商品降价了"
"未读的预警有几条"
"上次推送的那个降价预警是哪个商品"
可选参数：
unread_only: 只返回未读预警（默认 false）
site: 按站点筛选
limit: 返回条数上限（默认 10，最大 50）
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | ||
| limit | No | ||
| unread_only | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.3.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral load. It implies a safe read-only listing operation and discloses meaningful limits (default 10, max 50 for limit). However, it does not discuss permissions, ordering, pagination beyond limit, or failure behavior, so gaps remain for a tool with zero annotation coverage.
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 front-loaded with the core purpose, followed by compact usage examples and then the parameter list. The example questions add routing value rather than just filling space. It could be tightened, but everything included supports selection or invocation.
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?
Output schema exists, so return-value documentation is not required. For a zero-required-parameter read tool, the description covers purpose, usage triggers, and all three parameters. Minor omissions such as ordering or what fields an alert contains are acceptable given the output schema.
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%, so the description has to compensate. It explains all three parameters: unread_only filters unread alerts (default false), site filters by site, and limit caps the number of results (default 10, maximum 50). The maximum of 50 and the purpose of site are facts that the bare schema does not convey, though there is no format guidance for site.
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: it fetches the list of price alerts, covering all drop alerts the system has pushed, along with scoping for unread-only and site filters. This clearly separates it from sibling tools such as mark_alert_read or get_price_summary, though it never names a sibling explicitly or with an explicit comparison.
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?
It tells an agent what to use this tool for by listing the kinds of user questions this tool answers, such as "any new drop alerts" or "how many unread alerts". That is strong context for routing. There is no explicit when-not-to-use guidance, and no alternatives are named, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.