Real-time financial market data for A-share (China), Hong Kong, and US markets via the Model Context Protocol.
The only MCP server covering Asia-Pacific market data — the gap that no existing financial data MCP fills.
Real-time stock quotes — A-share, HK, and US markets
K-line / candlestick data — Historical OHLCV with multiple time periods
Market status — Live trading session status for US, HK, and CN
Market summary — Major global indices (S&P 500, NASDAQ, Dow, Hang Seng, SSE, CSI 300)
Batch quotes — Multiple stocks in a single call
Related MCP server: Stock Data MCP Server
CODE.MARKET — e.g. 600519.SH, 0700.HK, NVDA.US
Market | Code | Exchange |
SH | Shanghai Stock Exchange | A-shares |
SZ | Shenzhen Stock Exchange | A-shares |
HK | Hong Kong Stock Exchange | HK stocks |
US | US markets | NYSE, NASDAQ |
Market | Primary Source | Fallback | Latency |
A-share (SH/SZ) | Tencent Finance API | yfinance | Real-time |
Hong Kong | Tencent Finance API | Longbridge CLI | Real-time |
US | Longbridge CLI | yfinance | Real-time |
All data sources are free-tier APIs. No API keys required for basic usage.
Add to your MCP config:
{
"mcpServers": {
"asia-market-data": {
"url": "http://YOUR_SERVER:9100/mcp",
"transport": "streamable-http"
}
}
}pip install fastmcp requests yfinance
python server.pyTool | Description | Price |
| Real-time quote for a single stock | Free |
| Batch quotes for multiple stocks | Free |
| Historical OHLCV candlestick data | Free |
| Global market open/close status | Free |
| Major global indices summary | Free |
> Get the current price of Tencent
→ stock_quote(symbol="0700.HK")
→ Returns: { "last_price": 419.0, "change_pct": -1.64, ... }
> Show me the last 3 months of K-line data for Moutai
→ kline(symbol="600519.SH", period="3mo")
→ Returns: { "count": 64, "klines": [...] }
> What markets are open right now?
→ market_status()
→ Returns: { "US": "closed", "HK": "closed", "CN": "closed" }Phase 1: Free data sources, no payment gate (current)
Phase 2: x402 per-call billing for premium tools
Phase 3: Licensed data sources (EODHD, Longbridge commercial API)
Phase 4: WebSocket real-time streaming
MIT
Get K-line (candlestick/OHLCV) data for a stock.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | Time period - 1mo, 3mo, 6mo, 1y (default: 3mo) | 3mo |
| symbol | Yes | Stock symbol in CODE.MARKET format (e.g. 600519.SH, 0700.HK) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are not provided, so the description carries the burden. It mentions data is 'OHLCV' which discloses the return content, and the period parameter implies time-series behavior. However, it doesn't disclose whether the tool returns historical data only (no real-time), pagination, or data source limitations. The description adds some value but is not rich.
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?
A single, direct sentence that front-loads the purpose. No waste, but it is too brief for a data-heavy tool; still, without extra detail, it remains concise.
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?
An output schema exists, so return values are covered there. The period defaults are in the schema. Missing are usage context (historical vs real-time) and data fidelity notes, but for a simple OHLCV tool this is minimally adequate.
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 both parameters are already described in the schema. The description adds no extra meaning beyond what the schema provides, so 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 states a specific verb ('Get') and a clear resource ('K-line (candlestick/OHLCV) data for a stock'). It defines the resource more precisely than just 'kline' and distinguishes it from price-only tools like stock_quote, though it does not explicitly name siblings.
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 explicit guidance on when to use this tool versus alternatives. The sibling tools (stock_quote, stock_quote_batch) suggest price data tools, but the description doesn't clarify when K-line is preferred over a simple quote. The context is implied by 'K-line' being candlestick data but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get global market open/close status for US, HK, and CN markets.
Returns current trading session status (open/pre_market/after_hours/closed) for each major market based on UTC time.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It gives specific, non-obvious details: the exact status values (open/pre_market/after_hours/closed) and the UTC-time basis of the calculation. It omits potential nuance like holiday handling, but for a read-only, no-parameter tool this is strong coverage.
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 tight sentences with no filler. The first front-loads the core purpose and scope, and the second supplies the output vocabulary and time basis. Every sentence 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?
For a tool with no parameters, an existing output schema, and a read-only nature, the description covers all needed facts: purpose, exact market scope, returned statuses, and the time reference. Nothing an agent needs to decide whether to call it is missing.
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 schema coverage is trivially 100% and the description needs to document no arguments. It does add semantic context by naming the fixed markets (US, HK, CN) it covers. Baseline 4 for a parameterless tool 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 states a specific verb and resource: 'Get global market open/close status for US, HK, and CN markets.' It clearly identifies the exact data returned and the three market scopes, making it easy to distinguish from quote- and kline-focused siblings.
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 when to use this tool—whenever global market session status is needed—but it does not explicitly mention sibling alternatives like market_summary or state when to prefer one over the other. This leaves some routing to inference, though the purpose is clear enough to avoid gross misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get summary of major global indices (S&P 500, NASDAQ, Dow Jones, Hang Seng, SSE, CSI 300).
Returns current price and daily change percentage for each index.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states what the tool returns (price and change percentage) but does not explicitly mention that it is read-only, nor does it disclose any side effects, data freshness, or potential errors. While the word 'Get' implies a read operation, more transparency would be helpful.
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 concise sentences, front-loaded with the main purpose and followed by a precise list of indices and the return contents. Every sentence earns its place with 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?
For a tool with no parameters and a clear output schema (present but not shown), the description is sufficient. It covers the scope, the exact indices, and the nature of the returned data. An agent can confidently call this tool without further information.
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 schema coverage is trivially 100%. The description does not need to add parameter details, and none are provided. Per rubric, 0 params sets a baseline of 4, which is appropriate since 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 clearly states the tool's purpose: 'Get summary of major global indices' and lists the specific indices (S&P 500, NASDAQ, etc.). It also specifies the output (current price and daily change percentage). This distinguishes it from sibling tools like stock_quote (individual stocks) and market_status (market status), making it easy for an agent to identify the right tool.
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 when to use the tool (when you need index summaries) but does not explicitly contrast it with alternatives. For instance, it does not say 'for individual stock quotes, use stock_quote' or provide exclusions. The context is clear but lacks explicit routing guidance.
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 quote for A-share, HK, or US stocks.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock symbol in CODE.MARKET format (e.g. 600519.SH, 0700.HK, NVDA.US) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It reveals that the quote is 'real-time' and covers three markets, but does not disclose anything about data source, market-hours behavior, rate limits, or what happens for invalid symbols. The 'real-time' claim adds some behavior, but the overall disclosure is thin.
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?
A single front-loaded sentence with no filler. Every word contributes to the core purpose and market scope. It does not attempt to restate schema details, keeping it appropriately concise.
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?
Although the tool is simple and an output schema exists, the description omits any guidance about when to pick this tool over the closely related stock_quote_batch. It also lacks any usage conditions or caveats. For a tool with no annotations, this is a meaningful gap despite the simple shape.
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 the baseline is 3. The description does not add meaning beyond the schema; the symbol format and examples are already in the input schema. No deduction or bonus is warranted.
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 a specific verb ('Get') and resource ('real-time stock quote'), and scopes it to A-share, HK, and US stocks. It is clear but does not explicitly differentiate from the sibling stock_quote_batch, so it stops short of a 5.
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 given on when to use this tool versus stock_quote_batch, kline, or market_status. An agent cannot tell whether this tool is for single quotes only or whether batch should be preferred for multiple symbols. The context is implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get real-time quotes for multiple stocks. Symbols separated by commas.
| Name | Required | Description | Default |
|---|---|---|---|
| symbols | Yes | Comma-separated symbols (e.g. "600519.SH,0700.HK,AAPL.US") |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Get real-time quotes' conveys a non-destructive read operation and implies freshness, which is useful. However, it does not disclose batch size limits, symbol validation behavior, or partial failure handling—important behavioral context for an agent.
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 deliver the core action and input format with no filler. The most important operative detail—batch quote retrieval—is front-loaded, and 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?
For a single-parameter read tool with an output schema, the description plus schema is largely sufficient. It communicates the batch scope and input format, distinguishing it from the single-stock sibling. Minor omissions like rate limits or maximum symbol count prevent a 5.
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 the schema fully documents the single 'symbols' parameter, including an example. The description's 'Symbols separated by commas' matches the schema without adding new meaning, so the baseline 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 uses a specific verb ('Get') and identifies both the resource ('real-time quotes') and the key scope ('multiple stocks'). This clearly distinguishes it from the single-symbol sibling stock_quote while remaining distinct from kline, market_status, and market_summary.
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 establishes clear use context: call this tool when you need real-time quotes for several stocks, and separate symbols by commas. It does not explicitly name alternatives or exclusion cases, so it falls short of a 5, but the intended usage is unambiguous.
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.
v0.1.0klinemarket_statusmarket_summarystock_quotestock_quote_batchScored across 5 tools
Each tool has a clearly distinct purpose: single quote, batch quote, historical K-line data, market status, and market summary. The only overlap is between stock_quote and stock_quote_batch, but batch is a natural extension and clearly named.
All tool names follow a consistent snake_case pattern with a clear verb-noun structure (e.g., stock_quote, market_status). Even 'kline' is a concise but recognizable abbreviation, and the naming is uniform throughout.
Five tools is well-scoped for a market data server, covering real-time quotes, historical data, and market-level information without redundancy or unnecessary bloat.
The surface covers the core needs for market data: quotes, historical candles, market status, and index summaries. Minor gaps like search/fundamentals exist but are not essential for the primary use case.
Provide access to Chinese stock market data including historical prices, real-time data, news, and…
Access real-time and historical market data for China A-shares and Hong Kong stocks, along with ne…
Real-time & historical market data: forex, stocks, crypto, indices, metals, K-line, quotes
China A-share market data over MCP: 22 tools for quotes, K-line, financials, money flow, top-trader boards, sectors, macro, convertible bonds and factor screening. Five tools need no API key, so you can connect and try it immediately.
