Skip to main content
Glama

Wudao A-Share Stock Data MCP

auction_market_scan

Read-onlyIdempotent

全市场按集合竞价金额、涨停委买、封单、涨幅、量比等排序过滤。昨涨停/昨炸板今表现请用 auction_opening_snapshot;题材聚合用 auction_theme_strength。snapshotTime 支持 09:15/09:20/09:25,默认 09:25。 何时使用: 竞价主扫描器:按强度/成交额/涨停委买/尾秒竞价涨幅/封单等排序过滤。昨涨停与昨炸板反馈用 auction_opening_snapshot;题材线用 auction_theme_strength。未传日期且今天非交易日时按交易日历查询上一交易日并标注实际日期;支持 snapshotTime=09:15/09:20/09:25,默认 09:25;早期截面附实际时间和覆盖提示,禁止把虚拟撮合额当最终成交额。

Input Schema

NameRequiredDescriptionDefault
poolNo额外票池过滤。limit_up_prev=只看昨涨停;non_limit_up_prev=剔除昨涨停;broken_limit_up_prev=只看昨真炸板池。昨涨停/昨炸板今表现请用 auction_opening_snapshot。all
codesNo可选。自定义票池(最多 100 只)。常见用法:先调用 dragon_tiger / limit_up_filter 拿到票池,再传给本工具看竞价反馈。
limitNo返回 top N,默认 30,最大 100。
orderNo排序方向,默认 desc。asc 用于扫低开/萎缩。desc
formatNocontent[0].text:standard/raw 默认 JSON 明细;summary 默认1行 headline;markdown=完整 markdown 表格;json=完整 JSON。
marketNo市场范围,默认 all。all
presetNo一键预设场景;与 filters 同时传时 filters 优先级更高。hot_open=高开放量;low_open_heavy=低开放量(取自昨涨停池);percentile_breakout=竞价额历史分位 ≥90 突破。昨涨停/昨炸板今表现请用 auction_opening_snapshot。
sortByNo排序字段,默认 bidStrength(市值归一化竞价强度,跨市值对比首选)。常用:limitBuyAmount=9:25 涨停委买额终值,用于"竞价委买/涨停委买排行";openBidPct=9:25 开盘价相对 09:24 最后一笔有效竞价价格的尾秒涨跌幅;limitBuyAmountAfter920=9:20 后涨停委买额;finalSealAmount=最近落库封单截面,用于"封单排行"。其他:bidAmount(竞价成交额)/ limitBuyStrength(涨停委买强度)/ bidVol(竞价量,股)/ changeRate(竞价涨幅)/ volumeRatio(量比)/ turnoverRate(普通竞价换手)/ bidAmountPercentile(历史分位)/ auctionNetAmount(竞价净额)。bidStrength
excludeSTNo剔除 ST/退市股,默认 true。
tradeDateNo交易日期,支持 YYYY-MM-DD 或 YYYYMMDD。不传时:交易日取今日(所选时点尚未就绪返回 AUCTION_DATA_NOT_READY);非交易日按交易日历取上一交易日并标注实际日期。显式日期不自动换日。
detailLevelNo档位:默认 standard(Agent 可计算标准字段);summary=压缩摘要;raw=全字段+原始数据。
minBidAmountNo竞价额下限(元),默认 500 万。异动场景建议拉到 1000 万 (1e7)。
snapshotTimeNo竞价截面时点,默认 09:25。09:15/09:20 复用工作台留存行情和涨停价买单;实际秒数、覆盖范围见 dataTiming。早期竞价额为虚拟撮合金额;不返回后续定盘字段。09:20 带相对 09:15 买单变化,显式 09:25 带三时点买单对比。
maxChangeRateNo竞价涨幅上限(%)。
maxOpenBidPctNo尾秒竞价涨幅上限(%);筛尾秒撤退可设 -0.5。
minChangeRateNo竞价涨幅下限(%)。
minOpenBidPctNo尾秒竞价涨幅下限(%);09:25 开盘价相对 09:24 最后一笔有效竞价价格。筛尾秒抢筹可设 0.5。
minPercentileNo竞价额历史分位下限(0-100)。需 sortBy=bidAmountPercentile 或 preset=percentile_breakout 自动启用。
recent60dHighNo是否要求"非近 60 日高点"。默认不限制。
minBidStrengthNo归一化竞价强度下限(‱,万分之)。
minVolumeRatioNo量比下限。
recent20dGainMaxNo近 20 日累计涨幅上限(%)。低位首板候选场景建议 ≤15。
minLimitBuyAmountNo9:25 涨停委买额终值下限(元),用于筛选竞价定盘后涨停价位委买资金。
excludePrevLimitUpNo剔除昨日涨停股,找"新异动"场景常用。默认 false。
minFinalSealAmountNo最近落库封单截面下限(元),用于筛选封单较大的涨停股票;该字段不保证等同当前实时封单。
minAuctionNetAmountNo竞价净额下限(元)。
minLimitBuyAmountAfter920No09:20 后涨停委买额下限(元),用于筛选撤单限制阶段仍有涨停价位委买资金的股票。

