calculators

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

The description discloses the key assumption of no further contributions, but it does not disclose other behavioral aspects such as whether the result is adjusted for inflation, how volatility is treated, or what format the output takes. With no annotations, this gap leaves some behavior undefined.

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 entire description is one efficient sentence that front-loads the key purpose and definition. There is no waste or redundancy, and the dash-separated definition adds clarity.

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 (10 parameters, no output schema, no annotations), the single-sentence description is insufficient. It does not describe the output, edge cases, or financial assumptions beyond the no-contribution condition. For a financial calculator, more contextual guidance is needed.

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?

The description provides no parameter-specific explanations. With 10 parameters and 0% schema description coverage, it fails to explain how current_savings, annual_expenses, or rates impact the calculation, leaving the agent to rely solely on schema names.

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 uses a specific verb 'Compute' and names the exact resource 'Coast FIRE milestone', defining it as the capital needed today to compound to retirement target. This clearly differentiates from sibling 'calculate_fire_target' which likely computes the full target, not the coast milestone.

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 for Coast FIRE calculations but does not explicitly state when to use it over siblings like calculate_fire_target or project_wealth_plan. No exclusions or alternative guidance is given, though the definition makes the intended context reasonably clear.

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

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 disclosure. It mentions Monte Carlo simulation and returns a probability, but it does not clarify whether the output is the target amount, the probability, or both, nor does it disclose assumptions, determinism, or limitations. This ambiguity is significant for a tool with no output schema.

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 concise and front-loaded, with two sentences that directly state the purpose and method. No wasted words or redundant details.

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 tool with 8 parameters and no output schema, this description is incomplete. It does not explain the output format, the role of inputs like current_savings or portfolio_volatility, or the simulation's assumptions. The tool's complexity demands more context than 'runs Monte Carlo and returns probability' provides.

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?

The description adds no parameter-level semantics beyond the schema. Several parameters (inflation_rate, apply_inflation) lack full descriptions in the schema, and the description does not compensate or explain how parameters relate to the simulation. With 63% schema coverage, the description should provide additional context but does not.

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's function with a specific verb ('Estimate') and resource ('savings target needed for Financial Independence / Early Retirement'), and further distinguishes it by mentioning Monte Carlo simulation and probability of survival. This differentiates it from sibling tools like calculate_coast_fire, which likely focuses on a different FIRE metric.

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 provides clear context for when to use this tool: when estimating a FIRE savings target with probabilistic simulation. However, it does not explicitly state when not to use it or mention alternative sibling tools, so it stops short of a full 5.

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

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 disclosure. It explicitly states the educational nature of the estimate and lists what is not modeled (commune surcharges, deductions), adding context about scope and limitations. However, it does not describe the output format or edge-case behavior (e.g., capital losses), preventing a perfect score.

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?

Two sentences, front-loaded with the main purpose, followed by scope and limitations. Every sentence earns its place with no redundancy or filler.

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 complex tool covering 26 cantons with holding-period adjustments and deferral options, the description gives essential context: scope, key components, and limitations. However, it lacks information about the return value (e.g., tax amount in CHF) and how to interpret results, which is notable given there is no output schema to fill that gap.

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 50%: sale_price and purchase_price are not mentioned in the description, though their names are self-explanatory. The description adds meaning for years_held ('holding-period adjustments') and Ersatzbeschaffung ('replacement-residence deferral'), but does not fully compensate for the undocumented parameters or clarify their precise role in the calculation.

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 uses a specific verb ('Estimate') and a precise resource ('Swiss cantonal real-estate capital gains tax') for a property sale. It clearly distinguishes itself from the sibling FIRE/portfolio tools by targeting a niche Swiss tax calculation, covering all 26 cantons.

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?

