Retrieve extended Kitchin cycle data from 1919 onward, combining industrial production, manufacturer inventories, and M2 into annual-frequency JSON arrays.
基钦周期 FRED 扩展版（1919~），工业生产+制造商库存+M2，年频JSON数组
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
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 transparency burden. It discloses the output format (JSON array), annual frequency, starting year, source (FRED), and the three constituent indicators. It does not discuss update behavior or missing-data handling, but for a parameterless read-only data tool these are the key behavioral facts.
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 compact sentence that front-loads the tool identity, then provides period, components, frequency, and format. Every phrase carries meaningful information with no filler or repetition.
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 no-parameter data retrieval tool with an output schema present, the description is complete enough: it gives the identity, time range, source, frequency, and content of the returned JSON array. An agent can select and invoke this tool correctly based on the description alone.
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 properties, and 0-parameter tools have a baseline of 4. There are no parameters to document, and the description instead usefully clarifies what the returned data contains.
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 identifies the resource as the extended FRED-based Kitchin cycle dataset, specifies the period (1919~), the component series (industrial production, manufacturer inventories, M2), frequency, and output format. It lacks an explicit retrieval verb and does not name the sibling data_kitchin, but the 'extended' qualifier and component list make the tool's role reasonably distinct.
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 explicit statement of when to use this tool versus alternatives such as data_kitchin or kitchin_cycle. However, the description implies its usage context: it is the extended/annual-frequency Kitchin dataset with extra M2 coverage, so selection is left to inference rather than direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.