Retrieve historical constituent samples for a specified index code from China Securities Index. Use it to analyze past index composition and changes over time.
国证指数-样本详情-历史样本 https://www.cnindex.com.cn/module/index-detail.html?act_menu=1&indexCode=399001 :param symbol: 指数代码；"399001" :type symbol: str :return: 历史样本 :rtype: pandas.DataFrame
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No | 399001 |
Changes observed during successful MCP inspections.
v0.1.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds the source URL and the return type (pandas.DataFrame), which is genuine context beyond annotations, but says nothing about date ranges, pagination, or scope of the history returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a raw docstring dump: a title, a URL, a :param/:type block and a :return/:rtype block. The leading resource name is front-loaded, but the URL and rtype line add bulk without much decision 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?
For a one-parameter, no-output-schema lookup tool, the description covers the input meaning and return type, which is roughly adequate. It stops short of describing what the historical sample rows contain or how they are ordered, leaving the agent to discover the payload manually.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema supplies no meaning for the single parameter. The description compensates by naming symbol as the index code (指数代码) and giving a concrete example ('399001'), which is enough to call correctly even if format rules are not fully specified.
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 conveys that it returns historical constituent samples (历史样本) of a CNI index, with the example code 399001. However, it does not distinguish this from close siblings like index_detail_cni (current samples) or index_detail_hist_adjust_cni (historical adjustments), so the agent cannot confidently route among them from the text alone.
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 when-to-use guidance, no prerequisites, and no mention of alternatives. The agent must infer from the name alone that this is the historical-sample variant of the CNI index detail family.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.