A股数据 API (A-Share Data API)

ashare_etf

ETF 数据。用户问'ETF'时用这个。kind 选子集：概览(默认·行情/规模/溢折率/资金流/回撤/估值) · 详情(基金要素/费率/份额/基金经理/持仓Top20) · 持仓(成分股及权重) · 净值(历史净值，须同时传 start+end) · 公司(管理人/托管人/跟踪指数) · 持有人(户数/机构个人占比) · 财务(股债商品基金占比)。⚠️ 返回的 data 是排版文本，取字段用 structured（首表）或 tables（全部表） —— 详情/公司 是多表，只有 tables 拿全。⚠️ 查历史快照：kind=概览/持仓 + date=YYYY-MM-DD。传了 date 与不传返回形态可能不同（持仓：传 date＝重仓股涨跌 + 申赎清单前 10 两段、code 带市场前缀；不传＝单表 Top20 持仓、code 为裸 6 位）⇒ 按段名/列名取，⛔ 别按位置取。⚠️ 历史快照两个数据源边界：未来日期按最近交易日返回（看 date 列自证）；上市前日期回全 0（会被拦成 ok:false）。⚠️ 要『全市场有哪些 ETF / 规模排行 / 主题池（千亿·百亿·金牛奖·科创占比高…）』不在这里 —— 用 ashare_screen(asset='etf')：mode=ranking 有 9 类横截面指标（规模/估值/历史百分位/单日/区间涨跌/换手/成交额/溢折率），mode=label 有 48 个 ETF 主题池；list=true 先列合法取值。⚠️ 仅 ETF 代码：传个股代码返回 ok:false（不扣次数）。⚠️ code 单次只查 1 只：传逗号会 422（本端点没有批量价）；多只请分别调用，每只独立计次。只读查询；代码形如 sh510300 或裸 6 位 510300。

Input Schema

Name	Required	Description	Default
`end`	No	仅 kind=净值：结束日 YYYY-MM-DD
`code`	Yes	ETF 代码：sh510300
`date`	No	仅 kind=概览/持仓：历史快照日 YYYY-MM-DD（留空=最新）
`kind`	No	概览(默认)/详情/持仓/净值/公司/持有人/财务	概览
`start`	No	仅 kind=净值：起始日 YYYY-MM-DD

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 23, 2026

changedInput schema / properties / date / description

Previous value: -"仅 kind=持仓：查询日 YYYY-MM-DD（查历史持仓；留空=最新）"New value: +"仅 kind=概览/持仓：历史快照日 YYYY-MM-DD（留空=最新）"

Changed1 schema field changedOct 23, 2026

addedInput schema / properties / date

Added value: +{
+  "default": "",
+  "description": "仅 kind=持仓：查询日 YYYY-MM-DD（查历史持仓；留空=最新）",
+  "title": "Date",
+  "type": "string"
+}

Changed3 schema fields changedOct 17, 2026

addedInput schema / properties / end

Added value: +{
+  "default": "",
+  "description": "仅 kind=净值：结束日 YYYY-MM-DD",
+  "title": "End",
+  "type": "string"
+}

addedInput schema / properties / kind

Added value: +{
+  "default": "概览",
+  "description": "概览(默认)/详情/持仓/净值/公司/持有人/财务",
+  "title": "Kind",
+  "type": "string"
+}

addedInput schema / properties / start

Added value: +{
+  "default": "",
+  "description": "仅 kind=净值：起始日 YYYY-MM-DD",
+  "title": "Start",
+  "type": "string"
+}

Changed1 schema field changedSep 23, 2026
- addedInput schema / properties / code / description
```
Added value: +"ETF 代码：sh510300"
```
First observedSep 21, 2026

TDQS

A4.9/5.0

Behavior5/5

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

No annotations are provided, so the description carries the full burden and does so: read-only, no quota deduction on invalid codes, 422 on multi-code, historical-snapshot edge cases (future date → latest trading day, pre-listing → all zeros with ok:false), and return-shape differences when `date` is passed. This is behavior an agent cannot infer from any structured field.

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

Conciseness4/5

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

Front-loaded with purpose and the kind menu before the warnings, and every warning carries operational weight. It is dense and warning-heavy with emoji markers, which slightly reduces scanability, but there is little genuinely dead text.

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?

An output schema exists so return values need not be described, yet the description usefully explains the data/structured/tables split and that 详情/公司 are multi-table — exactly the gap the output schema alone leaves for multi-table responses. Complete for a 5-param, single-required tool.

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

Parameters5/5

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

Schema coverage is already 100%, but the description still adds material meaning: it explains what each `kind` yields, that `kind=净值` requires both start+end, and that passing `date` changes both the shape and code format (market prefix vs bare 6-digit) for 持仓. It tells the agent how to read the result, not just what the field is.

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 resource (ETF 数据) and enumerates the exact subset dimension via `kind` (概览/详情/持仓/净值/公司/持有人/财务). It explicitly differentiates from the sibling ashare_screen, so an agent can route without opening either schema.

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?

Gives explicit triggers ('用户问 ETF 时用这个'), the alternative for cross-sectional ETF queries (ashare_screen with mode=ranking/label, list=true), and hard exclusions (single stock code → ok:false, comma codes → 422, must call per-code). Covers when-not as well as when.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All A股数据 API (A-Share Data API) tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?