Skip to main content
Glama

Wudao A-Share Stock Data MCP

etf_market

Read-onlyIdempotent

查询 ETF 搜索、实时快照、涨幅/成交额排行、日线和分钟线。ETF 是独立资产,不要把 ETF 条件查询改用 stock_screener。 何时使用: ETF 行情工具:查 ETF 搜索、实时快照、涨幅/成交额排行、日线和分钟线。不要把 ETF 塞进 stock_screener。

Input Schema

NameRequiredDescriptionDefault
codeNo可选。单个ETF代码;等价于 symbols 单元素。
modeNo查询模式,默认 snapshot。search=搜索ETF;snapshot=实时快照;rank=排行;daily=日线;minute=分钟线。snapshot
limitNo返回数量,snapshot 默认 30,rank 默认 50;日线/分钟默认返回尾部窗口。
orderNo排序方向,默认 desc。desc
formatNocontent[0].text:默认1行 headline;markdown=完整 markdown 表格;json=完整 JSON。
periodNominute 模式周期,默认 1m。1m
sortByNorank/snapshot 排序字段,默认 pctChg;可选 pctChg/amount/close/vol。pctChg
endDateNo可选。daily 模式结束日期,支持 YYYY-MM-DD 或 YYYYMMDD。
keywordNo可选。名称/代码/分类关键词。search 模式按关键词搜索;snapshot/rank 模式用于过滤。
symbolsNo可选。ETF代码,数组或逗号分隔字符串。daily/minute 模式建议显式传入。
startDateNo可选。daily 模式起始日期,支持 YYYY-MM-DD 或 YYYYMMDD。
tradeDateNo可选。交易日期,支持 YYYY-MM-DD 或 YYYYMMDD;daily/minute 模式可指定日期。
detailLevelNo档位:默认 standard(Agent 可计算标准字段);summary=压缩摘要;raw=全字段+原始数据。
forceRefreshNo调试用。true 时绕过共享结果缓存;指数实时模式仍只读取最新落盘快照,不会由用户请求触发现场刷新。

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.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered without the description. The description adds only the domain fact that ETFs are an independent asset class; it discloses nothing about caching, rate limits, or freshness behavior (that detail lives in the forceRefresh param description instead).

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?

Front-loading is good, but the description duplicates itself: the list of query modes appears twice, and the 'don't put ETFs in stock_screener' warning is repeated twice with different wording. That redundancy costs space without adding information.

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?

For a 14-parameter, zero-required multiplexer with an output schema and full schema coverage, the description only needs to convey scope and routing, which it does. The mode-to-parameter interactions (e.g. startDate/endDate only matter in daily) are left entirely to the schema, which is acceptable here.

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% and every parameter is self-documented, so the baseline is 3. The description restates the mode list that the mode enum already documents and adds no syntax, default, or interaction detail beyond the schema.

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

Purpose4/5

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

It names a specific verb and resource (query ETF search, real-time snapshot, gain/turnover rankings, daily and minute bars) and explicitly carves the ETF asset class out from stock_screener, which is the main source of ambiguity among siblings. However, it does not distinguish itself from other bar-data siblings such as kline, minute_data, or index_market, and the same mode list is restated verbatim later in the text.

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?

The '何时使用' block gives an explicit use condition and an exclusion — don't route ETF conditional queries to stock_screener — which is exactly the routing decision an agent faces here. It stops short of saying when to prefer this over kline/minute_data or index_market for the overlapping time-series modes.

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.