Output Schema

NameRequiredDescriptionDefault
dataNo
metaNo
successNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / snapshotTime
      Added value: +{
      +  "description": "竞价截面时点,默认 09:25。09:15/09:20 复用工作台留存行情和涨停价买单;实际秒数、覆盖范围见 dataTiming。早期竞价额为虚拟撮合金额;不返回后续定盘字段。09:20 带相对 09:15 买单变化,显式 09:25 带三时点买单对比。",
      +  "enum": [
      +    "09:15",
      +    "09:20",
      +    "09:25"
      +  ],
      +  "type": "string"
      +}
    • changedInput schema / properties / tradeDate / description
      Previous value: -"交易日期,支持 YYYY-MM-DD 或 YYYYMMDD。不传时:交易日取今日(9:25 前返回 AUCTION_DATA_NOT_READY);非交易日按交易日历取上一交易日并标注实际日期。显式日期不自动换日。"New value: +"交易日期,支持 YYYY-MM-DD 或 YYYYMMDD。不传时:交易日取今日(所选时点尚未就绪返回 AUCTION_DATA_NOT_READY);非交易日按交易日历取上一交易日并标注实际日期。显式日期不自动换日。"
  2. 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:standard/raw 默认 JSON 明细;summary 默认1行 headline;markdown=完整 markdown 表格;json=完整 JSON。"
  3. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "properties": {
      +    "data": {},
      +    "meta": {},
      +    "success": {}
      +  },
      +  "type": "object"
      +}
  4. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly/idempotent/non-destructive/openWorld), yet the description adds substantive behavior: non-trading-day fallback via the trading calendar with the actual date annotated, early-snapshot caveats (virtual matching amount must not be treated as final, coverage/time noted in dataTiming), and the AUCTION_DATA_NOT_READY state. These are non-obvious traits beyond structured fields.

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

Conciseness3/5

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

Content is dense and mostly front-loaded, but the sibling routing ('昨涨停/昨炸板今表现请用 auction_opening_snapshot') and the snapshotTime 09:15/09:20/09:25 default are each stated twice, making the description noticeably redundant.

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

Completeness5/5

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

With 27 zero-required params at full schema coverage and an output schema present, the description only needs to cover routing, edge cases, and timing semantics, all of which it does. An agent has everything required to invoke it correctly, including non-trading-day and early-snapshot handling.

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 carries per-parameter meaning and the baseline is 3. The description restates the snapshotTime enum/default and adds the 'virtual matching amount' caveat, but contributes little parameter meaning beyond what the rich schema already documents.

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?

States a specific verb and resource: full-market auction scanning sorted/filtered by auction amount, limit-up buy orders, seal amount, change and volume ratio. It explicitly names the sibling tools it is not (auction_opening_snapshot, auction_theme_strength), so an agent can disambiguate without opening schemas.

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

Usage Guidelines5/5

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

The 何时使用 block declares the tool's role as the primary auction scanner and routes two adjacent use cases to named alternatives ('昨涨停/昨炸板今表现请用 auction_opening_snapshot;题材聚合用 auction_theme_strength'). When-to-use, when-not, and alternatives are all explicit.

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.