fund_scale_daily_szse

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds important behavioral context beyond this: the return type (pandas.DataFrame), the date format requirement, and the critical edge case that date ranges exceeding 6 months return an empty DataFrame with headers. This helps the agent anticipate failure modes.

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 structured docstring that is reasonably sized, but the opening title redundantly restates the tool name. The key behavioral constraint (6-month limit) is placed near the end rather than front-loaded. The URL adds reference value but could be omitted for brevity. Overall it is organized but not maximally concise.

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?

With no output schema, the description explains the return type (DataFrame) and the edge-case behavior (empty DataFrame when range > 6 months), which covers the most critical aspects. It also states the data source and fund categories. However, it lacks column-level details (e.g., fund code, name, scale value) and doesn't discuss pagination or data update frequency, leaving some gaps for complex use cases.

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 is the only source of parameter meaning. It explains start_date and end_date with format examples ('20260401') and symbol with allowed choices {'ETF', 'LOF', 'REITS'}. This compensates well for the bare schema, though it doesn't elaborate on the semantic range meaning beyond the labels 'start date' and 'end date'.

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 states it provides SZSE fund scale daily data ('深圳证券交易所-基金产品-基金规模-日频数据' and '返回: 深交所基金规模日频数据'). It identifies the resource (fund scale) and frequency (daily) despite lacking an explicit imperative verb like 'get' or 'fetch'. It implicitly distinguishes from siblings like fund_etf_scale_szse by supporting ETF, LOF, and REITS categories.

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. It does not mention when to prefer this over fund_etf_scale_szse or fund_scale_change_em. The date range limitation is disclosed but not framed as a usage criterion. There is no 'when not to use' or alternative tool references.

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