akshare-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct financial domain (bonds, funds, futures, forex/commodities, indices, macro, options, miscellaneous, A-stocks, boards/flow, fundamentals, HK/US stocks, margin/other) with clear boundaries and no overlap.
Naming Consistency5/5
All tool names follow a consistent 'akshare_<domain>' pattern using lowercase and underscores, making them predictable and easy to navigate.
Tool Count5/5
The 14 tools appropriately cover a broad financial data scope without being excessive; each tool groups many related functions, keeping the count manageable.
Completeness5/5
The tool set covers a comprehensive range of financial data including stocks, bonds, funds, futures, options, indices, macroeconomics, forex, commodities, and more, leaving no obvious gaps for typical financial analysis needs.
Average 2.7/5 across 14 of 14 tools scored. Lowest: 1.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Some methods include notes about IP blocking (e.g., '大量抓取容易封 IP'), but overall behavioral traits such as mutation, rate limits, or idempotency are not disclosed. No annotations provided to compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely long and poorly structured, listing dozens of methods with minimal formatting. It lacks front-loading of essential information and is not concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (many methods, 8 parameters, no annotations), the description is incomplete. It does not explain how to use parameters, what the output schema contains, or how to choose between methods.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; the description does not explain any parameters. While the required 'method' parameter is implied by the list of methods, its format and constraints are not described. The 'params_json' parameter with default '{}' adds confusion without explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with margin trading but then lists many unrelated functions (e.g., stock news, B-shares, account statistics), making the tool's purpose ambiguous. It does not differentiate from sibling tools like akshare_stock_a or akshare_fund.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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. The description is a list of methods without any context about use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions IP blocking risks for certain methods (e.g., '大量抓取容易封 IP'). It lacks systematic disclosure of data freshness, rate limits, or other behavioral traits. The read-only nature is implied but not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely long (200+ lines) and poorly structured as a monolithic list of methods. It lacks categorization or hierarchy, making it hard to parse. Conciseness is sacrificed without gaining clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (many sub-functions, 8 parameters), the description is incomplete. It does not explain output schema or how to combine parameters for each method. The lack of categorization further reduces completeness for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%—no parameter descriptions in the schema. The description does not explain how the generic parameters (symbol, date, etc.) map to specific methods, nor does it clarify the params_json catch-all. This forces the agent to infer meaning, risking incorrect invocations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it covers A-share stock data including real-time quotes, historical bars, limit-up pools, etc., which gives a general purpose. However, it does not clearly differentiate from sibling tools like akshare_stock_fundamental or akshare_stock_board_flow, making the scope ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 siblings. The description lists many methods but does not provide context for selection, e.g., when to use this tool for historical data vs. another sibling for fundamental data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description fails to disclose any behavioral traits such as side effects, authentication needs, rate limits, or data freshness. For a tool with numerous data sources, this is a critical omission, leaving the agent blind to important operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with headers and bullet points, but it is verbose, listing many methods with Chinese text. It front-loads a summary but then dives into an extensive list. Some sentences are redundant or unclear, detracting from efficient parsing by an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (many methods, 8 parameters, no schema descriptions, no annotations), the description is woefully incomplete. It does not explain common parameter usage, the role of 'params_json', or how to interpret results. An output schema exists but is not provided; its absence further harms completeness. The agent cannot reliably invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for its 8 parameters. The description shows example calls with parameters (e.g., crypto_bitcoin_cme(date='20230830')) but does not explain parameter meaning, format, or valid values across methods. The 'params_json' parameter is unexplained, adding confusion. The agent cannot determine how to properly set parameters without external knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool provides forex and commodity data, and it lists many specific methods. This distinguishes it from sibling tools (e.g., akshare_bond, akshare_stock_a) that cover other asset classes. However, it lacks a concise verb+resource summary, relying on a broad listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 description does not mention prerequisites, use cases, or when not to use it. The agent must infer from the method names and siblings, which is insufficient for confident selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 read-only nature, authorization needs, rate limits, or effects. Only method names and sources are given, which is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is excessively long and unstructured, presented as a flat list of methods without grouping or hierarchy. It could be condensed into a brief overview with links to method details, but instead overloads the agent with raw enumeration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the presence of an output schema, the description lacks essential context: how to choose a method, what the 'method' parameter values are (only examples), and how to construct other parameters. The tool's complexity is high, but the description does not sufficiently compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain parameters. It shows example values (e.g., symbol='03900') but does not clarify their meaning, formatting, or optionality. The long list of methods with inline params adds some context but is inconsistent and incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Hong Kong and US stock data', which broadly indicates the resource but lacks a specific verb-action. It is not a tautology, but it fails to state a clear, single purpose or differentiate from siblings like akshare_stock_a beyond asset class.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs siblings. The description simply lists methods without context about selection criteria, prerequisites, or alternatives, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 fails to mention rate limits, authentication, error handling for invalid methods, or the statefulness of the tool. It only lists available methods without discussing side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is excessively long (100+ lines) and poorly structured for an AI agent. While front-loaded with a brief summary, it then dumps a massive list of methods with repetitive signatures. Each signature carries little incremental value. The description would benefit from grouping methods by category or providing a clearer dispatch pattern explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is incomplete for a tool with such high complexity. It does not explain how the dispatcher pattern works: e.g., setting the 'method' parameter selects a function, and its parameters are passed via the other top-level fields or params_json. The agent cannot reliably invoke the tool without guessing parameter mappings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides method signatures with example parameters (e.g., symbol='黄金') but does not explain how the top-level parameters (date, symbol, etc.) map to each method's arguments. The role of params_json is unclear. This leaves the agent guessing how to invoke specific methods.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides Chinese and global futures data across multiple categories (real-time quotes, contract specs, inventory, etc.). The tool name 'akshare_futures' helps distinguish it from siblings like akshare_stock_a. However, the massive list of methods clutters the purpose and could overwhelm an agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool vs. alternatives. The description does not mention when not to use it or provide context for choosing between this and other akshare tools. Implicit differentiation from siblings is weak.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 any side effects, authorization needs, rate limits, or data freshness. The description merely lists endpoints without explaining behavior beyond what is obvious from method names.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely verbose, listing dozens of methods with Chinese descriptions, which makes it hard to scan. While the method list is useful, the overall structure is a wall of text. It could be shortened and organized into categories.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description is incomplete. It fails to explain how to construct the 'method' parameter, how parameters like 'params_json' work, or what the output format is. The method list is helpful but insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 8 parameters with 0% description coverage. The description does not explain any parameter, even the required 'method' parameter. Some method names in the list hint at possible values, but there is no systematic documentation of parameters like 'date', 'symbol', or 'params_json'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides 'alternative and miscellaneous data' and lists a wide range of categories (air quality, box office, etc.), distinguishing it from sibling tools that cover specific asset classes like bonds, stocks, or funds. However, it's more of a list than a concise statement of purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 its siblings. While it's implied that this tool covers data not handled by other akshare tools, there are no when-to-use or when-not-to-use instructions, nor any mention of prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as authentication requirements, rate limits, side effects, or data retrieval vs. mutation. The list of methods implies data retrieval, but there is no explicit statement about safety or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly long, containing a large numbered list of 30+ methods with Chinese descriptions. It lacks a concise overview and buries the purpose in a wall of text. While structured as a list, it is not front-loaded with essential information; many entries are redundant for understanding the tool's core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple data categories, 8 parameters), the description is incomplete. It does not explain return values despite an output schema being present. The method list is detailed but lacks context on how the parameters (like 'date' or 'adjust') interact with specific methods, leaving substantial gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 explain any parameters. While some methods include example values in parentheses (e.g., symbol='融资融券'), there is no general definition of parameters like 'symbol', 'start_date', or 'period'. The agent must guess parameter meaning from context, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear summary stating it covers concept/industry board data, capital flow, and northbound/southbound connect data. This effectively communicates the tool's domain. However, it does not explicitly differentiate from sibling tools like akshare_stock_a or akshare_index, relying instead on the tool name and the listed methods to imply distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 prerequisites, use cases, or exclusions. The description simply lists available methods without any strategic instructions for selection, leaving the agent to infer usage from method names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior, but it only lists methods without stating side effects, reading nature, or error handling. It mentions data sources (新浪/东财/同花顺) which adds some value, but overall transparency is low.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is unnecessarily long with an exhaustive list of methods. While the first sentence gives a high-level overview, the remainder is a massive bullet list that could be summarized. Every sentence does not earn its place; much of the content could be moved to a separate reference.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, many sub-functions) and the lack of schema descriptions, the description fails to be complete. It does not explain the purpose of universal parameters like params_json, nor does it cover how output schema relates to each method. Significant gaps remain despite the length.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 8 parameters with 0% description coverage, yet the description does not explain the universal parameters (date, adjust, period, params_json) in the schema. The method listing shows example parameters for sub-functions but does not map to the schema, leaving agents unable to understand how to properly fill parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides A-share fundamental data including financial statements, indicators, forecasts, etc. This distinguishes it from sibling tools like akshare_stock_a, but the structure as a long list of sub-functions detracts from immediate clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 description does not mention scenarios where other sibling tools would be more appropriate, leaving the agent to rely on naming conventions alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It does disclose IP bans (大量抓取容易封IP) for several methods and data recency limitations (只能获取近一年的数据) for one method. However, it does not systematically cover rate limits, authentication, or error behaviors across all methods.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly long due to the extensive method list. While the opening line is concise, the majority is a dense enumeration that could be organized more efficiently (e.g., grouped by bond type). This structure hampers quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity—many sub-methods, 8 parameters, no annotations—the description is incomplete. It lacks guidance on method selection, parameter usage, expected output, and error handling. The presence of an output schema is not leveraged in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It lists method signatures with example parameter values but does not explain the semantics of generic parameters like 'date', 'adjust', 'period', 'symbol', etc. The agent must infer from context, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides bond data including convertible, government, corporate bonds, etc. It distinguishes from sibling tools which cover other asset classes. However, the opening is somewhat broad and the method list is detailed but lacks a concise overarching purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 siblings or which sub-method to choose. The description functions as a catalog, leaving the agent to infer usage. There is no mention of prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It does not disclose any behavioral traits like rate limits, authentication requirements, data freshness, or error handling. The method list implies data retrieval but omits operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is excessively long with over 70 method entries. It front-loads a short summary but then dumps a massive list. Each method's Chinese description adds bulk without concise English guidance. Not efficiently structured for quick agent understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and complex parameters, the description lacks coverage of return values, usage patterns, or typical workflows. The method list provides granular operations but misses overarching context needed for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates by listing method-specific parameters in parentheses (e.g., fund_etf_hist_em(symbol='159707', period='daily')). However, common parameters like 'method', 'date', 'symbol' are not explained generically, leaving ambiguity for agents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it covers mutual fund and ETF data including NAV, yields, quotes, holdings, etc. It distinguishes from sibling tools (e.g., akshare_stock_a) by focusing on fund-related data, but the verb 'provide' is generic and the long method list dilutes clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives. While the tool name and broad category imply fund data, there is no 'when to use' or 'when not to use' advice, nor are sibling tools mentioned for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description includes data time ranges for many methods (e.g., 'data interval from 19800201 to present'), but lacks details on side effects, authentication, rate limits, or data update frequency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is excessively long (100+ lines) with an exhaustive method list. It front-loads a brief summary but the bulk is a verbose, unstructured enumeration that could be summarized or omitted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, many methods), the description fails to cover how to use parameters that are method-specific (e.g., city_first for macro_china_new_house_price) or what the output contains. Even though output schema exists, description doesn't bridge the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; description does not explain parameters (method, date, adjust, period, symbol, end_date, start_date, params_json) at all. It only lists available method names but does not clarify how these parameters affect behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides macroeconomic data for China and international markets, listing numerous specific indicators (GDP, CPI, PMI, etc.) and countries. This distinguishes it from sibling tools like akshare_bond or akshare_stock_a that cover other asset classes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for macroeconomic data but does not explicitly specify when to choose this tool over siblings or how to select among the hundreds of methods. No guidance on context or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Only one method mentions rate limit risk (封 IP), but overall the description lacks disclosures on destructive actions, authentication, or other behavioral traits. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a summary, but the rest is a long list of methods. It is verbose but informative. The structure could be improved with grouping or categorization for faster parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (many methods, 8 parameters), the description enumerates all methods and required parameters. However, it lacks an overarching usage pattern or examples of typical queries. The output schema exists, so return values are not needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It shows method-specific parameter examples (e.g., symbol='000300'), but does not systematically explain each parameter's meaning across all methods. The 'params_json' parameter is introduced but not defined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides stock index data for China and global markets, including historical/real-time values, constituents, and specialty indices. This distinguishes it from siblings like akshare_bond or akshare_fund, which cover different asset classes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs. siblings. The description only lists methods without contextual advice, leaving the agent to infer suitable contexts from the resource type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only vs. mutating, rate limits, authentication requirements, or data freshness. The agent has no explicit information about side effects or access constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy due to the large method list, but it is structured and front-loaded with a clear overview. However, many sentences are Chinese-only descriptions that could be summarized for an English-language agent, reducing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count (8) and absence of annotations, the description covers a wide range of options data methods with concrete examples. It lacks only high-level guidance on when to use specific methods, but overall it is quite complete for a data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Though the input schema has 0% description coverage, the description provides exhaustive documentation for each method via concrete examples and parameter patterns (e.g., symbol='io2202P4350'). This adds high value beyond the generic schema parameters, enabling the agent to construct correct calls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it provides 'Options data: SSE/SZSE ETF options, CFFEX index options, commodity options, option Greeks, margin requirements, and historical option chains.' This clearly identifies the tool's domain and distinguishes it from sibling tools like akshare_stock_a or akshare_futures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description enumerates many methods but offers no explicit guidance on when to use this tool versus alternatives, or which method to choose for a given scenario. The user must infer usage from the method names and Chinese descriptions, which is insufficient for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states 'Returns matching functions grouped by tool name' and that empty query returns full index. Does not mention side effects, auth, or limits, but for a search tool, the disclosed behavior is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each with clear purpose: purpose, usage guidance, empty query behavior. No wasted words; front-loaded with the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple discovery tool with one optional parameter and an existing output schema, the description covers all essential aspects: what it does, when to use, output format, and special case (empty query). No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It explains that the query parameter is a keyword for search and that an empty query returns the full index. Provides useful context beyond schema, though could elaborate on match rules (e.g., case sensitivity).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states purpose: 'Search for akshare functions by keyword across all data categories.' It specifies the verb (search), resource (akshare functions), and scope (all categories), effectively distinguishing from sibling tools that cover specific categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises when to use: 'Use this to find the right function and its parent tool before making a data request.' Also describes behavior with empty query to see full index. Implies alternatives (the specific category tools) but does not explicitly state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![akshare-mcp MCP server](https://glama.ai/mcp/servers/xiaozhozho/akshare-mcp/badges/card.svg)](https://glama.ai/mcp/servers/xiaozhozho/akshare-mcp)

Score Badge

Copy to your README.md:

[![akshare-mcp MCP server](https://glama.ai/mcp/servers/xiaozhozho/akshare-mcp/badges/score.svg)](https://glama.ai/mcp/servers/xiaozhozho/akshare-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/xiaozhozho/akshare-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server