get_history_k_data

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It explains behavior: frequency options, adjustflag meanings, date format, and fields auto-selection. However, it lacks details on return format, pagination, error behavior, or data source, leaving gaps.

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?

Description is short and front-loaded with main purpose. Uses compact style but conveys essential information. Could be slightly more structured for readability.

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?

Covers key parameters and return columns for specific frequencies, but lacks details on default behavior for omitted parameters, data range limits, error handling, and overall completeness for a tool with 6 parameters and no output schema.

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%, so description compensates well. Explains adjustflag values, frequency options, date format, and fields override mechanism. Only missing explanation for code format (e.g., stock symbol pattern).

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?

Description clearly states tool retrieves historical K-line bars. Provides specific details on frequency, adjustflag, dates, and fields, distinguishing it from sibling tools that retrieve other data types like fundamental factors or stock lists.

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 among the many sibling tools. Usage details are given but no comparison or exclusion criteria, leaving the agent to infer context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.