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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'get' data, implying a read-only operation, but does not explain output behavior, pagination, default record count, or any quirks. It does not contradict annotations (since there are none), but it provides minimal behavioral context.

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 extremely concise, a single sentence with no filler or redundancy. It is front-loaded with the core action. However, it is so terse that it sacrifices clarity and completeness, which is a minor structural issue but still efficient.

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?

Given the tool's simple schema (2 params) but the large set of sibling balance-sheet tools, the description lacks necessary context about the exact type of balance sheet data and when it should be used. Without annotations or an output schema, the description leaves the agent with insufficient information to fully understand the tool's role and output.

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 100%, with both symbol and recent_n well-described in the input schema. The description adds no additional parameter semantics or context beyond the schema. Baseline 3 is appropriate because the schema handles parameter documentation, and the description contributes no extra value.

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 a specific verb and resource ('Get company balance sheet data'), but it is vague and does not distinguish from numerous balance sheet siblings like getBalanceSheetStatement, getBalanceSheetStatementTTM, and getBalanceSheetStatementAsReported. It lacks specificity about the period, format, or scope of the data returned. Overall the core purpose is clear but under-specified.

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 provided about when to use this tool versus the many balance-sheet and financial-statement siblings. There is no mention of exclusions or alternatives, so an agent cannot determine if this is the right tool for a given request. It only describes what it does, not when to choose it.

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