get_intraday_minute_kline

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

With no annotations, the description carries the full behavioral burden. It does disclose useful context: data is limited to the current trading day, the upstream source (Sina/Tencent via AshareDataSource), and the exact returned columns. It does not cover behavior outside trading hours, rate limits, error cases for non-A-share codes, or result volume, which leaves meaningful gaps for a data-fetch tool.

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 one-line purpose is front-loaded, then structured Args/Returns blocks that are easy to scan. The 'same as get_realtime_quote' cross-reference and the redundant restatement of 'today only' twice are slight waste, but nothing is bloated.

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?

No output schema and no annotations exist, so the description is the only source of truth, and it does provide return columns and format choices. Remaining gaps are edge-case behavior (non-trading days, invalid codes, empty results), which keeps it from fully covering a 3-parameter data tool.

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 description must compensate, and it largely does: all three parameters are explained, including the full set of valid frequency values and defaults ('5m') plus format options ('markdown' | 'json' | 'csv', default markdown). The code parameter is only described by deferring to get_realtime_quote rather than giving accepted formats, which is a real but minor shortfall.

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 and resource ('Fetches intraday minute K-line data for a Chinese A-share stock') and pins the scope with '(today only)', which distinguishes it from the historical K-line sibling. It does not name the sibling alternatives (e.g. get_historical_k_data or get_realtime_kline) explicitly, so differentiation is inferable rather than stated.

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?

The '(today only)' qualifier and the enumerated frequency choices imply when this tool is appropriate versus historical data, but there is no explicit when-to-use/when-not section or named alternative. An agent must infer the routing decision from the scope note.

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