get_price_history

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

With no annotations, the description carries the full behavioral burden. It discloses that unsupported sources are skipped and that raw/qfq/hfq adjustment is contractually explicit, which is useful, but it omits caching behavior (despite a no_cache parameter), rate limits, auth, failure modes, and return shape. It also names three data sources that do not appear as any input parameter, leaving the agent unable to control or predict which source is used.

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 text is short but not efficient: it opens with a comparison to an external artifact rather than the tool's own function, and phrases like "matches the skill" and "history route/fields" convey nothing to an agent that lacks that context. Sentences are not front-loaded around the primary action.

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?

An 8-parameter data-retrieval tool with no annotations and no output schema needs the description to explain parameter meaning, source selection, and return shape. Instead it spends its budget on internal cross-references and leaves the majority of inputs and all output expectations unexplained.

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% across 8 parameters, so the description must compensate. It only clarifies the adjust parameter's raw/qfq/hfq vocabulary; code, start, end, count, frequency, format, and no_cache are left entirely undocumented. One of eight parameters covered is a clear shortfall against the low-coverage baseline.

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 name plus the phrase "history route/fields" and the mention of Tencent/Sina/Eastmoney with "explicit adjustment support" lets an agent infer this returns historical price bars. However, the description never states a verb+resource plainly and leans on an opaque internal reference ("a-share-data fetch_history") rather than saying what data is returned. It does differentiate from one sibling by noting get_historical_k_data is the legacy Baostock path.

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 only routing hint is that get_historical_k_data "retains Baostock's explicit adjustment semantics," implying this is the preferred modern path, but the description never says when to choose this over get_intraday_minute_kline, get_realtime_kline, or get_adjust_factor_data. No prerequisites, no exclusions, no fallback guidance are given.

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