get_financials

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

With no annotations at all, the description carries the full behavioral burden, and it discloses little beyond a caveat that Cashflow/DuPont are 'related indicators, not a full statement or a verified decomposition.' It says nothing about data source reliability, whether results are cached or delayed, pagination via count, or what the response contains.

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 text is short with no filler, but it is not front-loaded: the opening sentence points at an external tool reference the agent cannot resolve before any statement of what this tool does. The useful information (kind values, the Cashflow/DuPont caveat) arrives after that weak lead.

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?

A 9-parameter tool with no annotations, no output schema, and zero schema description coverage needs a much richer definition. As written, an agent cannot determine valid date/period semantics, what count controls, or how the six kind modes differ in output shape.

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% across 9 parameters, so the description must compensate and largely does not. It documents the kind vocabulary and vaguely alludes to 'period filters,' but leaves code, start, end, year, quarter, as_of, count (default 120), and format completely unexplained, including their interaction.

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 never states a verb or resource directly; purpose must be inferred from the 'kind=financials/profit/growth/balance/cashflow/dupont' enumeration and from a reference to an external 'a-share-data fetch_history' tool that the agent cannot see. An agent can guess this retrieves financial indicator data for a stock, but the definition itself does not say so.

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?

'Legacy Baostock tools remain available' only hints that alternatives exist (get_fina_indicator, get_profit_data, get_balance_data, etc. are siblings) without saying which to prefer or when. There is no when-to-use or when-not-to-use statement, and no explanation of how the kind values map to those sibling tools.

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