A financial data MCP (Model Context Protocol) server based on AKShare, providing Claude and other AI assistants with comprehensive Chinese financial market data retrieval capabilities. Supports stocks, funds, futures, economic indicators, and more.
Node.js: 18.0.0 or higher
Python: 3.8 or higher (only required for Python version)
# 1. Clone the project
git clone https://github.com/jadenmong/akshare-mcp-server.git
cd akshare-mcp-server
# 2. Install Node.js dependencies
npm install
# 3. Start the server (HTTP version, recommended - no Python dependencies)
npm start
# Or start Python version (requires Python and akshare installation)
npm run start:pythonThe project provides two MCP server implementations:
HTTP Version (Recommended):
โ Zero Python dependencies, ready to use
โ Based on AKShare HTTP API, stable and reliable
โ Built-in fallback data ensures service availability
โ Simple deployment, fast startup
Python Version:
โ Direct AKShare library calls, richer data
โ Supports more data types (futures, economic indicators)
โ Requires local Python 3.8+ environment
โ Requires akshare library installation
Related MCP server: AkTools MCP Server
Add the following configuration to your Claude Desktop configuration file:
Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Linux: ~/.config/claude/claude_desktop_config.json
HTTP Version Configuration (Recommended):
{
"mcpServers": {
"akshare": {
"command": "node",
"args": ["<your-project-path>/src/http-server.js"],
"description": "AKShare Financial Data MCP Server (HTTP)"
}
}
}Python Version Configuration:
{
"mcpServers": {
"akshare": {
"command": "node",
"args": ["<your-project-path>/src/server.js"],
"description": "AKShare Financial Data MCP Server (Python)"
}
}
}Note:
Replace <your-project-path> with your actual absolute path
Windows: use double backslashes \\, e.g., D:\\projects\\akshare-mcp-server\\src\\http-server.js
macOS/Linux: use forward slashes /, e.g., /home/user/akshare-mcp-server/src/http-server.js
Historical Data: get_stock_historical_data - Get stock historical data
Real-time Quotes: get_stock_realtime_data - Get stock real-time quotes
Stock List: get_stock_list - Get stock list
Stock Search: search_stock - Search stock information
Fund List: get_fund_list - Get fund list
Futures Information: get_futures_info - Get futures market data
Economic Indicators: get_economic_data - Get macroeconomic data
Feature | HTTP Version | Python Version |
Stock Historical Data | โ | โ |
Stock Real-time Data | โ | โ |
Stock List | โ | โ |
Stock Search | โ | โ |
Fund Data | โ | โ |
Futures Data | โ | โ |
Economic Data | โ | โ |
akshare-mcp-server/
โโโ src/
โ โโโ http-server.js # HTTP version MCP server (recommended)
โ โโโ server.js # Python version MCP server
โ โโโ tools/ # Financial data tool modules
โ โ โโโ stock_tools.js # Stock data tools
โ โ โโโ fund_tools.js # Fund data tools
โ โ โโโ futures_tools.js # Futures data tools
โ โ โโโ economic_tools.js # Economic data tools
โ โโโ utils/
โ โโโ toolHelpers.js # Tool helper functions
โโโ test/
โ โโโ test.js # Automated test suite
โโโ python_bridge.py # Python bridge script
โโโ requirements.txt # Python dependencies
โโโ package.json # Node.js configuration
โโโ README.md # English documentation
โโโ README_CN.md # Chinese documentation
โโโ LICENSE # MIT License{
"name": "get_stock_historical_data",
"arguments": {
"symbol": "000001",
"period": "daily",
"start_date": "20240101",
"end_date": "20240131",
"adjust": "qfq"
}
}{
"name": "get_stock_realtime_data",
"arguments": {
"symbol": "000001"
}
}{
"name": "get_stock_list",
"arguments": {
"market": "all"
}
}{
"name": "get_fund_info",
"arguments": {
"symbol": "510050"
}
}{
"name": "get_fund_list",
"arguments": {
"type": "etf"
}
}{
"name": "get_futures_info",
"arguments": {
"symbol": "ag",
"exchange": "SHFE"
}
}{
"name": "get_economic_data",
"arguments": {
"indicator": "GDP",
"start_date": "20240101",
"end_date": "20241231"
}
}The project includes a comprehensive automated test suite for both versions:
npm testTest coverage includes:
Tool list retrieval
Stock historical data queries
Stock real-time quotes
Stock list retrieval
Fund data queries
Futures data queries (Python version)
Economic data queries (Python version)
# HTTP version development mode
npm run dev
# Python version development mode
npm run dev:pythonNode.js Version Too Low
Error: Node.js version 18.0.0 or higher required
Solution: Upgrade Node.js to the latest LTS versionPython Dependencies Installation Failed
# Try using a domestic mirror
pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple/Claude Desktop Connection Failed
Check if the configuration file path is correct (note Windows uses double backslashes)
Confirm that http-server.js or server.js file path exists
Restart the Claude Desktop application
Check Claude Desktop log output
Data Retrieval Failed
Check network connection
HTTP version: Confirm access to AKShare HTTP API
Python version: Confirm akshare library is installed (pip list | grep akshare)
Check server log output for errors
Start the server with detailed logging:
DEBUG=akshare:* npm startโก High Performance: Node.js async processing with concurrent request support
๐ก๏ธ Type Safety: Strict parameter validation and type checking using Zod
๐ Python Bridge: Secure AKShare Python library calls via subprocess
๐ง Modular Design: Tools organized by financial product category for easy maintenance
๐ Data Standardization: Unified JSON data format and error handling
๐ Easy to Extend: Simple tool definition and addition mechanism for rapid integration
๐ Dual Implementation: HTTP and Python versions for different use cases
โ Comprehensive Testing: Automated test suite ensures code quality
This project is open source under the MIT License.
AKShare - Powerful financial data API library
Model Context Protocol - Standardized tool interface protocol
Welcome to submit Issues and Pull Requests to improve this project!
If you encounter issues during use, please:
Check the Troubleshooting section of this documentation
Submit an issue on GitHub Issues
Consult the AKShare Official Documentation
English Documentation: README.md (this document)
Chinese Documentation: README_CN.md
AKShare Documentation: AKShare Official Docs
MCP Protocol: Model Context Protocol
Support more financial data types (bonds, forex, cryptocurrency)
Add data caching mechanism for better performance
Support custom data source configuration
Provide Docker image for simplified deployment
Add data visualization tool integration
Get fund list from HTTP sources.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | etf | |
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only mentions 'from HTTP sources,' which is trivial and does not reveal side effects, rate limits, data freshness, or that it is a read-only operation. The agent lacks essential 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?
The description is a single short sentence, which is concise but lacks substance. It is not overly verbose, but it sacrifices clarity for brevity. Key information is missing, making it less effective than it could be.
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 two parameters, no output schema, and no annotations, the description is too minimal. It does not explain the return format, pagination (if any), or how the 'limit' parameter affects results. The agent cannot confidently invoke this tool without additional assumptions.
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 0%, and the description does not mention parameters at all. The schema provides enums and defaults, but the meaning of values like 'qfii' is unexplained. The agent must infer parameter semantics solely from the schema, which is insufficient.
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 'Get fund list from HTTP sources,' which clearly identifies the action and resource. However, it does not distinguish this tool from the sibling tool 'get_stock_list,' and the reference to 'HTTP sources' is vague. The schema's enum values (etf, lof, qfii, all) are not explained, making the purpose less precise.
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?
There is no guidance on when to use this tool versus alternatives like 'search_stock' or 'get_stock_list.' Context signals show related sibling tools, but the description does not specify scenarios or criteria for selecting this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get stock historical data from HTTP sources.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock code, for example "000001" | |
| period | No | daily | |
| start_date | No | Start date in YYYY-MM-DD or YYYYMMDD | |
| end_date | No | End date in YYYY-MM-DD or YYYYMMDD | |
| adjust | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only adds "from HTTP sources". It omits important details like data format, rate limits, authentication needs, or error handling.
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) and front-loaded, but it lacks substance. It is concise but at the expense of completeness.
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 five parameters, no output schema, and no annotations, the description is insufficient. It fails to explain the data source, return format, or how parameters like adjust affect the results.
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 description adds no meaning beyond the input schema. With 60% schema coverage, it does not compensate by explaining parameter roles or providing examples beyond what the schema already offers.
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 and resource: "Get stock historical data". It distinguishes from real-time data but does not explicitly differentiate from search_stock, which also involves searching for stock 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 tool versus alternatives like get_stock_realtime_data or search_stock. No when-not-to-use information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get stock list from HTTP sources.
| Name | Required | Description | Default |
|---|---|---|---|
| market | No | all | |
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only mentions 'from HTTP sources' implying network dependency but fails to disclose other traits like rate limits, caching, or effects on system state. The description does not compensate for missing annotations.
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 structure. It front-loades the purpose but omits critical details, making it insufficiently informative.
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 absence of an output schema and annotations, the description should explain what the tool returns. It does not. The tool is simple but the description fails to provide a complete picture for proper invocation.
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 0%, yet the description adds no explanation for the 'market' enum values (sh, sz, all) or the 'limit' parameter. Without schema descriptions, the agent has no meaningful guidance on parameter usage.
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 'Get stock list from HTTP sources' which identifies the resource and action but is vague. It does not specify what the list contains (e.g., symbols, names) or differentiate it clearly from siblings like 'get_stock_historical_data' or 'search_stock'.
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 siblings (e.g., 'get_fund_list', 'search_stock'). There is no mention of prerequisites, contexts, or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get stock real-time data from HTTP sources.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock code, for example "000001" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must fully disclose behavior. It only states 'from HTTP sources,' which is trivial. Missing critical details: data freshness, rate limits, authentication requirements, error handling, or whether it returns live vs. delayed 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?
Single sentence front-loads purpose efficiently. No extraneous words, but could be slightly more informative 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?
Given only one parameter and no output schema, the description should specify what data is returned (e.g., price, volume, timestamp) or any limits. It fails to provide this essential context, leaving the agent underinformed.
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% (parameter 'symbol' described with example). Description adds no additional meaning beyond the schema, 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?
Clearly states 'Get stock real-time data,' specifying verb and resource. Sibling tools like get_stock_historical_data and search_stock indicate distinct scope, so differentiation is implied. However, it lacks specifics about market or data source, which would enhance 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 usage guidance provided. The description does not indicate when to use this tool versus alternatives (e.g., search_stock for finding stocks, get_stock_historical_data for past data). No prerequisites or contexts mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search stock information from HTTP sources.
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Stock name or code keyword | |
| market | No | all |
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 any behavioral traits such as authentication needs, rate limits, or what data is returned.
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, concise, but too brief to be informative. It lacks necessary details but is not 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?
No output schema, no annotations, and the description does not explain return format, errors, or any additional context needed for a search tool with a required parameter.
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 schema covers one parameter's description (keyword) but missing description for market. The description does not add extra meaning beyond the schema; market enum values are not explained.
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 the tool searches stock information, which is a verb+resource. However, it does not distinguish from sibling tools like get_stock_realtime_data or get_stock_list, and the meaning of 'HTTP sources' is unclear.
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 prerequisites, no exclusions provided. The description only states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct resource or data type: funds vs. stocks, and within stocks: historical data, real-time data, list, and search. No overlapping purposes.
All tool names follow a verb_noun pattern in snake_case (get_fund_list, get_stock_historical_data, etc.). The only slight variation is 'search_stock' instead of 'get_search_stock', but it still maintains the verb_noun structure.
With 5 tools covering both fund and stock data retrieval, the count is well-scoped for a financial data API. It provides essential operations without being overwhelming.
The tool set covers core read operations for stocks and funds but lacks fund historical and real-time data, which are minor gaps. The primary domain (stock and fund lookups) is well-covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Provide access to Chinese stock market data including historical prices, real-time data, news, andโฆ
China A-share market data for research, backtesting and AI agents via MCP.
Read-only China A-share data for AI agents: market, limit-up, capital flow and disclosures.
Access real-time and historical market data for China A-shares and Hong Kong stocks, along with neโฆ
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jadenmong/akshare-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
