bonus

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes a data retrieval operation ('获取' - get/fetch) which implies read-only behavior, but doesn't mention authentication requirements, rate limits, error conditions, or what format the data returns. For a tool with no annotation coverage, this leaves significant behavioral questions unanswered.

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 efficiently structured with a clear purpose statement followed by parameter explanations. Each sentence serves a purpose: the first states what the tool does, and the next three lines explain each parameter. There's no wasted text, though it could be slightly more polished in formatting.

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 data retrieval tool with 3 parameters and no output schema, the description covers the basic purpose and parameters adequately. However, it doesn't explain what 'F10 dividend financing data' actually contains, what format it returns, or how to interpret the results. With no annotations and no output schema, users need more context about what they're getting and how to use it.

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?

The description provides clear semantic explanations for all 3 parameters: 'stock_code: 股票代码' (stock code), 'page: 第几页 默认1' (which page, default 1), and 'size: 每页含有多少数据 默认10' (how much data per page, default 10). With 0% schema description coverage, the description fully compensates by explaining what each parameter means and their defaults, adding significant value beyond the bare schema.

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 '获取F10分红融资数据' which translates to 'Get F10 dividend financing data' - this provides a clear verb ('get') and resource ('F10 dividend financing data'). However, it doesn't distinguish this tool from its many siblings (like 'balance', 'cash_flow', 'income', etc.) which also appear to be financial data retrieval tools. The purpose is clear but lacks sibling differentiation.

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 provides no guidance on when to use this tool versus alternatives. With 50+ sibling tools on the server (including 'balance', 'cash_flow', 'income', 'holders', etc.), there's no indication of what makes this tool distinct or when an agent should choose it over other financial data tools. The description is purely functional without context.

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