Fund Flow

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

With no annotations, the description carries the full burden and does so well: it discloses T+1 lag, that dates follow actual API return, the output contract (cite numbers as-is with units and dates), the explicit exclusion of northbound net-inflow figures since 2024-08-19, a fact-only/no-recommendation policy, and the data source. It omits auth/rate-limit behavior, keeping it short of a 5.

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 content is front-loaded with the overall purpose, then structured into per-kind blocks and an output contract. Length is justified by the two-mode design, though the parenthetical skill reference and source-date note add mild noise.

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 output schema exists, so return formatting need not be restated, yet the description adds the essential output contract and a hard boundary (no northbound net-inflow numbers). For a 2-parameter, no-annotation tool this is nearly complete; only the sibling overlap and auth context are unaddressed.

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 must compensate, and it does: kind='margin' is documented as requiring code and returning margin-balance fields, while kind='lhb' documents an optional code and its Top5 output. The default values themselves are left to the schema, but the semantic meaning of both parameters is fully conveyed.

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 names the resource (资金流向) and specifies two distinct modes via kind='margin' (per-stock margin trading) and kind='lhb' (market-wide dragon-tiger list), each with concrete returned fields. It is clear what the tool does, but it never distinguishes itself from the overlapping sibling lhb_board, which appears to cover the same 龙虎榜 domain.

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?

Usage is only implied through the kind branches: margin requires code, lhb allows an empty code. There is no explicit when-to-use-this-vs-alternatives guidance, and the presence of the sibling lhb_board makes the lack of routing language a real gap.

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