读取当前 API key 所属用户的自选股分组列表，支持只看空分组。只读工具。 何时使用: 读取当前 API key 所属用户的自选股分组列表，可筛空分组。只在用户明确问"我的自选分组/有哪些空组/分组列表"时使用。
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | content[0].text：默认1行 headline；markdown=完整 markdown 表格；json=完整 JSON。 | |
| onlyEmpty | No | 是否只返回空分组。用户说"空组/没有股票的组"时传 true。默认 false。 | |
| detailLevel | No | 档位：默认 standard（Agent 可计算标准字段）；summary=压缩摘要；raw=全字段+原始数据。 |
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | ||
| meta | No | ||
| success | No |
Changes observed during successful MCP inspections.
Input schema / properties / detailLevel / descriptionPrevious value: -"输出详细度（不传=standard，返回 Agent 可计算标准字段）。summary=压缩摘要；raw=全字段+原始数据。"New value: +"档位：默认 standard（Agent 可计算标准字段）；summary=压缩摘要；raw=全字段+原始数据。"Input schema / properties / format / descriptionPrevious value: -"content[0].text 形态。通常不传=1 行 headline；auction_market_scan / auction_theme_strength 在 standard/raw 档默认直接返回 JSON 明细。markdown=完整 markdown 表格；json=完整 JSON。"New value: +"content[0].text：默认1行 headline；markdown=完整 markdown 表格；json=完整 JSON。"Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "data": {},
+ "meta": {},
+ "success": {}
+ },
+ "type": "object"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint; the description's 只读工具 simply restates that. It does add one genuinely useful scoping fact — results are limited to the user owning the current API key — but says nothing about return shape, pagination, or rate limits beyond what annotations cover.
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?
Purpose is front-loaded before the 何时使用 clause, which is good structure. However the purpose sentence is repeated almost verbatim in the usage clause (读取当前 API key 所属用户的自选股分组列表 appears twice), wasting a sentence.
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 return values need no explanation, and all three parameters are documented. Safety traits are covered by annotations. The description is complete enough for correct invocation, with only minor redundancy remaining.
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%, so the schema already fully documents format, onlyEmpty and detailLevel. The description only echoes onlyEmpty via 支持只看空分组 and adds no syntax or format detail, so the 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?
States a specific verb and resource: 读取…自选股分组列表 (read the watchlist-group list). The resource is clearly distinct from siblings like watchlist_list (stocks in a watchlist) and watchlist_group_create/delete/rename (group mutations). It does not explicitly name a sibling, so it stops short of a 5.
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 何时使用 clause explicitly triggers on user phrasings ('我的自选分组/有哪些空组/分组列表'), giving concrete when-to-use context. There is no explicit when-not or naming of the alternative tool, so it is not a full 5.
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.