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 transparency. It adds useful context by noting that the fourth quarter is derived from the annual report, that figures are from the company's own XBRL filings, and that balance sheet values are 'instants'. However, it does not disclose limitations such as data coverage depth, currency, units, or potential missing periods.

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 a single dense sentence with no filler words; every clause contributes specific metric or source information. It is front-loaded with the most prominent quarterly metrics. The long list format is slightly unwieldy, especially at the end, but it remains concise for the amount of information conveyed.

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 a single parameter and no output schema, the description does a good job of telling the agent what data will be returned: quarterly and annual income statement metrics, cash flow items, capital returns, and balance sheet instants. It also explains a subtle derivation rule for Q4. Minor gaps include exactly how far back data goes and whether values are in millions or as reported, but the core calling context is complete.

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%, and the schema already explains the symbol parameter with examples and the class-share convention like BRK-B. The tool description adds no additional parameter semantics beyond what the schema provides. The baseline of 3 applies because the schema fully documents the only parameter.

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—company financials from SEC XBRL filings—and enumerates the specific metrics returned. It distinguishes itself from sibling market-data tools by focusing on company-reported financial statements. However, it lacks an explicit operative verb like 'returns' or 'retrieves', relying on the title and list format.

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 implies this tool is for fundamental company financials by listing revenue, EPS, cash flow, buybacks, and balance sheet items. It does not name any sibling tools or state when to prefer this over alternatives such as earnings_calendar or macro_series. There is no explicit exclusion or when-not-to-use guidance.

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