创建当前 API key 所属用户的空自选股分组。写入工具，仅在用户明确要求新增/创建分组时使用。 何时使用: 创建当前 API key 所属用户的自选股空分组。自选分组最多 20 个。只有用户明确要求创建/新增分组时调用。
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | content[0].text：默认1行 headline；markdown=完整 markdown 表格；json=完整 JSON。 | |
| groupName | Yes | 必填。要创建的自选股分组名。分组名最长 50 字；每个用户最多 20 个自选分组。 | |
| 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 the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), so the description's 'write tool' label is largely redundant. It does add the 20-group cap, but that constraint is also stated in the groupName schema, and it omits what happens on name collision or when the limit is reached.
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 content is duplicated across sentences: the base sentence, the '何时使用' restatement, and the closing '只有用户明确要求创建/新增分组时调用' all repeat the same 'create an empty group' / 'only when explicitly requested' ideas. The repetition crowds out genuinely new information.
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-value explanation is not required. For a simple one-required-parameter write tool, the description covers the actor (current API-key user), the outcome (empty group), and the group cap — enough to call it correctly.
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 all three parameters (groupName, format, detailLevel) are already documented in the schema. The description adds no format/validation detail beyond what the schema provides, making baseline 3 appropriate.
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 (create) plus resource (empty watchlist group) and scope (belonging to the current API-key's user). It is clearly distinguishable from siblings like watchlist_add or watchlist_group_rename because it emphasizes the group is created empty.
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?
Gives an explicit usage condition — 'only call when the user explicitly requests creating/adding a group' — which prevents speculative invocation. It does not, however, name alternative siblings (e.g., rename/list/delete) or clarify what to do if the group already exists.
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.