fund_financial_fund_info_em

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds that the return type is pandas.DataFrame and that the data is historical net value details, which is useful but not extensive. It does not disclose pagination, data coverage, or any other behavioral nuances beyond the annotations.

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 compact, consisting of a title line, a URL, and docstring-style param/return sections. It is structured and not verbose. However, the first line exactly repeats the annotation title, which is redundant and slightly wasteful.

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 simple tool with one parameter and no output schema, the description explains the data source (East Money/TianTian Fund), what the parameter means, and the return type. Yet it lacks details about the returned DataFrame's columns, date range, or any practical limitations. The absence of an output schema means the description should carry more return-structure information.

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?

With 0% schema description coverage, the description compensates by explaining that 'symbol' is a financial fund code obtainable via ak.fund_financial_fund_daily_em(). This adds the essential meaning and a useful cross-reference. It does not specify the code format or provide examples beyond the default, but it provides a functional description for the single parameter.

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 states the resource as '理财型基金收益-历史净值明细' (financial management fund returns - historical net value details), which identifies what data is retrieved and distinguishes it from other fund-related siblings. However, there is no explicit verb like 'get' or 'fetch' – the purpose is stated as a noun phrase that mirrors the title, leaving the action implicit.

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 description implies usage when historical net value details for financial/wealth-management funds are needed. It also cross-references ak.fund_financial_fund_daily_em() to obtain the symbol, giving partial context. However, it does not explicitly state when to use this tool over sibling functions like fund_money_fund_info_em or fund_open_fund_info_em, nor does it provide exclusion criteria.

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