fund_portfolio_hold_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 context about the 'date' parameter behavior (empty string returns latest available year) and return type (DataFrame), but does not disclose potential network dependencies, data source limitations, or column details that might affect usage.

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 and structured as a docstring with source, URL, and param/return documentation. It is front-loaded with the source name and URL, and every line serves a purpose. Some might argue the Chinese is terse, but it is efficient and not 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?

Since there is no output schema, the description needs to explain the return value more thoroughly. It only says '基金持仓' and 'pandas.DataFrame' without detailing columns or types. Given the potential complexity of fund holding data (e.g., stock names, percentages, market values), this is insufficient for an agent to fully understand the response.

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 well. It explains that 'symbol' is a fund code and 'date' is a query year, with a special behavior for empty string. This adds meaningful semantics beyond the raw schema, which only provides types and defaults.

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 identifies the resource: fund holdings (基金持仓) from Eastmoney's fund archive investment portfolio page, with a specific URL. The verb is implied (query/fetch) and the scope is 'fund holdings' which distinguishes it from bond holdings or industry allocation siblings, though it doesn't explicitly say 'stock' holdings.

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 guidance is given on when to use this tool versus alternatives. It does not mention that this is for stock holdings as opposed to fund_portfolio_bond_hold_em or fund_portfolio_industry_allocation_em, nor does it suggest any exclusions or complementary tools. The only usage hint is the parameter explanation.

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