Clear context is provided: the tool estimates Swiss cantonal capital gains tax with holding-period adjustments and Ersatzbeschaffung deferral. The limitation 'Educational estimate; commune surcharges and value-enhancing-improvement deductions are not modeled' signals when not to rely on it, though it does not explicitly name alternative tools or exclusion criteria beyond these limitations.

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

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 disclosure. It reveals that profiles are derived from real index data and consist of (return %, volatility %) pairs, which is helpful but omits details like data time period, number of profiles, or response structure.

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 two sentences long and front-loaded with the verb 'Return' and the resource. Every sentence earns its place: one states what the tool does, the other explains why it's useful.

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 tool with one parameter and no output schema, the description adequately explains the return concept (a pair of percentages) and the data source. It falls slightly short of a 5 because it doesn't specify the shape or cardinality of the returned profiles (e.g., array, object, count).

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?

The schema already documents the single currency parameter with a clear description and enum, covering 100% of parameter meaning. The description adds minimal semantic value beyond mentioning currency, so the baseline score of 3 is appropriate.

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 explicitly states the tool returns historical portfolio return profiles for a currency, specifying the resource and scope. It also distinguishes itself from sibling calculation tools by positioning itself as the data source for assumptions in calculate_fire_target and project_wealth_plan.

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 clearly indicates when this tool is useful—grounding assumptions in calculate_fire_target and project_wealth_plan. It does not explicitly state when not to use it or offer alternative tools, but the named consumers provide strong contextual guidance.

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

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

With no annotations, the description carries the full burden and does well. It discloses the regional tax model (US 2026 brackets vs flat rate), optional phase switch and property sale, and the default vs full output behavior via yearly_detail. It does not cover edge cases or assumptions, but for a read-only computation tool this is substantial behavioral context beyond the schema.

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 two sentences, front-loaded with the primary action, followed by model details and output behavior. Every clause adds information with no redundancy or off-topic 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?

For a tool with 28 parameters and no output schema, the description is thorough: it covers scope, modeled components, regional tax differences, and output format. It does not specify exact fields in the summary or milestones, but it is sufficient for an agent to understand the tool's role and toggle yearly_detail. Slightly more detail on return structure would make it a 5.

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 57%, and the description adds context for some parameters (e.g., 'growth→income phase switch' maps to portfolio_switch_enabled/year, 'optional property sale' maps to property_sale_enabled/year, 'region-aware tax' maps to region). However, many parameters receive no added meaning from the description, leaving the agent to rely on schema descriptions or defaults for obscure fields like partner_early_death_years_before_end.

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 runs a full year-by-year Wealth Plan projection for a household, with a specific verb ('Run') and resource. It enumerates modeled components (income, pensions, expenses, portfolio growth, phase switch, mortgage, property sale, taxes), which distinguishes it from siblings focused on standalone FIRE calculations, property tax, or portfolio returns.

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 for comprehensive household wealth projections by outlining the modeled scenarios and output options, but it does not explicitly mention alternatives or exclusions. An agent can infer this is for full projections rather than single-purpose calculations, but explicit comparison to siblings is absent.

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

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

With no annotations, the description carries the transparency burden. It discloses key behaviors: computes exact trades, flags foreign-cash overdrafts, and explicitly states it is planning math only with no transaction costs or taxes. This clarifies limitations and side effects (none destructive), though it doesn't detail edge-case handling.

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 two sentences, front-loaded with the main action and outputs, followed by a concise qualifier. Every phrase earns its place with no redundancy or filler.

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?

Despite no output schema, the description names the three output components (trades, cash movements, summary) and the main behavior. It is complete for a planning tool given a rich input schema, though it does not detail the structure of the returned trades or summary objects.

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%, so baseline is 3. The description adds meaning by clarifying that target weights can be per-holding or per-asset-class (class_targets), and that cash and FX rates are inputs, linking parameters to their purpose in the rebalancing workflow.

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 rebalances a multi-currency portfolio, enumerating inputs (holdings, target weights, cash, FX rates) and outputs (BUY/SELL trades, cash movements, summary). The verb 'rebalance' is specific and distinguishes it from sibling tools like retirement calculators or property tax computations.

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 provides clear context on when to use the tool by specifying required inputs and the planning-only scope ('Planning math only — no transaction costs or taxes'). It does not explicitly name alternatives or when-not-to-use scenarios, but the context is sufficient for differentiation from siblings.

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