Skip to main content
Glama

Wudao A-Share Stock Data MCP

market_overview

Read-onlyIdempotent

实时全市场涨跌家数、市场温度计等大盘宽度数据;涨跌停/炸板口径请使用 limit_stats 何时使用: 实时全市场涨跌家数、市场温度计等大盘宽度(开盘啦)。不传日期时,交易日默认今日,非交易日按交易日历自动取上一交易日并标注 fallback;交易日开市前若尚未就绪返回 MARKET_SUMMARY_NOT_READY,不冒充昨收。涨跌停/炸板口径请用 limit_stats。

Input Schema

NameRequiredDescriptionDefault
dateNo可选。交易日期,格式 YYYY-MM-DD;不传时交易日默认今日,非交易日按交易日历自动取上一交易日并标注 fallback。交易日盘前今日数据未就绪时明确报错,不冒充昨日。
formatNocontent[0].text:默认1行 headline;markdown=完整 markdown 表格;json=完整 JSON。
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.8/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds genuinely useful behavior beyond that: non-trading-day fallback to the previous trading day with a 'fallback' marker, and a specific MARKET_SUMMARY_NOT_READY error instead of silently returning stale prior-close figures.

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?

The data scope is front-loaded, but the limit_stats routing instruction is duplicated verbatim (it appears in the opening clause and again at the end), and the fallback behavior is restated in both description and schema. Tightening would remove a full sentence with no loss of meaning.

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 and annotations covering the safety profile, the description only needs to cover selection and edge behavior, which it does (when-to-use, sibling routing, date fallback, not-ready error). Minor gap: it never clarifies how this differs from other market-level siblings such as index_market or short_term_emotion.

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 date, format, and detailLevel, including the same fallback wording the description repeats. The description adds no new parameter semantics (format and detailLevel are untouched), so this is the baseline 3.

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?

The description names a specific resource set — real-time whole-market advancing/declining counts and market thermometer (breadth data) — and explicitly routes limit-up/limit-down/board-break definitions to the sibling limit_stats, so an agent can separate it from limit_stats or index_market. It lacks an explicit verb, but the resource scope is concrete enough to be unambiguous.

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?

There is an explicit '何时使用' (when to use) clause and an explicit alternative for a confusingly adjacent sibling ('涨跌停/炸板口径请用 limit_stats'). However the alternative is stated twice and there is no statement of when NOT to use or of other overlapping siblings (index_market, short_term_emotion), so it falls short of a full when/when-not/alternatives treatment.

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.