This TypeScript-based MCP server (zero Python dependencies) provides AI assistants with comprehensive Chinese A-share stock market data from East Money, Sina, and Xueqiu.
Market Data
get_time_info — Current time, timestamp, and latest trading day
get_hist_data — Historical K-line data (minute/hour/day/week/month/year intervals, forward/backward price adjustment, multiple sources) with 34 built-in technical indicators (SMA, EMA, MACD, RSI, BOLL, ATR, CCI, ADX, MFI, etc.)
get_realtime_data — Real-time quotes: price, change %, market cap, PE/PB ratios
Financial Statements
get_balance_sheet — Total assets, fixed assets, cash, inventory, liabilities
get_income_statement — Operating revenue, costs, net profit
get_cash_flow — Operating, investing, and financing cash flows
get_financial_metrics — Key consolidated financial metrics
Shareholder Data
get_top10_shareholders — Top 10 shareholders (name, share count, %, changes)
get_top10_free_shareholders — Top 10 tradable shareholders with type classification (fund, QFII, broker, insurance)
get_fund_holdings — Complete fund holdings (unlimited records, position size, float %, market value)
News & Insider Activity
get_news_data — Stock-related news from East Money
get_inner_trade_data — Insider trading records (director/supervisor/executive buy/sell transactions)
纯 TypeScript 实现的中国 A 股市场数据 MCP 服务器
ahshare-mcp 是一个基于 Model Context Protocol (MCP) 的服务器，为 AI 助手（如 Claude Desktop、VS Code Copilot）提供中国 A 股市场金融数据访问能力。
核心特点：与 Python 版 akshare-one-mcp 功能兼容，但使用 纯 TypeScript 实现，零 Python 依赖。
维度 | Python 版 | TypeScript 版 |
语言 | Python 3.12+ | TypeScript 5.x |
运行时 | CPython | Node.js 22+ |
数据源 | 通过 | 直接调用 HTTP API |
Python 依赖 | ❌ 必需 | ✅ 零依赖 |
技术指标 | pandas 计算 | 纯 TS 数学实现 |
部署 | Python + pip/uv | 单 Node.js 进程 |
镜像大小 | ~500MB | ~150MB |
MCP 工具数 | 9 | 12（含股东/基金持股） |
Related MCP server: sfc-data-mcp
历史 K 线 — 日/周/月/分钟级，支持前/后复权，多数据源
实时行情 — 最新价、涨跌幅、市值、PE/PB
34 种技术指标 — SMA/EMA/MACD/RSI/BOLL/ATR/CCI/ADX/MFI 等
资产负债表 — 总资产、固定资产、货币资金、存货、负债
利润表 — 营业收入、营业成本、营业利润、净利润
现金流量表 — 经营/投资/筹资现金流
财务指标 — 三表合并关键指标
十大股东 — 排名、持股数、持股比例、变动详情
十大流通股东 — 类型分类（基金/QFII/券商/保险）
基金持股 — 全量（不限于前10），1000+ 条记录
个股新闻 — 东方财富新闻搜索
内部交易 — 董监高增/减持记录
时间信息 — 当前时间 + 最近交易日
npm install -g ahshare-mcpgit clone https://github.com/terrysun1216/ahshare-mcp-ts.git
cd ahshare-mcp-ts
npm install
npm run build在 Claude Desktop 配置文件中添加：
{
"mcpServers": {
"ahshare-mcp": {
"command": "npx",
"args": ["ahshare-mcp"]
}
}
}或在 VS Code Copilot 中：
{
"mcpServers": {
"ahshare-mcp": {
"command": "npx",
"args": ["tsx", "/path/to/ahshare-mcp-ts/src/main.ts"]
}
}
}# stdio 模式（默认，供 MCP 客户端使用）
ahshare-mcp
# HTTP 模式（供远程/Web 客户端使用）
ahshare-mcp --streamable-http --port 8081配置后，在 Claude 中可以这样对话：
"帮我查看贵州茅台 600519 最近 30 天的日线走势和 MACD 指标"
"贵州茅台最新的十大股东是谁？持股市值多少？"
"对比一下 600519 和 000858 的 PE、ROE 等财务指标"
"有哪些基金重仓持有了贵州茅台？"
# | 工具名 | 描述 | 数据源 |
1 |
| 当前时间、时间戳、最近交易日 | 新浪 |
2 |
| 历史 K 线数据 + 34种技术指标 | 东方财富/新浪 |
3 |
| 实时行情（价格/涨跌/市值/PE/PB） | 东方财富 |
4 |
| 个股新闻 | 东方财富 |
5 |
| 资产负债表 | 东方财富 |
6 |
| 利润表 | 东方财富 |
7 |
| 现金流量表 | 东方财富 |
8 |
| 三大报表合并关键指标 | 东方财富 |
9 |
| 董监高内部交易 | 雪球 |
10 |
| 十大股东 + 十大流通股东 | 东方财富 F10 |
11 |
| 十大流通股东明细 | 东方财富 F10 |
12 |
| 基金持股明细（全量） | 新浪财经 |
类别 | 指标 |
趋势 | SMA, EMA, MACD, APO, PPO, TRIX, ULTOSC |
动量 | RSI, CCI, ADX, DX, MFI, MOM, CMO, WILLR |
波动率 | BOLL, ATR, SAR |
成交量 | OBV, AD, ADOSC |
方向 | PLUS_DI, PLUS_DM, MINUS_DI, MINUS_DM |
变化率 | ROC, ROCP, ROCR, ROCR100 |
其他 | AROON, AROONOSC, BOP, STOCH, TSF |
┌─────────────────────────┐
│ MCP Client │
│ (Claude Desktop / VS Code) │
└──────┬──────────────────┘
│ JSON-RPC (stdio / HTTP)
┌──────┴──────────────────┐
│ MCP Server Layer │
│ @modelcontextprotocol/ │
│ sdk + Hono + Zod │
├──────────────────────────┤
│ Service Layer │
│ 行情 / 财务 / 股东 / 新闻 │
├──────────────────────────┤
┌──────────┼──────────┬──────────────┤
│ │ │ │
┌────┴───┐ ┌───┴────┐ ┌───┴───┐ ┌───────┴──┐
│东方财富 │ │ 新浪 │ │ 雪球 │ │ 指标引擎 │
│ HTTP │ │ HTTP │ │ HTTP │ │ 34 函数 │
└────────┘ └────────┘ └───────┘ └──────────┘数据流向：MCP Client → JSON-RPC → MCP Server → Service → HTTP Provider → 东方财富/新浪/雪球公开 API
零 Python 依赖：直接从 TypeScript 调用各数据源的公开 HTTP 接口，使用 Node.js 内置 fetch API。
包 | 版本 | 用途 |
| ^1.29 | MCP 协议实现 |
| ^4.12 | HTTP 框架 |
| ^4.4 | 参数校验 + 类型推导 |
| ^5.9 | 类型系统 |
| ^4.1 | 测试框架 |
仅 3 个生产依赖，与 Lyna 项目使用完全相同的技术栈。
# 安装依赖
npm install
# 开发运行（stdio 模式）
npm run dev
# 开发运行（HTTP 模式）
npm run dev:http
# 运行测试
npm test
# 编译
npm run buildsrc/
├── main.ts # CLI 入口
├── config.ts # 全局配置
├── calendar.ts # 交易日历
├── server/ # MCP Server (stdio + HTTP)
├── tools/ # 12 个 MCP 工具定义
├── services/ # 业务逻辑层
├── providers/ # HTTP API 层（东方财富/新浪/雪球/F10）
├── indicators/ # 34 个技术指标纯函数
└── types/ # Zod Schema + TS 类型全部 13 个 E2E 测试通过，使用真实数据验证：
npm test # 单元测试
npx tsx tests/e2e-all-tools.test.ts # 端到端测试MIT © Terry
AKShare — 底层数据源研究和参考
akshare-one-mcp — Python 版 MCP 参考实现
Lyna — TypeScript MCP 架构参考
Get company balance sheet data.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock symbol/ticker (e.g. '000001') | |
| recent_n | No | Number of most recent records to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose what data is returned (e.g., periods covered, whether it includes all historical data), potential limitations, or any behavioral traits beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence), but it is too brief and lacks necessary context. While it is not verbose, the brevity sacrifices informative value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, no output schema, many sibling tools, and no annotations, the description is insufficient. It does not explain what the balance sheet includes, how to interpret the data, or any response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds no additional meaning beyond what the schema provides, but since schema is complete, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'balance sheet data', which distinguishes it from sibling tools like 'get_cash_flow' or 'get_income_statement'. However, it could be more specific about the scope (e.g., company by symbol).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., for quarterly data vs. annual data). The description does not mention any context that would help an agent decide between sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get company cash flow statement data.
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | Data source | sina |
| symbol | Yes | Stock symbol/ticker (e.g. '000001') | |
| recent_n | No | Number of most recent records to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does not disclose behavioral traits such as return format, data frequency, period ranges, or any limitations. The agent has no insight into what the tool does beyond fetching cash flow data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks useful detail. While not verbose, it is under-specified for a financial data tool with multiple parameters and siblings.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of financial data (three parameters, no output schema, no annotations), the description is incomplete. It does not explain what the returned data contains, how parameters interact, or any caveats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters (symbol, source, recent_n). The description adds no additional meaning beyond what the schema already provides, so it meets the baseline for a well-documented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get company cash flow statement data' uses a specific verb 'Get' and resource 'cash flow statement data', clearly distinguishing it from sibling tools like 'get_balance_sheet' and 'get_income_statement'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions, making it hard for an agent to choose appropriately among financial data tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get key financial metrics from the three major financial statements.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock symbol/ticker (e.g. '000001') | |
| recent_n | No | Number of most recent records to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It lacks disclosure of behavioral traits such as data aggregation, recency, or format. The mention of 'three major financial statements' hints at scope but is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is concise but lacks structure. It could benefit from additional detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is incomplete. It does not specify which metrics are returned, the data range, or how it differs from sibling tools like get_income_statement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add extra meaning beyond schema; it merely repeats 'financial metrics' without clarifying parameter usage or output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'key financial metrics from the three major financial statements,' conveying purpose. However, it does not differentiate from siblings like get_balance_sheet or get_income_statement, slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings (e.g., get_balance_sheet for detailed statement data) or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取股票基金持股明细（全量，不限前10）。返回所有持有该股票的基金名称、代码、持仓数量、占流通股比例、持股市值
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock symbol/ticker (e.g. '600519') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool returns specific fields (fund names, codes, quantities, etc.) and implies it is a read operation. Lacks information on authentication or rate limits, but for a simple query tool, this is reasonable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded with the core action and key distinguishing feature. Every word serves a purpose, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple structure (1 param, no output schema), description adequately explains what is returned and the scope. Could mention potential large result sets or lack of pagination, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with description of symbol already in schema. Description does not add significant extra meaning beyond what schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly specifies verb '获取' and resource '股票基金持股明细', and explicitly distinguishes itself from siblings like get_top10_shareholders by noting '全量，不限前10' (full amount, not limited to top 10).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context that this tool returns all holdings, not just top 10, implying when to use it over sibling tools that return top 10 shareholders. However, it does not explicitly mention when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get historical stock market data. 'eastmoney_direct' support all A,B,H shares
| Name | Required | Description | Default |
|---|---|---|---|
| adjust | No | Adjustment type | none |
| source | No | Data source | eastmoney |
| symbol | Yes | Stock symbol/ticker (e.g. '000001') | |
| end_date | No | End date in YYYY-MM-DD format | 2030-12-31 |
| interval | No | Time interval | day |
| recent_n | No | Number of most recent records to return | |
| start_date | No | Start date in YYYY-MM-DD format | 1970-01-01 |
| indicators_list | No | Technical indicators to add | |
| interval_multiplier | No | Interval multiplier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only status, rate limits, data freshness, or possible limitations. For a tool with no annotations, the description should compensate but fails to do so.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that effectively communicates the core action and a key capability. It is front-loaded and efficient, though more structure (e.g., bullet points) could improve readability for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, 1 required, and no output schema, the description is minimal. It does not explain return format, pagination, or data limitations. For a tool of this complexity, completeness is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already documented. The description adds only minor value by mentioning data source support for specific share types. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves historical stock market data and specifies support for A, B, H shares with 'eastmoney_direct'. It is distinguishable from sibling tools like get_realtime_data by focusing on historical data, though it could be more explicit about the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_realtime_data or get_financial_metrics. The description does not mention prerequisites, suitable scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get company income statement data.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock symbol/ticker (e.g. '000001') | |
| recent_n | No | Number of most recent records to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states a basic read action without disclosing any behavioral traits like data scope, pagination, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the key action and resource, with no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of income statement data and the lack of output schema or annotations, the description is insufficient; it does not explain return fields, time periods, or data format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and adequately describes both parameters (symbol and recent_n). The tool description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and resource 'income statement data', clearly distinguishing it from sibling tools like get_balance_sheet and get_cash_flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get company insider trading data.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock symbol/ticker (e.g. '000001') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only says 'Get... data' implying a read operation, but lacks details on behavior (e.g., data freshness, rate limits, pagination).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence is concise but lacks structure; no front-loading of key info. Could be improved with additional context while remaining brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description is too minimal. It does not explain what the returned data looks like or any usage constraints, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter with description). Description adds no extra meaning beyond the schema's stock symbol explanation. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it gets insider trading data, which is clear but vague. It doesn't specify the type of insider data (transactions, holdings, etc.) or differentiate from siblings like get_fund_holdings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like get_fund_holdings or get_hist_data. No context on prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get stock-related news data.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock symbol/ticker (e.g. '000001') | |
| recent_n | No | Number of most recent records to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention whether the tool is read-only, rate limits, or what happens if no news is found. The description only states the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence. For a simple tool, this is efficient. However, it could be slightly expanded to improve clarity without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain the structure or content of the returned data (e.g., list of news articles with fields). It does not, leaving the AI agent without sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters have descriptions in the input schema (100% coverage). The description adds no additional meaning beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets news data related to stocks. It distinguishes from siblings by the resource type (news vs financial metrics). However, it could be more specific (e.g., 'get recent news articles for a stock symbol').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., get_realtime_data provides real-time prices). The description does not indicate prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get real-time stock market data. 'eastmoney_direct' support all A,B,H shares
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | Data source | eastmoney_direct |
| symbol | No | Stock symbol/ticker (e.g. '000001') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions market support. It lacks disclosure of rate limits, error behavior, or confirmation that the operation is read-only, which is critical for a data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the core purpose first, followed by a specific detail. No redundant information, every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should at least hint at what data fields are returned. It covers source selection adequately but omits return structure, which is a gap for an otherwise simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so the baseline is 3. The description adds minor value by clarifying that 'eastmoney_direct' supports all share types, but does not elaborate on parameter formats or usage beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves real-time stock market data, and specifies that 'eastmoney_direct' supports all A, B, H shares, distinguishing it from sibling tools that return historical data or financial statements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for real-time data retrieval, and hints at source selection for broader market coverage, but provides no explicit guidance on when to use this tool vs. siblings or excludes alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current time with ISO format, timestamp, and the last trading day.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. The description states it 'gets' time and trading-day info, implying a read-only operation, but it does not disclose timezone specifics, the meaning of 'last trading day,' or any potential dependencies. This is acceptable for a trivial tool but lacks richer context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes meaning, and the structure is clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters, no output schema, and no annotations. The description lists the expected return values (ISO time, timestamp, last trading day), which is mostly complete, but it omits details like timezone or trading calendar context that could affect interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so per the rubric the baseline is 4. The description adds no parameter-specific detail, but none is needed since the input schema is empty and there is nothing to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'get' with a clear resource ('current time') and explicitly lists the outputs: ISO format, timestamp, and last trading day. This distinguishes it from the many financial sibling tools, which focus on market data rather than time information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the tool's context: use it when you need current time formatted as ISO, a timestamp, or the last trading day. It does not explicitly exclude alternatives or provide when-not-to-use guidance, but the zero-parameter nature and simple purpose make the intended usage evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0get_balance_sheetget_cash_flowget_financial_metricsget_fund_holdingsget_hist_dataget_income_statementget_inner_trade_dataget_news_dataget_realtime_dataget_time_infoget_top10_free_shareholdersget_top10_shareholdersScored across 12 tools
Each tool targets a specific type of financial or market data with clear distinctions: financial statements (balance sheet, cash flow, income, metrics), market data (historical vs real-time), ownership (fund holdings, top10 shareholders, top10 free shareholders), insider trades, news, and time info. No two tools have overlapping purposes.
All tool names follow a consistent 'get_<descriptive_noun>' pattern using snake_case. The naming is uniform and predictable, making it easy for agents and users to understand the action and data type each tool provides.
With 12 tools, the server covers core functionalities for stock market data retrieval (financials, prices, ownership, news, utilities) without being overly expansive or too sparse. The count is well-suited for a focused financial data assistant.
The tool surface covers major areas: financial statements, market prices (historical & real-time), holdings, insider trades, and news. However, it lacks tools for company profiles, dividend data, or index data, which are minor gaps for a comprehensive stock analysis toolkit.
China A-share market data for research, backtesting and AI agents via MCP.
Provide access to Chinese stock market data including historical prices, real-time data, news, and…
MCP server giving AI agents one-connection access to China A-share market intelligence: financials,
Access real-time and historical market data for China A-shares and Hong Kong stocks, along with ne…