Provide access to Chinese stock market data including historical prices, real-time data, news, and…
Scored across 9 tools
Each tool targets a distinct financial data type: individual statements, derived metrics, historical vs. real-time prices, insider trades, news, and a time utility. The only potential overlap is get_financial_metrics vs. the three statement tools, but the description clarifies it returns derived key metrics rather than raw statement data. No two tools appear to do the same thing.
All nine tools follow the exact same get_<noun> snake_case pattern (e.g., get_balance_sheet, get_cash_flow, get_realtime_data). There are no deviations in verb style, casing, or structure. This makes the set highly predictable.
Nine tools is well-scoped for a financial data server covering statements, market data, news, insider trading, and time. Each tool has a clear, non-redundant purpose, and the count is neither bloated nor too thin for the domain.
The surface covers core financial statements, key metrics, historical and real-time prices, insider trades, and news, forming a coherent dataset for stock analysis. Minor gaps exist, such as a stock lookup/search tool or company profile data, but these are workarounds rather than critical missing operations.
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.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure but only offers minimal information about data source capabilities. It does not explain error handling for invalid symbols, rate limits, data availability periods, or whether the technical indicators are computed server-side or require specific parameters.
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 appropriately brief with two concise statements and no extraneous information. The purpose is front-loaded in the first sentence. The second sentence suffers from minor grammatical awkwardness ('support' instead of 'supports') but remains intelligible.
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 complex tool with 9 parameters—including technical indicators, multiple data sources, and date ranges—the description is insufficient. With no output schema or annotations to rely on, it should explain the return format, available data fields, and key parameter interactions, which it does not provide.
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?
Given 100% schema coverage, the baseline is adequate, but the description adds meaningful value by clarifying that eastmoney_direct supports all A/B/H shares, which helps users select the appropriate source parameter. However, it misses opportunities to explain technical concepts like qfq/hfq adjustments or the practical use of interval_multiplier.
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 core action ('Get') and resource ('historical stock market data'), distinguishing it from siblings like get_realtime_data and financial statement tools. The mention of A/B/H share support adds valuable scope context. However, it lacks specificity about what data points are actually returned (OHLCV prices, volume, etc.).
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 versus alternatives like get_realtime_data or the financial metrics tools. While it hints that eastmoney_direct supports all A/B/H shares, it fails to explain source selection criteria or how to choose between date ranges versus the recent_n parameter.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions return components (ISO format, timestamp, last trading day) but fails to disclose idempotency, timezone handling, rate limits, or whether 'last trading day' refers to a specific exchange/market.
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 efficient sentence with no waste. Information is front-loaded with specific formats (ISO, timestamp) and the key trading calendar feature mentioned immediately.
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?
Without an output schema, the description appropriately mentions the three return components (ISO time, timestamp, last trading day). However, given the financial context implied by siblings, it should specify which market's trading calendar is used or if it requires symbol-specific 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?
The input schema has zero parameters, establishing baseline 4 per evaluation rules. No parameter description is necessary or expected given the empty 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 clearly states the tool retrieves current time information in ISO format and timestamp, plus trading calendar data (last trading day). This effectively distinguishes it from financial data siblings like get_balance_sheet. However, it lacks specificity about which market's trading calendar or timezone context.
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, or prerequisites for invocation. While the financial data focus of sibling tools makes this tool's utility role somewhat implied, there is no discussion of when time/trading day data is needed versus other operations.
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.
get_balance_sheet3 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / properties / recent_n / anyOfPrevious value: -[
- {
- "minimum": 1,
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maximum": 9007199254740991,
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / (root)Previous value: -{
- "properties": {
- "result": {
- "type": "string"
- }
- },
- "required": [
- "result"
- ],
- "type": "object",
- "x-fastmcp-wrap-result": true
-}New value: +nullget_cash_flow5 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / properties / recent_n / anyOfPrevious value: -[
- {
- "minimum": 1,
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maximum": 9007199254740991,
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / source / constRemoved value: -"sina"Input schema / properties / source / enumAdded value: +[
+ "sina"
+]Output schema / (root)Previous value: -{
- "properties": {
- "result": {
- "type": "string"
- }
- },
- "required": [
- "result"
- ],
- "type": "object",
- "x-fastmcp-wrap-result": true
-}New value: +nullget_financial_metrics3 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / properties / recent_n / anyOfPrevious value: -[
- {
- "minimum": 1,
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maximum": 9007199254740991,
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / (root)Previous value: -{
- "properties": {
- "result": {
- "type": "string"
- }
- },
- "required": [
- "result"
- ],
- "type": "object",
- "x-fastmcp-wrap-result": true
-}New value: +nullget_hist_data4 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / properties / interval_multiplier / maximumAdded value: +9007199254740991Input schema / properties / recent_n / anyOfPrevious value: -[
- {
- "minimum": 1,
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maximum": 9007199254740991,
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / (root)Previous value: -{
- "properties": {
- "result": {
- "type": "string"
- }
- },
- "required": [
- "result"
- ],
- "type": "object",
- "x-fastmcp-wrap-result": true
-}New value: +nullget_income_statement3 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / properties / recent_n / anyOfPrevious value: -[
- {
- "minimum": 1,
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maximum": 9007199254740991,
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / (root)Previous value: -{
- "properties": {
- "result": {
- "type": "string"
- }
- },
- "required": [
- "result"
- ],
- "type": "object",
- "x-fastmcp-wrap-result": true
-}New value: +nullget_inner_trade_data2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Output schema / (root)Previous value: -{
- "properties": {
- "result": {
- "type": "string"
- }
- },
- "required": [
- "result"
- ],
- "type": "object",
- "x-fastmcp-wrap-result": true
-}New value: +nullget_news_data3 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / properties / recent_n / anyOfPrevious value: -[
- {
- "minimum": 1,
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maximum": 9007199254740991,
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / (root)Previous value: -{
- "properties": {
- "result": {
- "type": "string"
- }
- },
- "required": [
- "result"
- ],
- "type": "object",
- "x-fastmcp-wrap-result": true
-}New value: +nullget_realtime_data2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Output schema / (root)Previous value: -{
- "properties": {
- "result": {
- "type": "string"
- }
- },
- "required": [
- "result"
- ],
- "type": "object",
- "x-fastmcp-wrap-result": true
-}New value: +nullget_time_info2 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Output schema / (root)Previous value: -{
- "additionalProperties": true,
- "type": "object"
-}New value: +nullget_balance_sheetget_cash_flowget_financial_metricsget_hist_dataget_income_statementget_inner_trade_dataget_news_dataget_realtime_dataget_time_infoAccess real-time and historical market data for China A-shares and Hong Kong stocks, along with ne…
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.
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.
Add one secure layer between your agents and this server.
