financial_calculator

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds context about parameter formats (e.g., rate in percent, compounding_frequency options) but does not disclose behavior like validation, edge cases, or what happens with invalid calc_type. It does not contradict annotations, so a 3 is appropriate.

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 structured as a docstring with a clear list of parameters, each with concise definitions. It is moderately sized and front-loaded with the tool's purpose before diving into args. No wasted sentences, though the parameter list could be tightened by clarifying 'amount' without adding length.

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?

The tool has an output schema (not shown) but the description does not explain the return format or how results vary by calc_type. It also does not specify which parameters are required for each calculation mode, leaving an agent to infer that principal/rate/time are needed for interest and EMI, while percentage may need amount. This is a meaningful gap for a multi-mode calculator, making the description adequate but not 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?

With 0% schema description coverage, the description carries the full burden for parameters, and it largely succeeds. It explains calc_type values, rate as annual percent, time in years, compounding_frequency options, and principal. However, 'amount' is only described as 'Optional secondary parameter,' which is vague and does not clarify its role across different calc_type modes (e.g., percentage vs. EMI). Despite this gap, it adds significant meaning beyond the bare schema.

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 it calculates financial metrics and enumerates specific types (simple interest, compound interest, loan EMI, percentages), which distinguishes it from sibling math/stats tools. It is specific about the resource and verbs, though it doesn't explicitly contrast with siblings like evaluate_math_expression or calculate_statistics.

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 usage by listing the calc_type options and parameter meanings, but it does not state when to prefer this tool over alternatives, nor does it mention exclusions (e.g., 'for general math use evaluate_math_expression'). The guidance is implicit rather than explicit.

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