models

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the description need not repeat those. It adds some behavioral context by specifying the ticker requirement (though this contradicts the schema) and supporting quarterly or date-range options. However, it does not describe output behavior, error conditions, or how multiple tickers are handled beyond a comma-separated format, leaving gaps that annotations don't cover.

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 bloated, repeating the full list of indicator names that already exist in the enum. It front-loads the purpose but then dumps the entire enum list in a single paragraph, which is redundant and wastes tokens. A concise reference to the schema or a few examples would be more efficient. The description is not appropriately sized for its content.

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 complexity (25 parameters, many indicator-specific), the description provides only a high-level overview (ticker requirement, quarterly/date support) and a list of indicators. It does not explain which parameters are needed for which indicators (though the schema covers some), nor does it mention that the output schema is available. The description also omits guidance on parameter interactions and fails to resolve the ticker requirement ambiguity, making it incomplete for such a complex tool.

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 100%, but many parameter descriptions are placeholders like 'Value for diluted.' or 'Value for periods.' that add little meaning. The description adds a few useful notes (ticker requirement, quarterly/date support), but it also incorrectly states tickers are required when the schema lists them as optional, confusing parameter semantics. It does not clarify which optional parameters apply to which indicators beyond what the schema already says.

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 states the tool provides 'Pre-computed financial models' and lists the specific models (WACC, DuPont, DCF, etc.), which conveys a specific verb (compute) and resource (financial models). It distinguishes from sibling categories by listing its unique indicators, though it doesn't explicitly name alternatives like 'valuation' or 'profitability' tools, so it lacks a direct differentiation statement.

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 mentions prerequisites ('Requires tickers=...') and options (quarterly, date range), but it does not provide guidance on when to choose this tool over sibling categories (e.g., momentum, liquidity). There is no explicit 'when-to-use' or 'when-not-to-use' advice, and no mention of alternatives, so agents receive little direction on tool selection.

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