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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, and the description layers on real context the annotations cannot express: data is live SEC EDGAR XBRL, values are as-reported rather than adjusted, and non-standard filer concepts surface as 'not reported'. It also discloses that CSV and XLSX artifacts come back alongside the structured values.

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?

Front-loaded with the trigger condition and usage limits, and no sentence is filler. The one inefficiency is the long enumeration of returned fields (revenue through diluted EPS) and the CSV/XLSX mention, which partly duplicates the declared output schema.

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 an output schema, four annotations and full parameter documentation, the remaining burden on the description is purpose, routing and data caveats — and it covers all three, including the key 'as reported, not adjusted' and 'not reported' gotchas that would otherwise cause the agent to misread results.

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%, so the schema already explains 'years' (1-10, default 5), 'period' (annual vs quarterly) and 'company' (ticker or name) with examples. The description only echoes this at a high level ('annual or quarterly period', 'net income by year') without adding syntax or edge-case guidance beyond what is already documented.

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?

States a specific verb and resource ('get company financials from SEC filings') and enumerates the concrete outputs (revenue, net income, assets, liabilities, cash, operating cash flow, diluted EPS) plus formats. This is unmistakably distinct from the sibling find_latest_filings, which retrieves filings rather than extracted financial line items.

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?

Explicitly frames the trigger condition ('Use this when the user wants company financials or revenue history... for a US public company') and gives concrete example intents (10-K revenue, net income by year, statements download). It also states hard exclusions — 'Do not use for share prices, forecasts, or investment advice' — which cleanly routes off-topic requests away.

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