实时涨跌停统计：封板数、炸板数、封板率、今日vs昨日对比，量化市场强度 何时使用: 权威涨跌停/炸板/封板率口径；历史交易日优先读取本地收盘统计，盘前/非交易日返回明确状态。配合 market_overview 和 limit_up_ladder。
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | 必填。交易日期，支持 YYYY-MM-DD 或 YYYYMMDD。 | |
| format | No | content[0].text：默认1行 headline；markdown=完整 markdown 表格；json=完整 JSON。 | |
| 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, so the safety profile is covered. The description adds genuine non-obvious behavior: data source routing (local close statistics for historical dates) and defined behavior on non-trading days. Return format is not described but an output schema exists, so this is a meaningful addition.
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?
A single dense block that front-loads purpose, then the when-to-use condition, with no redundant sentences. It is packed with delimiters rather than wasted prose, though the transition between purpose and usage could be slightly cleaner.
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?
Covers purpose, usage conditions, and non-trading-day edge behavior; an output schema exists so return-value explanation is rightly omitted. For a 3-param, one-required read tool this is essentially complete, with only explicit sibling exclusions missing.
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 date format, format, and detailLevel are already documented in the schema. The description adds no syntax, default, or interaction detail beyond what the schema provides. Baseline 3 applies when the schema carries the full parameter burden.
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 resource (实时涨跌停统计) and enumerates concrete outputs: 封板数, 炸板数, 封板率, 今日vs昨日对比. This distinguishes it from event-level siblings like limit_events and broken_limit_up, which report individual events rather than aggregate strength metrics. It stops short of an explicit negative boundary ('do not use for X').
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?
Has a dedicated 何时使用 clause that names the authoritative caliber (涨跌停/炸板/封板率) and states edge-case routing: historical days read local close stats, pre-market/non-trading days return an explicit status. It also names companion tools (market_overview, limit_up_ladder), giving clear context. No explicit when-not-to-use or alternatives is given, so not a 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.