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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is known. The description adds genuinely useful context beyond them: the ~20-year data horizon, annual/quarterly granularity, and the $0.005 USDC per-call x402 payment model, which is essential for an agent to invoke it. It stops short of describing rate limits or response shape.

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?

Purpose and data scope are front-loaded, followed by cost. The long metric enumeration is dense but each item tells the agent what data is available (partially substituting for the absent output schema), so little is wasted, though it could be tightened.

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?

For a 3-parameter tool with no output schema and low schema coverage, the field enumeration effectively communicates the return surface, and the cost/payment note covers a key operational requirement. Minor gaps remain around ticker formatting and the years parameter's behavior.

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 coverage is only 33% — period is the sole documented parameter. The description restates the period choice ('annual or quarterly', matching the schema) and its 'up to 20 years' phrasing loosely bounds the years parameter, but it never explains the ticker format or years default/range. Partial compensation for the coverage gap justifies a mid score.

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?

Names a specific resource (reported financials for US public companies) plus the data source (XBRL) and enumerates the exact metrics returned. It is easily distinguished from siblings like sec_search, sec_events, and filings without opening the schema.

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 when the tool is useful by listing the financial metrics it provides, but it never states when to prefer it over alternates such as sec_search or report_stock, nor any exclusions (e.g., non-US issuers). Guidance is inferable but not explicit.

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