Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@FinanceMCP-DCTHS Check today's performance for the humanoid robot sector on East Money"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
基于 MCP 协议的金融数据服务器，集成 Tushare API，支持东财和同花顺数据源
同花顺板块指数列表 (get_ths_index)
获取同花顺概念和行业指数列表
支持按指数代码、市场类型、指数类型查询
同花顺板块行情 (get_ths_daily)
获取同花顺板块指数行情数据
包含开盘价、收盘价、涨跌幅、成交量等
同花顺板块成分 (get_ths_member)
获取同花顺概念板块成分股
可查询板块包含的股票或股票所属板块
东财板块信息 (get_dc_index)
获取东财概念板块每日数据
包含领涨股、总市值、涨跌幅等信息
东财板块成分 (get_dc_member)
获取东财板块成分股数据
支持历史成分查询
东财板块行情 (get_dc_daily)
获取东财板块行情数据
支持概念板块、行业板块、地域板块
特性 | stdio 模式 | HTTP 模式 |
适用场景 | 本地使用 | 服务器部署 |
启动方式 |
|
|
Token 配置 | 环境变量 | 环境变量 + HTTP Header |
推荐用途 | 个人使用、快速测试 | 生产部署、多用户 |
Related MCP server: tushare-mcp-http
无需安装，直接使用 npx：
npx -y financemcp-dcths# 克隆仓库
git clone https://github.com/guangxiangdebizi/FinanceMCP-DCTHS.git
cd FinanceMCP-DCTHS
# 安装依赖
npm install复制环境变量模板：
cp .env.example .env编辑 .env 文件，填入你的 Tushare Token：
TUSHARE_TOKEN=你的tushare_token获取 Token：访问 Tushare 官网 注册并获取免费 Token
npm run buildnpm run start:stdio或通过 npx 直接运行：
npx -y financemcp-dcthsnpm run start:http服务器将在 http://localhost:3000 启动
在 Claude Desktop 配置文件中添加：
位置：
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
配置内容：
{
"mcpServers": {
"financemcp-dcths": {
"command": "npx",
"args": ["-y", "financemcp-dcths"],
"env": {
"TUSHARE_TOKEN": "你的tushare_token"
}
}
}
}{
"mcpServers": {
"financemcp-dcths": {
"type": "streamableHttp",
"url": "http://localhost:3000/mcp",
"timeout": 600,
"headers": {
"X-Tushare-Token": "你的tushare_token"
}
}
}
}HTTP 模式支持三种 Token 传递方式：
✅ X-Tushare-Token 请求头（推荐）
✅ X-Api-Key 请求头
✅ Authorization: Bearer <token> 请求头
在 Claude 中输入：
查询所有同花顺概念指数对应的 MCP 调用：
{
"name": "get_ths_index",
"arguments": {
"type": "N"
}
}在 Claude 中输入：
查询东财人形机器人板块今天的数据对应的 MCP 调用：
{
"name": "get_dc_index",
"arguments": {
"name": "人形机器人",
"trade_date": "20231201"
}
}在 Claude 中输入：
查询同花顺人工智能板块最近一周的行情对应的 MCP 调用：
{
"name": "get_ths_daily",
"arguments": {
"ts_code": "885823.TI",
"start_date": "20231201",
"end_date": "20231207"
}
}在 Claude 中输入：
查询东财新能源汽车板块包含哪些股票对应的 MCP 调用：
{
"name": "get_dc_member",
"arguments": {
"ts_code": "BK0001.DC",
"trade_date": "20231201"
}
}参数 | 类型 | 必填 | 说明 |
| string | ❌ | 指数代码（如 885823.TI） |
| string | ❌ | 市场类型：A-A股 HK-港股 US-美股 |
| string | ❌ | 指数类型：N-概念指数 I-行业指数 R-地域指数 等 |
参数 | 类型 | 必填 | 说明 |
| string | ❌ | 指数代码（如 885823.TI） |
| string | ❌ | 交易日期（YYYYMMDD） |
| string | ❌ | 开始日期 |
| string | ❌ | 结束日期 |
参数 | 类型 | 必填 | 说明 |
| string | ❌ | 板块指数代码（查询该板块的成分股） |
| string | ❌ | 股票代码（查询该股票所属板块） |
参数 | 类型 | 必填 | 说明 |
| string | ❌ | 指数代码（支持多个，逗号分隔） |
| string | ❌ | 板块名称（如：人形机器人） |
| string | ❌ | 交易日期（YYYYMMDD） |
| string | ❌ | 开始日期 |
| string | ❌ | 结束日期 |
参数 | 类型 | 必填 | 说明 |
| string | ❌ | 板块指数代码 |
| string | ❌ | 成分股票代码 |
| string | ❌ | 交易日期（支持历史查询） |
参数 | 类型 | 必填 | 说明 |
| string | ❌ | 板块代码（格式：xxxxx.DC） |
| string | ❌ | 交易日期（YYYYMMDD） |
| string | ❌ | 开始日期 |
| string | ❌ | 结束日期 |
| string | ❌ | 板块类型：概念板块、行业板块、地域板块 |
✅ 本地开发：使用 .env 文件存储 Token（已在 .gitignore 中排除）
✅ 生产部署：使用系统环境变量或 Docker secrets
✅ 客户端配置：在客户端配置文件中传递 Token
❌ 避免：不要将 Token 硬编码在代码中或提交到 Git
src/
├── index.ts # stdio 模式入口
├── httpServer.ts # HTTP 模式入口
├── utils/
│ └── tushareClient.ts # Tushare API 客户端
└── tools/
├── thsIndex.ts # 同花顺板块指数列表
├── thsDaily.ts # 同花顺板块行情
├── thsMember.ts # 同花顺板块成分
├── dcIndex.ts # 东财板块信息
├── dcMember.ts # 东财板块成分
└── dcDaily.ts # 东财板块行情# 监听文件变化，自动编译
npm run watch
# 另开终端运行服务器
npm run dev在 src/tools/ 目录下创建新工具文件
实现工具接口（name, description, parameters, run）
在 src/index.ts 和 src/httpServer.ts 中导入并注册工具
所有工具均需要 5000-6000 积分的 Tushare 账号权限。具体权限要求：
get_ths_index: 需要 6000 积分
get_ths_daily: 需要 6000 积分
get_ths_member: 需要 5000 积分
get_dc_index: 需要 6000 积分
get_dc_member: 需要 6000 积分
get_dc_daily: 需要 6000 积分
A: 检查 Token 配置：
stdio 模式：检查环境变量或客户端配置的 env.TUSHARE_TOKEN
HTTP 模式：检查请求头 X-Tushare-Token 或环境变量
A: 某些接口需要 Tushare 会员权限，请：
访问 Tushare 积分商城
查看接口所需积分等级
升级账户权限
A: 可能原因：
日期参数错误（非交易日）
股票代码或板块代码错误
该日期没有数据
Apache-2.0 License - 详见 LICENSE 文件
陈星宇 (Xingyu Chen)
LinkedIn: Xingyu Chen
Email: guangxiangdebizi@gmail.com
GitHub: @guangxiangdebizi
NPM: @xingyuchen
NPM 包: financemcp-dcths
Model Context Protocol - MCP SDK
Tushare Pro - 金融数据 API
东方财富 - 数据来源（概念板块、行业板块数据）
同花顺 - 数据来源（概念指数、板块行情数据）
本项目使用的板块数据来源于：
同花顺（THS）数据：数据版权归属同花顺。如需商业用途，请联系同花顺获取授权。
东方财富（DC）数据：数据版权归属东方财富。如需商业用途，请联系东方财富获取授权。
本工具仅供个人学习和研究使用。
欢迎提交 Issue 和 Pull Request！
🐛 报告 Bug
💡 提出新功能建议
📖 改进文档
🔧 提交代码
⚠️ 免责声明：
本工具仅供学习和研究使用，数据来源于 Tushare API。使用本工具需要遵守 Tushare 的使用条款。任何投资决策请谨慎，本工具作者不承担任何投资风险和损失。
获取东方财富板块行情数据。包含开盘价、收盘价、涨跌幅、成交量等信息。支持概念板块、行业板块、地域板块。
| Name | Required | Description | Default |
|---|---|---|---|
| ts_code | No | 板块代码（格式：xxxxx.DC） | |
| trade_date | No | 交易日期（YYYYMMDD格式，如 20231201） | |
| start_date | No | 开始日期（YYYYMMDD格式） | |
| end_date | No | 结束日期（YYYYMMDD格式） | |
| idx_type | No | 板块类型：概念板块、行业板块、地域板块 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. Describes output fields but lacks disclosure of side effects, authentication needs, rate limits, or whether it's read-only. Minimal behavioral 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?
Three sentences: purpose, included fields, supported types. No wasted words, front-loaded with essential info.
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?
Describes output fields and sector types but omits parameter precedence (trade_date vs range), output format, and frequency. With no output schema or annotations, more context would help an AI agent use the tool correctly.
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 descriptions cover 100% of parameters with format info. Description adds value by listing included data fields and sector types, but fails to clarify interplay between trade_date and start/end_date, or that no parameters are required. Missing usage details for parameter combinations.
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 states tool gets sector market data from East Money, listing included fields (open, close, change, volume) and supported sector types (concept, industry, region). Distinguishes from sibling tools like get_dc_index and get_dc_member.
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, no exclusions or prerequisites provided. The description simply states what it does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取东方财富概念板块信息。包含板块涨跌幅、领涨股、总市值、换手率等数据。
| Name | Required | Description | Default |
|---|---|---|---|
| ts_code | No | 指数代码（支持多个代码同时输入，用逗号分隔） | |
| name | No | 板块名称（例如：人形机器人） | |
| trade_date | No | 交易日期（YYYYMMDD格式，如 20231201） | |
| start_date | No | 开始日期（YYYYMMDD格式） | |
| end_date | No | 结束日期（YYYYMMDD格式） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only implies read-only via '获取' (get). It does not disclose safety, side effects, rate limits, or any behavioral constraints beyond a basic retrieval 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?
Two efficient sentences: first states main purpose, second lists key data fields. No redundancy, front-loaded, and every word contributes 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?
The description provides basic context about retrieved fields but omits parameter relationships (e.g., how ts_code and name interact). With no output schema, some additional parameter usage hints would improve completeness for this 5-parameter 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?
Input schema covers all 5 parameters with full descriptions. The description adds no extra meaning beyond the schema; it only summarizes returned data types. Baseline 3 is appropriate given full schema coverage.
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 East Money concept sector information and lists included data types (rise/fall, leading stocks, market cap, turnover). This distinguishes it from sibling tools like get_ths_index (THS index) and get_dc_daily (daily data).
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 vs. siblings such as get_dc_daily or get_dc_member. The description focuses on what the tool does without context about filter combinations or appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取东方财富板块成分股数据。可查询指定板块的成分股，或查询指定股票所属的板块。支持历史成分查询。
| Name | Required | Description | Default |
|---|---|---|---|
| ts_code | No | 板块指数代码，查询该板块包含的成分股 | |
| con_code | No | 成分股票代码，查询该股票所属的板块 | |
| trade_date | No | 交易日期（YYYYMMDD格式），查询指定日期的成分 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses historical support and dual query modes, adding value. But it omits details on data freshness, pagination, authentication, or potential latency. The behavior is adequately implied for a read 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?
Three terse sentences cover essential functionality without redundancy. Each sentence contributes unique information: the purpose, two primary use cases, and historical support. No filler or unnecessary 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?
Despite the clear purpose, the description lacks critical details: it does not specify the return format or fields, nor what happens when no parameters are given (0 required). For a list tool, this is a significant gap. Return format is especially important since no output schema exists.
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 each parameter described in Chinese. The tool description adds value by explaining the semantic roles of ts_code (query constituents of a sector) and con_code (query sector of a stock), and clarifies that trade_date is for historical snapshots. This goes beyond the schema alone.
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 states the tool retrieves East Money sector constituent stock data, supporting two query modes (by sector index or stock code) and historical lookups. This verb+resource combination effectively distinguishes it from sibling tools like get_dc_daily and get_ths_member.
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?
Description provides clear context on when to use the tool (query constituents by sector, or find sector by stock) and mentions historical support. However, it does not explicitly exclude alternatives or compare with get_ths_member, which serves a similar purpose for a different data source.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取同花顺板块指数行情数据。包含开盘价、收盘价、涨跌幅、成交量等信息。
| Name | Required | Description | Default |
|---|---|---|---|
| ts_code | No | 指数代码（如 885823.TI） | |
| trade_date | No | 交易日期（YYYYMMDD格式，如 20231201） | |
| start_date | No | 开始日期（YYYYMMDD格式） | |
| end_date | No | 结束日期（YYYYMMDD格式） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It states the data included (open, close, change, volume) but omits critical behavior like read-only nature, rate limits, authentication needs, or data range restrictions. The description adds minimal value beyond the tool's 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 two sentences long, front-loaded with the main purpose, and contains no superfluous information. Every word earns its place.
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 4 parameters and no output schema, the description should explain return format, pagination (if any), and data behavior. It only lists data fields, leaving the UI or agent to infer the rest. Incomplete for practical use.
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 all 4 parameters described. The description does not add meaning beyond the schema; it merely lists included data fields. Baseline for high coverage is 3, and the description does not exceed it.
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 it fetches THS sector index daily data (开盘价、收盘价、涨跌幅、成交量), which distinguishes it from sibling tools like get_ths_index (index list) and get_ths_member (members). The verb '获取' and resource '同花顺板块指数行情数据' are specific.
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 explicit guidance on when to use this tool vs alternatives or any prerequisites. Sibling tools are listed but not compared. Usage is implied by the data type (daily data), but no constraints or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取同花顺概念和行业指数列表。可查询指数代码、市场类型、指数类型等信息。
| Name | Required | Description | Default |
|---|---|---|---|
| ts_code | No | 指数代码（如 885823.TI） | |
| exchange | No | 市场类型：A-A股 HK-港股 US-美股 | |
| type | No | 指数类型：N-概念指数 I-行业指数 R-地域指数 S-同花顺特色指数 ST-同花顺风格指数 TH-同花顺主题指数 BB-同花顺宽基指数 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits beyond the input schema. It does not mention side effects, rate limits, auth requirements, or whether the tool is read-only.
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 sentences, no redundant information. However, the Chinese phrasing could be slightly more streamlined, but overall it is concise and front-loaded.
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 simplicity of the tool (3 optional params, no output schema), the description is minimally adequate. It lacks details on the return format, pagination, or example usage, which would improve completeness.
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 description adds marginal value. It reiterates that users can query by index code, market type, and index type, but does not provide significant extra context beyond the schema descriptions.
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 a list of Tonghuashun concept and industry indices, and lists queryable fields (code, market type, index type). It is specific enough to distinguish from sibling tools like get_ths_daily or get_ths_member.
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. No mention of prerequisites, limitations, 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.
获取同花顺概念板块成分股列表。可查询指定板块的成分股，或查询指定股票所属的板块。
| Name | Required | Description | Default |
|---|---|---|---|
| ts_code | No | 板块指数代码（如 885823.TI），查询该板块包含的成分股 | |
| con_code | No | 股票代码（如 000001.SZ），查询该股票所属的板块 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description should disclose behavioral traits like data freshness, response size, or pagination. The current description lacks these details, providing only basic functionality.
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 concise sentences with no fluff. Each sentence adds value: the first states the purpose, the second elaborates on the two usage modes.
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 and lacks an output schema. The description covers the input and purpose but does not specify the output format (e.g., fields returned). Adequate but leaves gaps.
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 the description adds meaning by clarifying the two query modes: sector-to-stocks and stock-to-sectors. This goes beyond the schema's parameter descriptions.
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 the constituent stock list of Tonghuashun concept sectors, specifying two usage modes: by sector code or by stock code. It distinguishes from siblings like get_ths_daily and get_ths_index by focusing on member composition.
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 explains the tool's functionality but does not provide explicit guidance on when to use it versus alternatives, nor does it mention prerequisites or exclusions. Usage is implied from context.
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.3get_dc_dailyget_dc_indexget_dc_memberget_ths_dailyget_ths_indexget_ths_memberScored across 6 tools
Each tool has a unique purpose: daily data, index info, and member composition for two distinct data sources (东方财富 and 同花顺). There is no overlap or ambiguity between tools.
All tools follow a consistent 'get_[source]_[type]' pattern, where source is 'dc' or 'ths' and type is 'daily', 'index', or 'member'. No deviations.
6 tools is well-scoped for covering three essential functions (daily data, index, members) across two data sources. Neither too few nor too many.
The tool set provides complete coverage for the stated domain: daily market data, index overview, and composition details for both East Money and Tonghuashun sectors. No obvious gaps.
MCP server giving AI agents one-connection access to China A-share market intelligence: financials,
China A-share market data for research, backtesting and AI agents via MCP.
MCP server for stocksense-ai documentation, generated by doc2mcp.
Open-source MCP server for Zerodha Kite Connect. Portfolio, market data, backtesting, alerts.