Retrieve daily OHLCV K-line data for a stock market index over a specified date range using Tushare.
Get index daily K-line data (Tushare API: index_daily).
Args:
index_code: Index code (e.g., "000300.SH" for CSI 300, "000001.SH" for Shanghai)
start_date: Start date in YYYYMMDD format
end_date: End date in YYYYMMDD format
Returns:
dict: Index OHLCV data
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | No | ||
| index_code | Yes | ||
| start_date | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, yet it only says it returns OHLCV data. It omits anything about Tushare token/points requirements, rate limits, or what an empty date range does, all of which matter for a data-fetch tool with no annotation safety net.
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?
Front-loaded purpose followed by a clean Args/Returns docstring layout with no filler. Every line is functional, though the Returns line is nearly redundant with the purpose line.
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 simple three-parameter read tool with no output schema or annotations, the description is minimally adequate: it covers purpose, parameter formats, and a rough return shape. It still leaves auth/tier requirements and empty-date-range behavior unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description does compensate partially by giving the YYYYMMDD date format and real index_code examples (000300.SH, 000001.SH) that the schema lacks. It fails to explain the default empty-string values for start_date/end_date, leaving the coverage gap only half closed.
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?
States a specific verb (Get) and resource (index daily K-line) plus the upstream Tushare API name. The 'index' scope implicitly separates it from tushare_get_daily_price/weekly_price, but no sibling is named explicitly, 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?
There is no guidance on when to use this versus tushare_get_daily_price or tushare_get_index_components, no mention of prerequisites, and no exclusions. The agent must infer the use case purely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.