Retrieves a user's monitored Shopee products with current and benchmark prices, price changes, and status, optionally filtered by site or active/paused status.
获取用户正在监控的商品列表。
用户可能的问法：
"我在盯哪些商品"
"SG 站有几个商品在监控"
"我的监控列表"
"暂停中的监控有几个"
返回监控项数组，每项包含商品名、店铺、站点、基准价、当前价、变动幅度、状态等。
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | ||
| status | No | active |
| 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?
No annotations are present, so the description carries the full load. It discloses that the result is an array of monitor items with fields including product name, shop, site, baseline price, current price, change magnitude, and status, which is useful. It says nothing about permissions, pagination, list size limits, or whether 'active' is the implicit default filter.
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 one-line purpose is front-loaded, followed by a compact bullet list of user phrasings and a single return-shape sentence. No filler sentences.
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?
An output schema exists, so the return-value sentence is somewhat redundant but harmless. For a zero-required-param read tool the main gaps are undocumented parameter semantics and the lack of any routing guidance against the many read siblings, leaving the definition only minimally sufficient.
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 names the two parameters. The example questions ('SG 站...' and '暂停中的监控...') hint at site and status filtering, but there is no explanation of accepted values, that status defaults to 'active', or that site is nullable.
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: '获取用户正在监控的商品列表' (retrieve the list of products the user is monitoring). It is clearly distinguishable from mutation siblings like add_monitor and update_monitor_status, though it doesn't differentiate itself from get_monitor_overview or get_price_summary.
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?
Four example user phrasings ('我在盯哪些商品', 'SG 站有几个商品在监控', '我的监控列表', '暂停中的监控有几个') give concrete triggers for when this tool applies. However, no exclusions or alternative-tool routing are given, so an agent can't tell when get_monitor_overview would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.