Skip to main content
Glama

Wudao A-Share Stock Data MCP

board_break_analysis

Read-onlyIdempotent

短线复盘核心面板:昨涨停 × 今日行情交叉。回答"昨涨停今天断板的、昨连板今天没板、高标杀、断板后是退潮还是分歧、晋级/淘汰率、市场是退潮还是修复"。返回 breakRate(断板率)、avgBrokenPctChg、sentimentSignal=cooling/neutral/warming、highBoardBroken 高标杀名单、statusBreakdown 细分。focus=broken/sealed_again/all。 何时使用: 断板分析(短线复盘核心面板):昨涨停 × 今日行情交叉。短线高频问法直接命中:"昨天涨停今天断板的有哪些"、"昨天连板今天没板的"、"高标(≥3 板)有没有被杀"、"断板后是直接低开退潮还是分歧高开低走"、"昨日连板淘汰率"、"今天市场是退潮还是修复"。返回 summary.breakRate(断板率)、avgBrokenPctChg(平均跌幅)、sentimentSignal=cooling/neutral/warming(直接给出退潮信号)、highBoardBroken(高标杀名单)、statusBreakdown(限跌/深跌/分歧失败/红盘弱续 细分)。focus=broken 默认(只看断板);sealed_again(只看续板成功);all(两者)。minStreak=3 只看高标;theme 按题材过滤。

Input Schema

NameRequiredDescriptionDefault
focusNo视角。broken=只看断板(默认,最常问的复盘视角);sealed_again=只看续板成功的;all=两者都要。broken
limitNo返回最大条数,默认 100,最大 300。
themeNo题材关键词(reason_type / kpl_theme / kpl_lu_desc / jiuyangongshe_category_name 任一字段模糊匹配)。例如 "机器人"、"AI"。
formatNocontent[0].text:默认1行 headline;markdown=完整 markdown 表格;json=完整 JSON。
prevDateNo对比的昨日。不传则自动取 tradeDate 的上一交易日。
minStreakNo昨日至少 N 连板才纳入分析。1=昨日所有涨停(默认);2=2 板以上;3=只看高标(≥3 板)。
tradeDateNo查询的交易日期(今日),支持 YYYY-MM-DD 或 YYYYMMDD。不传则取最近交易日。
detailLevelNo档位:默认 standard(Agent 可计算标准字段);summary=压缩摘要;raw=全字段+原始数据。

Output Schema

NameRequiredDescriptionDefault
dataNo
metaNo
successNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / detailLevel / description
      Previous value: -"输出详细度(不传=standard,返回 Agent 可计算标准字段)。summary=压缩摘要;raw=全字段+原始数据。"New value: +"档位:默认 standard(Agent 可计算标准字段);summary=压缩摘要;raw=全字段+原始数据。"
    • changedInput schema / properties / format / description
      Previous 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。"
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "properties": {
      +    "data": {},
      +    "meta": {},
      +    "success": {}
      +  },
      +  "type": "object"
      +}
  3. First observed

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint/openWorldHint/idempotentHint/destructiveHint=false, so the safety profile is covered and the bar is lower. The description adds semantics for the returned signals (sentimentSignal=cooling/neutral/warming as a 退潮信号) which is useful, but otherwise largely restates field names rather than disclosing new behavioral traits like data freshness or coverage limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Heavily redundant: the panel purpose, the trigger questions, the return fields (breakRate, avgBrokenPctChg, sentimentSignal, highBoardBroken, statusBreakdown) and the focus enum are each stated twice across the two paragraphs. The front-loaded summary is good, but the duplication bloats the definition and dilutes the signal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the return values need not be explained, yet the description still covers inputs, focus/minStreak/theme filters, and the analytical meaning of the results. It is complete for an 8-param optional-input analysis tool; only minor gaps around data scope/freshness remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 8 parameters, making 3 the baseline. The description re-states focus/minStreak/theme usage but adds no format or syntax detail beyond what the schema already explains (e.g. accepted date formats are only in the schema).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific cross-analysis (昨涨停 × 今日行情交叉) and enumerates the exact questions it answers (断板/续板/高标杀/退潮vs修复), plus the output fields it produces. This is far more specific than siblings like broken_limit_up or limit_up_ladder and lets an agent route correctly without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Contains an explicit 何时使用 section with concrete trigger phrasings ('昨天涨停今天断板的有哪些', '高标(≥3板)有没有被杀', '昨日连板淘汰率'), which is strong 'when to use' guidance. However it never states when NOT to use it or names an alternative sibling, so it stops 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.