HomeCalc — Canadian Mortgage & Tax Calculators

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

Annotations already establish that this is a read-only, non-destructive calculation. The description adds valuable behavioral context beyond that: the 20%-to-0% taper, the 366-730 day range, and the $20,000 deduction condition. It does not specify the exact return shape or edge-case behavior, so it falls short of a 5.

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 a single, front-loaded sentence with no filler. Every clause contributes either jurisdiction, scope, rate schedule, or deduction eligibility.

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 simple three-parameter calculator with no output schema, the description provides the essential formula and eligibility rules. It is nearly complete, though it could clarify the exact return value and treatment of edge cases such as sales outside the 730-day window.

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 all three parameters are already documented. The description still adds computational meaning by tying the taper to days held and conditioning the deduction on holding at least 365 days, which helps interpret `daysHeld` and `isPrimaryResidence` beyond their schema text.

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 states a specific verb and resource: estimating British Columbia's home flipping tax. It adds scope and the exact tax-rate structure, which clearly distinguishes it from the generic sibling `house_flipping` and other tax calculators.

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?

Usage is implied by the stated 730-day sale window and primary-residence condition, but there is no explicit guidance on when to choose this tool over siblings such as `house_flipping` or `capital_gains_tax`. No exclusions or alternative scenarios are named.

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?

Annotations already declare this is a safe read-only, closed-world computation, so the safety burden is covered. The description adds genuine behavioral substance beyond that: it discloses the deadline rule (11:59 p.m., third business day, skipping weekends and BC statutory holidays) and the fee rate, which tells the agent exactly what the output means. It stops short of describing the output shape or edge cases such as holidays falling on the boundary.

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?

A single dense sentence with the core subject front-loaded, followed by the two outputs. No filler, no repetition of the title, and every clause (date rule, holiday exclusion, fee rate) carries information.

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 two-parameter, closed-world calculator with no output schema, the definition provides enough to call it correctly and understand what the results represent. A slight gap remains: it does not state the output fields or what happens if the acceptance date is a weekend/holiday, but this is minor for a computation this simple.

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%, and the schema already explains the price is used for the 0.25% fee and the date format. The description restates the 0.25% rate and the counting rule but adds little per-parameter detail beyond what the schema provides, so the baseline of 3 applies.

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 names a specific legal/financial computation (BC home buyer rescission period) and states both results it produces: the deadline and the 0.25% fee. It is clearly distinguishable from siblings like bc_home_flipping_tax or land_transfer_tax, which are different BC-specific calculators.

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?

Usage is implied by the stated inputs (a date of acceptance and an accepted price), so an agent can infer it is used after an offer is accepted. However, there is no explicit when-to-use or when-not-to-use guidance, no mention that this applies only to BC residential resale purchases, and no named alternatives.

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?

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), so the description's job is to add computation semantics — which it does: half-year rule, AIIP, post-2024 accelerated incentive keyed to acquisition date, and a 5-year schedule. It also flags the non-obvious rule that CCA can't create a rental loss. It stops short of stating assumptions or rounding/interpretation caveats.

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?

A single dense sentence, front-loaded with the resource and scoping terms, with no filler. It is long and clause-heavy but every clause names a distinct computed output, so little could be cut without losing information.

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?

With 10 parameters (1 required), no output schema, and only a single-sentence description, the enumeration of returned figures (rate, year-1 CCA, tax saving, 5-year schedule, recapture/terminal loss) effectively substitutes for a missing return-value spec. What remains thin is the relationship between optional inputs (existingUCC, disposal fields) and the outputs, but the core is complete for a pure calculator.

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 carries per-parameter meaning and the baseline is 3. The description adds only marginal value — the note that acquisition date selects the half-year/AIIP/accelerated treatment, and the rental-loss cap on netRentalIncomeBeforeCCA — without explaining how existingUCC or disposalProceeds feed the schedule.

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 resource (CRA capital cost allowance on a business or rental asset) and enumerates exactly what it computes: class rate, year-1 CCA with half-year rule/AIIP/accelerated incentive, tax saving, 5-year schedule, recapture/terminal loss. This makes it clearly distinct from siblings like income_tax or capital_gains_tax without opening any 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?

Usage is implied by the domain ('business or rental asset', CRA), and the output list hints at when an agent would want it. However, there is no explicit when-to-use statement and no routing to or away from alternatives such as capital_gains_tax or income_tax, leaving the agent to infer the boundary.

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?

Annotations already declare readOnlyHint/openWorldHint=false/destructiveHint=false, so the safety profile is covered. The description adds real behavioral substance: the 50% inclusion rate, principal-residence and LCGE treatment, loss offsets, CCA recapture, and stacking on top of other income. It omits any caveat that results are an estimate rather than filing-grade tax advice.

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 purpose, then a dense but purposeful list of the tax mechanics applied. Every clause maps to a real capability; the run-on second sentence is long but not padded.

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 19-parameter calculator with no output schema, the description explains the method well but says nothing about the shape of the result (federal vs provincial breakdown, total tax, effective rate, exemption used). An agent cannot tell what it will get back or how to interpret it.

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 every one of the 19 parameters is already documented with types, defaults, enums and meanings. The description adds only topical framing (which asset types and exemptions exist) and no parameter-level detail, so baseline 3 applies.

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 ('Estimate') and resource ('Canadian capital gains tax') and enumerates the covered asset classes, which separates it from income_tax and land_transfer_tax. It does not explicitly name which sibling to use for overlapping scenarios (e.g. BC home flipping), so it falls short of full sibling differentiation.

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?

Usage is only implied by the asset categories and exemption list; there is no explicit 'use this when... / use X instead' guidance. An agent facing a BC-flipping or general-income question gets no routing signal to bc_home_flipping_tax or income_tax.

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?

Annotations already establish readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely non-obvious behavioral detail no annotation carries: mortgage math uses Canadian semi-annual compounding, and the cap rate is benchmarked against typical local yields. It stops short of 5 because it never mentions the down-payment warnings the schema alludes to, nor any failure/validation behavior.

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 domain and the metric list, with the mortgage convention as a trailing caveat. No filler and no restatement of the tool name. Slightly dense as a comma run, but every clause carries information.

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 9-parameter calculator with no output schema, listing the returned metrics plus the compounding convention covers most of what an agent needs to call it and trust the result. The gap is that warning behavior (propertyType is 'used for down payment warnings') and the interpretation of the benchmark comparison are never surfaced in the description.

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 every one of the nine parameters (including the city enum used for benchmarking, and annualOperatingExpenses explicitly excluding mortgage) is already documented in the schema. The description adds only the semi-annual-compounding convention, which is a computation note rather than parameter-level meaning. Baseline 3 applies.

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 names the specific analysis domain (Canadian rental property analysis) and enumerates the exact metrics produced: cap rate, NOI, gross rent multiplier, expense ratio, cash flow, cash-on-cash return. That is far more concrete than the name 'cap_rate' alone. It stops short of 5 because it never explicitly distinguishes itself from the mortgage-oriented siblings (mortgage_payment, mortgage_affordability), leaving the agent to infer the boundary.

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 gives no guidance on when to use this tool versus the eleven siblings, and no prerequisites are stated. An agent must infer that 'Cap Rate & Rental Property Calculator' is chosen over mortgage_payment when full rental-property underwriting is wanted. There are no exclusions and no explicit when-to-use clause.

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?

Annotations already establish that this is a safe, read-only, closed-world calculation, so the safety profile needs no restatement. The description adds useful scope detail (rebates applied, MLTT/NRST triggers, fees broken out separately), but says nothing about the returned breakdown, rounding, or how defaults are applied to untouched cost parameters.

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 is front-loaded in the opening clause, but the remainder is a single run-on parenthetical list that packs a dozen items without grouping or prioritization. It contains no wasted words, yet the density costs scannability.

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 15-parameter calculator with no output schema, the definition covers inputs well via the schema but leaves the response shape unexplained (presumably a cost-by-cost breakdown plus total). An agent knows what goes in, not what comes back.

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%, with all 15 parameters individually documented and three enums constrained, so the schema carries parameter meaning fully. The description reinforces which jurisdictions trigger which taxes, but adds no syntax or semantics beyond the 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 names a concrete outcome (cash needed to close a Canadian home purchase) and enumerates the cost components it aggregates, which distinguishes it from narrower siblings such as land_transfer_tax or cmhc_insurance. It never names those siblings explicitly, but the aggregation framing makes the distinction inferable.

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?

Usage is only implied: this is the all-in closing estimate, whereas sibling tools cover individual components. There is no explicit 'use this instead of X when Y' statement, and no note on when a single-component tool would be preferable or on assumptions (defaults filled in for unlisted costs).

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?

Annotations already establish this as a safe, offline read calculation, so the description focuses on domain behavior instead: the premium is added to the mortgage while provincial sales tax is paid in cash at closing, and only ON/QC/SK levy that tax. That is genuine behavioral nuance an agent could not get from annotations, though edge cases (insurable price cap, minimum down payment rules) are unstated.

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?

A single front-loaded sentence that names the subject first, then scopes it, then lists outputs. It is dense with parentheticals but every clause carries information; only minor trimming of the nested aside would improve reading flow.

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?

With no output schema, the description usefully enumerates the returned figures (premium rate, premium amount, sales tax, insured mortgage total) so an agent knows what to expect. Remaining gaps are edge-case handling, such as the insurable price ceiling and behavior when down payment is at or above 20%.

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 the baseline is 3; the description earns a bump by clarifying that the province parameter only matters for sales tax and that only ON, QC and SK charge it, which is not apparent from the flat 10-province enum. It says nothing about the firstTimeBuyerNewBuild parameter's 30-year amortization effect beyond what the schema already documents.

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 (CMHC mortgage default insurance premium) plus precise scope (down payment under 20%, Canadian home) and enumerates the outputs: premium rate, premium amount added to mortgage, provincial sales tax, insured mortgage total. This clearly separates it from siblings like minimum_down_payment and insured_insurable_uninsured.

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 'under 20% down payment' condition implicitly defines when the tool applies, which is a real usage constraint. It gives no explicit when-not guidance or named alternatives (e.g., for 20%+ down payments the premium is zero and insured_insurable_uninsured applies), so it falls short of a 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?

Annotations already declare a safe, read-only, closed-world calculation, so the burden is lower. The description does add genuinely useful behavior: commission rates come from province defaults but are overridable, and the output nets out the mortgage payoff. It does not describe the shape of the result (e.g., line-item breakdown vs single total), which matters given 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?

One sentence, front-loaded with the outcome (total cost and what you walk away with), followed by the component chain. It is dense but every clause maps to a real parameter group; the parenthetical is the only slightly awkward element.

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 12-parameter calculator with only one required field and no output schema, the description covers all cost categories and the final net-proceeds step, so an agent can call it correctly with minimal input or with overrides. A brief note on what the response contains would close the remaining 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 coverage is 100%, so every parameter is already documented, and the baseline of 3 applies. The parenthetical 'province starting rates, all overridable' and the ordered cost chain give the agent a mental model of how province, structure, and the rate overrides interact, but no individual parameter meaning is added beyond the 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 states a specific verb and resource — computing total cost of selling a Canadian home and the net proceeds — and enumerates the cost components (commission + GST/HST, legal fees, discharge fee, other costs, mortgage payoff). This separates it in spirit from buyer-side tools like closing_costs and single-component tools like real_estate_commission, though it never names a sibling explicitly.

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?

Usage is implied by 'selling a Canadian home,' which scopes it geographically and directionally, but there is no explicit when-to-use/when-not guidance or routing to related calculators (e.g., use real_estate_commission for commission alone, closing_costs for the buy side). The agent must infer the boundary.

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?

Annotations already declare this as a non-destructive, closed-world read, so the bar is lower. The description still adds real domain behavior beyond them: the 39%/44% limit thresholds, the 50% condo-fee treatment, and that a qualifying view should use the stress-test-rate payment.

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 tightly packed sentences with the core computation front-loaded and the two domain rules (condo haircut, stress-test rate) following. No filler or restated title.

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?

With 7 parameters and no output schema, the description should say more about what comes back (both ratios, per-ratio pass/fail against the 39%/44% limits) and whether defaults like heating/property tax are applied. The 'against the limits' phrasing hints at a comparison but does not specify the return shape.

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 the baseline is 3. The description goes slightly beyond the schema by explaining the condo-fee 50% haircut in context and by advising that mortgagePayment should reflect the stress-test rate for qualifying purposes, which changes what value the agent should supply.

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 computation (GDS and TDS ratios) from specific inputs (income, housing costs, other debts) benchmarked to the 39%/44% thresholds. It is distinguishable from nearby tools like debt_to_income or mortgage_qualifier by naming the exact ratio pair, though it never names those siblings explicitly.

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 line about using the stress-test-rate payment gives one piece of situational guidance, but there is no explicit when-to-use versus alternatives (e.g. debt_to_income for TDS-only, mortgage_stress_test for rate qualification). Usage is implied rather than routed.

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?

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), so the bar is lower, and the description still adds real behavior: cards/LOCs with no payment silently default to 3% of balance while car and personal loans require their real payment, and the output includes balances, payments, available credit and GDS/TDS against 39%/44% thresholds. It does not mention rounding, currency handling, or what happens when housing costs are omitted.

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 dense sentences with no filler; the default rule appears before the return-value summary, which is the right order. The final clause packs four return items and two thresholds into one sentence, which is efficient but slightly crowded.

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?

With no output schema, the description usefully enumerates the return payload and names the 39%/44% benchmark ratios. For a three-parameter read-only calculator this is close to complete, with only sibling disambiguation and edge-case behavior (missing housing costs, cap of 30 debts) left implicit in the schema.

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 the schema already documents annualIncome, housingCostsMonthly and the nested debt fields including the 'blank = 3% of balance' rule. The description reinforces the default rule and adds the constraint that car and personal loans need their actual payment, which is only partially spelled out in the schema, so it sits at baseline-plus rather than adding substantial new meaning.

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 computation (total debt service ratio) from three named inputs (income, housing costs, itemised debts) and lists what comes back. An agent can tell it is a ratio calculator rather than a mortgage qualifier or generic debt_service_ratio, though the description never explicitly contrasts itself with the debt_service_ratio sibling.

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?

Usage is implied by the input list (you supply income, housing costs and a debt array) and by the domain rules for defaults, but there is no explicit 'use this when...' or exclusion against debt_service_ratio or mortgage_qualifier. The agent must infer the choice from name and inputs alone.

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?

Annotations already establish readOnly, non-destructive, closed-world, so the safety profile is covered. The description adds genuine domain behaviour an agent could not infer: the revolving HELOC is capped at 65% LTV, total secured borrowing at 80% with an A lender, and TDS is assessed at the OSFI stress-test rate, with separate treatment for B and private lenders. It does not disclose how defaults (prime rate, tier rates) are resolved or what the response contains.

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?

A single sentence with the comparison verb front-loaded and no filler. It is dense and slightly run-on in the final clause ('and the same for B and private lenders'), but every clause carries real information.

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 14-parameter calculator with no output schema, the description covers the computational model and enumerates what the result contains (borrowing capacity, monthly payments, TDS qualification, per-lender-tier results). What is missing is how optional defaults are applied and the shape of the returned comparison, which matters given the absence of an output schema.

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% across 14 parameters, so the schema already carries enum meanings, units, defaults and ranges. The description adds framing by tying the inputs to the 65%/80% LTV and OSFI stress-test logic, but does not explain specific parameters such as helocSpreadPct or secondMortgageLenderTier beyond what the schema states. Baseline 3 applies.

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?

Specific verb and resource: 'Compare a HELOC with a second mortgage for tapping home equity in Canada', with the exact outputs named (borrowing limit, monthly payments, TDS qualification). It does not name a sibling, so an agent must infer that mortgage_affordability and mortgage_payment are different tools, but the HELOC/second-mortgage framing is narrow enough to be unambiguous.

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?

Usage is only implied by the described computation – the agent can infer this is the tool for equity-tapping comparisons rather than a plain mortgage payment or affordability calculation. There is no explicit 'use this when…' statement, no prerequisites, and no exclusions relative to mortgage_affordability or mortgage_payment.

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?

Annotations already establish that this is a safe, read-only, closed-world calculation, so the burden is light. The description nonetheless adds real behavioral context beyond them: it names the CRA 12-month flipping rule, that under 12 months means 100% business income with no capital gains treatment, and that the output quantifies the tax saved by waiting. It stops short of stating that holdingPeriodMonths drives that flag or of noting it is an estimate, not tax advice.

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, both dense and front-loaded with the calculation scope, followed by the tax-rule caveat. Every clause maps to a real feature of the tool, though the second sentence runs long and packs the CRA rule and the 12-month comparison together.

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 13-parameter calculator with no output schema, the description covers the major cost lines and the key tax behavior the agent needs to interpret results. It does not describe the shape of the returned breakdown or how the tax-savings figure is expressed, which is the main remaining 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 100%, so the baseline is 3 and the schema already carries per-parameter meaning. The description adds a level of semantic mapping on top by calling out the land transfer tax with first-time buyer rebate, renovation contingency, holding costs, realtor commission, and closing costs, which lets an agent connect inputs to outputs before opening the 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?

States a specific verb and resource ('Estimate profit on a Canadian house flip') and enumerates the cost components the calculation covers, so an agent knows exactly what the tool computes. It does not, however, distinguish itself from the sibling bc_home_flipping_tax, which overlaps on the BC case that this tool's province enum also accepts.

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?

Usage is only implied: an agent can infer this is for pre-flip profit modeling, but the description never says when to pick it over bc_home_flipping_tax, land_transfer_tax, or capital_gains_tax, nor what inputs are prerequisites. No exclusions or alternative-routing guidance is given.

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?

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is settled and the description does not need to repeat it. In exchange it discloses what is actually modeled — CMHC insurance in the mortgage, ownership costs, vacancy-adjusted rent, an income-tax estimate option, and qualification with/without rental add-back — which is real behavioral context. It does not say whether results are illustrative estimates or how provincial rules change the math.

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?

A single dense sentence that front-loads the core scenario before listing outputs. Every clause maps to a distinct output dimension, so nothing is filler, though the parenthetical strategy list and the colons make it slightly harder to scan than a short multi-sentence structure would be.

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 17-parameter calculator with no output schema, the description does the important job of telling the agent what comes back: cost comparison, vacancy-adjusted rent, CMHC-inclusive mortgage, and qualification income. It omits how optional inputs like province, marginalTaxRatePct, and equivalentRentMonthly shape the result, but the fully documented schema covers those, leaving no blocking 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 100% across all 17 parameters, including enums for strategy and province and the 25/30 amortization constraint, so the schema carries parameter meaning and the baseline is 3. The description adds conceptual framing (rent after vacancy, rental add-back qualification) but no parameter-specific guidance beyond what the schema already states.

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 names a concrete scenario (live in one unit, rent the rest) and enumerates the outputs produced: CMHC mortgage, ownership costs, post-vacancy rent, true monthly cost vs renting, and qualification income with and without rental add-back. That is clearly a house-hacking analysis tool, not a generic mortgage or rent-vs-buy calculator. It stops short of naming sibling tools such as rent_vs_buy or mortgage_qualifier to draw the boundary explicitly.

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?

Usage is only implied by the enumerated outputs — an agent can infer this is for owner-occupied multi-unit purchases, especially with CMHC and rental add-back qualification. There is no explicit when-to-use statement, no exclusions (e.g. not for pure investment properties, not for single-family non-rented homes), and no routing to rent_vs_buy or mortgage_qualifier for simpler cases.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds meaningful context beyond that: the 2026 tax-year basis, the exact deduction programs modelled, and the Quebec/Ontario-specific extras. It does not disclose the shape of the result (breakdown vs. single number) or accuracy caveats, so it falls short of a 5.

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?

A single front-loaded sentence that enumerates the computed components with no filler. The list is dense but every item is informative about scope; it could be tightened slightly (e.g. grouping the Quebec/Ontario extras) without losing 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?

With no output schema, the description carries the burden of describing what comes back, and it only implies a take-home figure without saying whether a full deduction breakdown is returned. It does establish the tax year and supported provinces, but an agent cannot fully predict the response shape from the definition alone.

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 all four parameters are already documented, giving a baseline of 3. The description does add interpretive value by explaining that provincial choice drives QPIP for Quebec and surtax/Health Premium for Ontario, and that CPP vs QPP applies. It says nothing about employmentType or rrspContribution, so it does not exceed baseline.

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 names a specific resource and scope: 2026 Canadian federal + provincial income tax, CPP/QPP, EI, QPIP, Ontario surtax/Health Premium, and take-home pay, for any province. An agent can tell this computes payroll deductions and net pay rather than anything mortgage- or property-related like its siblings. It stops short of explicitly contrasting with a sibling tool, so it lands at 4 rather than 5.

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?

Usage is only implied: an agent infers it should call this when it needs after-tax income for a Canadian province. There is no explicit when-to-use statement, no exclusions, and none of the sibling calculators (e.g. capital_gains_tax, mortgage_affordability) are named as alternatives or complements.

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?

Annotations already declare a pure computation (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the safety profile is covered. Beyond that the description adds real behavioral context the annotations cannot: the result includes reasons, GDS/TDS is computed separately in each category at that category's rate, and renewals hinge on whether a premium was paid at origination — a non-obvious business rule. With no output schema, it also sketches the return 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?

Two sentences, front-loaded with the classification output, then the renewal dependency last. No filler or restatement of the title. It is dense but every clause carries information; only the parenthetical purpose list borders on enumerating schema 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 an 18-parameter, no-output-schema tool the description covers what comes out and one key rule, but the underlying classification criteria (loan-to-value thresholds, amortization limits, unit/occupancy effects) are never hinted at, so an agent cannot predict which inputs drive the verdict. The illustrative-default warning lives only in the schema. Adequate but leaves meaningful gaps for a tool of this complexity.

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% across 18 parameters, so the schema already documents units, occupancy, purpose, rates, and amortization. The description only adds meaning for one parameter class, linking premiumPaid to the renewal rule in the final sentence. That is a marginal gain over a fully documented schema, which is the baseline-3 case.

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 names a specific verb and output ('classifies a mortgage as insured, insurable or uninsurable') plus the transaction types covered (purchase, renewal, switch, refinance) and a secondary function (GDS/TDS per category at its rate). An agent can tell this apart from generic siblings like debt_service_ratio or mortgage_qualifier because it produces a three-way classification plus per-category ratios. It stops short of explicitly naming the sibling it replaces, so not a 5.

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 'Broker tool' framing and the list of covered purposes imply when it applies, and the closing sentence signals that renewal cases need premiumPaid. However, there is no explicit when-to-use versus mortgage_qualifier, cmhc_insurance, or debt_service_ratio, and no statement of when this tool is inappropriate. Usage is inferable but left to the agent.

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?

Annotations already declare readOnly, non-destructive, closed-world behavior. The description adds useful behavioral context: geographic coverage, municipal add-ons (Toronto MLTT, Montreal welcome tax), first-time buyer rebates, what fees are included vs. excluded, and zero-LTT jurisdictions. It doesn't specify tax-year/rate version, but that is a modest gap.

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?

Three dense, front-loaded sentences with no wasted words. Purpose comes first, followed by scope/special cases and an important exclusion.

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?

No output schema exists, but the description signals the return components (tax, rebate, registration fee, total due at registration), which is sufficient for an agent to know what to expect. Slightly more detail on output structure could help, but it is largely complete for a read-only calculator.

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 documents every parameter including inToronto, isFirstTimeBuyer, and quebecMunicipality. The description reinforces province-specific behavior but adds no syntax, format, or mapping details beyond what the schema provides.

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 ('Estimate') and resource ('land transfer tax on a home purchase') with scope across 13 provinces/territories. It explicitly names special cases (Toronto MLTT, Montreal welcome tax) and distinguishes itself from all siblings, which cover different taxes or mortgage calculations.

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: use for home-purchase land transfer tax estimation. Notes exclusions ('mortgage registration fee is not included') and special cases where no LTT applies (AB, SK, NL, territories). No explicit sibling alternative exists, so the lack of a 'use X instead' line is minor.

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?

Annotations already declare readOnlyHint=true, non-destructive, and closed-world, so safety is covered. The description adds useful behavioral context: the exact rule tiers, that it also determines CMHC insurance applicability, and that it returns a premium rate. It does not discuss assumptions such as occupancy type or amortization, which keeps it from a 5.

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 a single front-loaded sentence that efficiently names the calculation, jurisdiction, rule set, and outputs. The parenthetical tier breakdown is dense but earns its place by clarifying an otherwise complex rule.

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?

With no output schema, the description carries the burden of explaining what is returned, and it does so by naming the minimum down payment, CMHC insurance applicability, and premium rate. It is complete enough for a one-parameter calculator, though it omits assumptions that could affect 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% and the sole parameter, homePrice, is documented in the schema. The description does not add syntax, constraints, or format meaning beyond what the schema already provides, so the baseline of 3 applies.

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 states a specific calculation (minimum down payment) for a specific jurisdiction (Canadian home) under a specific rule set (Dec 2024 CMHC). It also names the outputs (CMHC insurance applicability and premium rate), which clearly distinguishes it from siblings like mortgage_payment or mortgage_affordability.

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?

Usage is implied by the Canadian CMHC rule context, but the description does not explicitly say when to use this tool versus siblings such as mortgage_payment or mortgage_affordability. No exclusions or alternative-selection guidance are provided.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds genuinely useful behavioral substance beyond that: it discloses the qualifying-rate methodology (stress test rather than contract rate), the regulatory ratios and down payment tier rules applied, and it enumerates the returned fields (max price, max mortgage, CMHC premium, monthly payment, GDS/TDS), compensating for the absent 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?

Two tightly packed sentences with zero filler. The primary output (maximum home price) is front-loaded, the rules that govern it follow, and the return payload closes the description — each clause earns its place despite the density.

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 12-parameter financial calculator with no output schema, the description does the heavy lifting well by listing return values and the regulatory framework used. It stops short of describing edge-case behavior — for example, what happens when the computed price exceeds the $1.5M insurability ceiling or when the down payment falls below a tier minimum — which an agent would want to know before interpreting 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 itself already explains every parameter, and the baseline of 3 applies. The description contributes one meaningful clarification beyond the schema: that qualification is evaluated at the OSFI stress-test rate rather than the 'contract mortgage rate' described on interestRatePct, but it adds no guidance on downPaymentMode interplay or the 25/30-year amortization constraint beyond what the schema states.

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 states a specific verb+resource: it computes the 'maximum home price a Canadian buyer qualifies for,' and it names the exact standards applied (GDS 39%, TDS 44%, OSFI stress-test rate, Dec-2024 down payment tiers, $1.5M CMHC ceiling). This clearly separates it from siblings like mortgage_payment or minimum_down_payment, but it never names those siblings explicitly, so the differentiation is inferential rather than stated.

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?

Usage is only implied: an agent can infer this is the tool for 'how much house can I afford' questions rather than 'what is my payment on price X.' There is no explicit when-to-use/when-not-to-use guidance and no routing to mortgage_payment, minimum_down_payment, or land_transfer_tax, which are the obvious adjacent calculations.

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?

Annotations already establish that this is a read-only, non-destructive, closed-world calculation. Beyond that, the description adds useful behavioral context by disclosing the Canadian semi-annual compounding convention and the output dimensions, including renewal balance, payoff year, and prepayment savings; it does not cover assumptions such as rounding or fixed-rate behavior.

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 tight sentences with no wasted wording. It front-loads the core purpose and output list, then adds the optional prepayment behavior in a compact second sentence.

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 an eight-parameter, read-only calculator with no output schema, the description gives enough return-value context: payment, total interest, renewal balance, payoff year, annual table, and prepayment savings. It is nearly complete, though it could mention assumptions or output format limitations.

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 all eight parameters are already documented in the input schema. The description adds only broad context that lump-sum and payment-increase prepayments affect interest and time saved, without adding syntax, constraints, or semantics beyond the 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 states a specific resource and operation: 'Year-by-year amortization of a Canadian mortgage', with named outputs including payment, total interest, renewal balance, payoff year, and annual table. This distinguishes it from narrower siblings such as mortgage_payment or mortgage_prepayment by making clear that it produces a full amortization schedule and can show prepayment savings.

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: for year-by-year amortization and for comparing optional lump-sum or payment-increase prepayments via interest and time saved. However, it does not explicitly state when to use this versus mortgage_payment, mortgage_prepayment, or mortgage_renewal, nor does it give exclusions or prerequisites.

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?

Annotations already declare readOnlyHint/destructiveHint=false, so safety is covered; the description adds genuine domain behavior beyond that — CMHC insurance is auto-added under 20% down and not added when loanAmount is supplied. It stops short of describing the returned figure (per-period amount, total interest, insurance breakdown), which matters since there is 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?

Three sentences, front-loaded with the purpose, then the input-mode rule, then the failure mode to avoid. Every sentence carries distinct information with no restatement of schema fields.

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 10-parameter, single-required-parameter calculator with no output schema, the description covers the highest-risk decision (which input mode) and a silent-error trap. The remaining gap is that it never tells the agent what the response contains, forcing the agent to infer the return shape.

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, but the description adds real semantic value the schema cannot: that homePrice and loanAmount are alternative entry points rather than complementary parameters, and why substituting one for the other is wrong. It does not, however, clarify the interaction of province, termYears, or paymentFrequency 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 opening sentence names the exact output (periodic payment) and the precise domain (Canadian mortgage), which separates it from siblings like mortgage_affordability, minimum_down_payment, and mortgage_penalty. An agent can identify the tool's job 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?

It explicitly routes between two mutually exclusive input modes (homePrice + downPayment vs loanAmount alone) and gives the trigger condition ('when the user gave the mortgage amount', with an example utterance). It also states a when-not with the reason ('never invent a purchase price to reach a loan amount: it shifts the answer and adds a CMHC premium').

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?

Annotations cover read-only safety, and the description adds the crucial non-obvious behavior: omitted rate inputs fall back to site defaults that 'can be several times off', they are surfaced in `assumedInputs`, and the agent should show them to the user. This is exactly the kind of caveat an agent cannot infer from structured fields.

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?

Three sentences, front-loaded with the core definition, then the fixed/variable rule, then the fallback caveat. Every clause carries information; nothing is redundant with the title or 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?

For an 8-parameter read-only calculator with no output schema, the description covers method selection, input-omission behavior, the `assumedInputs` return field, and the accuracy caveat. An agent has everything needed to call it and communicate results responsibly.

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, but the description adds meaning beyond the schema by grouping the three optional rate parameters as 'lender-specific' and explaining the consequence of omission. It doesn't restate individual param formats, which the schema already handles well.

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 ('Estimate the penalty to break a Canadian mortgage') plus the two calculation methods (three months' interest vs IRD). It is clearly distinguishable from siblings like mortgage_payment or mortgage_affordability, which compute different quantities.

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?

Gives explicit conditional logic for which method applies: 'Fixed = greater of the two; variable = usually three months' interest', and notes the three rate inputs are lender-specific and may be omitted. It does not explicitly route to a sibling tool, but the siblings are unrelated calculations, so that omission is minor.

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?

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the description only needs to add domain behavior. It does add useful context, that the penalty estimate is contingent on exceeding a privilege limit and uses 3 months' interest or IRD, but it says nothing about calculation assumptions, limits of the model, or what the returned values look like beyond naming them.

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?

A single dense sentence front-loads the primary output and enumerates the input modes without filler. It is somewhat clause-heavy at the tail (parenthetical about 3 months' interest or IRD), but no sentence is wasted.

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 10-parameter, no-output-schema calculator, the description is adequate: it implies the three return components (interest saved, time saved, penalty estimate) and covers both allowed prepayment channels. What is missing is modest, chiefly any note on model assumptions or how the fixed/variable choice alters the penalty path, which the schema partially carries.

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 every parameter including comparisonRatePct and rateType is already documented with purpose, defaults, and bounds. The description's mention of "IRD" and "privilege limit" gives slight conceptual grounding for the comparison-rate input, but it adds no syntax, units, or interaction detail beyond the schema. Baseline 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 names the concrete output (interest and time saved) and the three input strategies (extra per-payment, annual lump sum, or both), plus the penalty estimate, which makes the tool's scope clear. It implicitly distinguishes itself from mortgage_penalty and mortgage_amortization by combining prepayment savings with a penalty sizing estimate, but it never names those siblings to make the boundary explicit.

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?

Usage is implied rather than stated: an agent can infer this is for "what if I prepay" scenarios, and that the penalty figure is a secondary check against the privilege limit. There is no explicit when-to-use, no when-not-to-use, and no routing to mortgage_penalty or mortgage_amortization for the standalone cases.

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?

Annotations already declare a safe read-only, closed-world operation, so the bar is lower, and the description still adds real behavioral context: the GDS 39% / TDS 44% qualification constraints, use of the OSFI qualifying rate, and the fact that property tax and heating are estimated rather than supplied. It does not disclose the response shape or whether results are advisory only, which keeps it below a 5.

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?

Three compact sentences with no filler, front-loaded with the primary output (max mortgage and home price) before the mode breakdown. The telegraphic style is dense but readable; minor polish would earn a 5.

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 an 8-parameter calculation tool with no output schema, the description covers the returned quantities, the two calculation paths, the regulatory ratio caps, and the estimated inputs. It does not explain how annualInterestRatePct interacts with the OSFI qualifying rate, which is the one substantive gap for this complexity.

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 documents every parameter including the mode enum and the income-vs-budget parameter split. The description reinforces which parameters belong to which mode, which is mild added meaning, but adds no format, unit, or default detail beyond the 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?

States a specific outcome (maximum mortgage and home price at the OSFI qualifying rate) and splits it into two clearly named modes, income vs. budget. It stops short of distinguishing itself from close siblings such as mortgage_affordability, mortgage_stress_test, or debt_service_ratio, so an agent cannot fully disambiguate from the name and description alone.

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?

Explicit conditional guidance exists for the two modes: mode='income' when you have income, debts and down payment; mode='budget' when you start from an affordable monthly payment. What is missing is when NOT to use this tool versus the many overlapping siblings (affordability, stress test, debt service ratio).

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?

The annotations already establish that this is a safe, read-only, closed-world calculation, and the description adds the enumerated comparison outputs and the balance-reducing effect of a lump sum. It does not disclose calculation conventions such as Canadian compounding, how the current-payment baseline is derived, or how accelerated payment frequencies affect the comparison.

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 compact sentences front-load the comparison, enumerate its principal results, and then cover the optional lump-sum behavior. There is no redundant or promotional wording.

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?

Together with the fully documented schema and safety annotations, the description supplies enough information to select and invoke the calculator, including its main outputs despite the absence of an output schema. Greater completeness would require key methodology assumptions and clearer routing away from related mortgage calculators.

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 all seven inputs, their defaults, and their constraints. The description reinforces the roles of the rates, new term, and lump sum but adds little parameter-specific meaning beyond that documentation.

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 gives a specific action and scope: comparing a Canadian mortgage's payment and term interest between the current and renewal rates. Listing payment changes and extra term interest clearly distinguishes it from sibling tools such as mortgage_payment and mortgage_amortization.

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 renewal-rate comparison and payment-shock context make it clear when this tool is appropriate, including when modeling a lump sum at renewal. It does not explicitly exclude simpler payment calculations or name an alternative sibling for those cases.

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?

Annotations already establish read-only, non-destructive, closed-world behavior, yet the description still adds substance: the qualifying-rate formula (higher of contract + 2% or 5.25%), the 39/44 GDS/TDS thresholds, the three-state pass/close/fail result, and the exemption logic. It does not discuss rounding, assumptions, or limits on the max-home-price back-solve, so it falls just short of full transparency.

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 action and OSFI context, then the results, then the exemption carve-out. The long enumeration is information-dense rather than wasteful, though the mid-sentence output list is slightly harder to scan than separated clauses would be.

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 16-parameter tool with no output schema, the description does the necessary work: it names what comes back (qualifying rate, ratios, verdict, max price, shortfall) and flags the case where the tool returns an exempt result. Minor gaps remain around result units and how the close band is defined, but nothing critical to calling it correctly is missing.

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, but the description earns more by explaining how inputs are consumed: which rate becomes the qualifying rate, which ratio thresholds apply, and why renewalIncreasing matters for exemption. That gives an agent meaning beyond the per-field text without duplicating it.

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 verb ('Check') and a precisely scoped resource: the OSFI B-20 stress test for purchase, renewal or refinance. It also enumerates the outputs (qualifying rate, GDS/TDS, pass/close/fail, max home price, shortfall), which separates it from generic siblings like mortgage_qualifier, mortgage_affordability and debt_service_ratio without needing to name them.

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 three supported scenarios are stated explicitly, and the last sentence gives a genuine exclusion rule: straight-switch renewals are exempt unless the amount or amortization increases, which maps directly to the renewalIncreasing flag. It stops short of naming sibling tools to use instead when the case is out of scope (e.g. plain payment or affordability math).

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the agent knows this is a safe, closed-world calculation. Beyond that, the description adds real value by disclosing the calculation model — HST is netted against the new-housing rebate, financing cost derives from a draw schedule, contingency applies to hard+soft costs. It does not describe the returned figures' structure, though no output schema exists to cover that gap.

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?

A single front-loaded sentence with a colon-and-list structure; every clause names a distinct cost or return component and none is filler. It is dense but appropriately sized for a 14-parameter composite calculator, with only the missing action verb ('calculates') as a minor structural gap.

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 14-parameter, no-output-schema calculator, the description covers what goes in and what comes out at a component level, which is roughly adequate. It leaves unaddressed how the result is shaped (a single object? line items?), whether figures are CAD, and the preconditions tying ownsLand to landPurchasePrice — meaningful gaps when there is no output schema to lean on.

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% and every one of the 14 parameters carries its own description, defaults, enums and bounds, so the baseline is 3. The description adds only marginal parameter meaning — it implies projectType drives the HST rebate and that land transfer tax is a function of province — without explaining units, interactions (ownsLand vs. landPurchasePrice), or which inputs feed which outputs.

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 names a concrete artifact ('development pro forma for a Canadian build') and enumerates exactly what it computes: land, land transfer tax, hard/soft costs, HST net of the new-housing rebate, financing, contingency, sale proceeds, profit, margin, ROI. That is far more specific than a tautology and clearly separates it from single-purpose siblings like land_transfer_tax or closing_costs. It stops short of explicitly naming which sibling tools it replaces.

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?

Usage is only implied by the phrase 'for a Canadian build' and by the computed-output list, which signals whole-project feasibility analysis rather than a single-fee lookup. There is no explicit when-to-use statement, no when-not (e.g., existing-property purchase analysis), and no routing to alternatives such as closing_costs, land_transfer_tax, or renovation_roi.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false. The description adds non-obvious calculation behavior: assessed value not purchase price, Ontario's 2016 MPAC values, and rates normalised to full assessed value for SK and Winnipeg.

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 dense sentences, front-loaded with what is calculated and the critical assessed-value distinction. The parentheticals earn their place by preventing assessed-versus-purchase-price and rate-normalisation errors.

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 read-only calculator with four fully documented parameters and no output schema, the description supplies enough basis, coverage, override and normalisation context. Remaining schema-level details such as includeQuebecSchoolTax are covered by the parameter descriptions.

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 the schema already documents each parameter. The description still adds meaning for assessedValue and ratePct by warning against purchase price and explaining that ratePct overrides the city rate and that published rates are normalised.

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 states a specific action and resource: annual and monthly property tax from assessed value for 18 Canadian cities. It explicitly distinguishes assessed value from purchase price, so an agent can identify it among tax and calculator siblings.

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?

It gives a clear usage alternative: pass ratePct instead of city to use the rate on your own bill. It does not explicitly say when not to use this tool versus sibling calculators, but the parameter-selection guidance is concrete.

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?

Annotations already cover the read-only, closed-world, non-destructive profile, so the description's added value is domain behavior: commission is not regulated, quoted provincial rates are only starting points, and any rate can be overridden via explicit parameters. That is meaningful behavioral disclosure beyond the annotations, though it says nothing about how results are presented or what precedence applies when province and override parameters conflict.

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 tightly packed sentences, no filler, with the resource and scope front-loaded. The density comes at a small cost — multiple distinct claims (tax, split, net proceeds, provincial defaults, negotiability) are compressed into one line each.

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 an 11-parameter tool with only one required field and a fully described schema, the description gives enough to call it correctly and implicitly names the outputs (commission, tax, split, net proceeds). With no output schema, it could be more explicit about the shape of the returned numbers, and it does not clarify default-vs-override precedence.

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% and each parameter, including the override fields and their tiered/flat applicability, is already documented in the schema. The description restates at a high level that province sets starting rates and overrides exist, adding little beyond structured data; baseline 3 applies.

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 resource and scope: "Seller's real estate commission in Canada" plus the components it computes (commission, GST/HST, listing vs buyer split, net proceeds). An agent can tell it is a seller-side commission calculator rather than a generic cost tool, though it never names the near sibling cost_of_selling or closing_costs to draw the boundary.

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?

Usage is only implied by the framing — a seller estimating commission on a sale. There is no explicit when-to-use, when-not-to-use, or pointer to alternatives such as cost_of_selling or closing_costs. The negotiability note is useful context but is not routing 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?

Annotations already declare a safe read-only, closed-world operation, and the description goes further by disclosing that depreciation is straight-line over the project's economic life and is an editable HomeCalc assumption rather than a measured figure. That caveat about model fidelity is exactly the kind of context annotations cannot carry. It does not mention rounding, currency handling beyond the title, or sensitivity to overrides.

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?

One front-loaded sentence delivers the whole purpose, with the key caveat about the editable assumption nested immediately after the behavior it qualifies. The multiple parentheticals make it dense on first read, but no sentence is wasted.

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?

With no output schema, the description must convey return semantics, and it does: value added vs cost, residual value at sale, and net rent. Combined with 100% schema coverage and read-only annotations, an agent has everything needed to call this correctly.

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 every parameter already carries its own documentation and the baseline of 3 applies. The description adds only indirect meaning, tying economicLifeYears to the straight-line decay mechanism; it says nothing about overriding valueAdded versus projectType defaults that the schema does not already state.

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 names a specific computation (value added vs cost, value decay to sale date, plus net rent) for a specific resource (a home renovation), which clearly separates it from siblings like cost_of_selling or capital_cost_allowance. It stops short of naming an alternative tool or contrasting scope explicitly, so it lands just below the top mark.

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?

Usage is implied by the concept of evaluating a renovation's return, and the phrasing 'how that value shrinks by the time you sell' hints at the sale-horizon use case. There is no explicit when-to-use, when-not-to-use, or pointer to a sibling such as house_flipping or cost_of_selling, leaving selection guidance to inference.

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?

Annotations already establish this as a safe read-only, closed-world, non-destructive operation, so the bar is lower. The description adds genuinely useful behavior: results are 'floored to the cent' and a 'capped:false' result means the unit is exempt, though the 'capped' field is never defined and no output schema exists to anchor it.

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 compact fragments with the province scope and rounding behavior front-loaded, and no filler wording. Its brevity dips into under-specification, which is better captured by completeness than by conciseness.

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 simple read-only calculator with fully documented parameters, the definition is close to sufficient, but a tool with no output schema should say what comes back (guideline percentage vs. new rent) and clarify the dangling 'capped' field referenced in the description.

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%, including enum values for province and an exclusiveMinimum on currentRent, so the schema already carries parameter meaning. The description adds nothing about the four inputs beyond a partial gloss on exemption, making baseline 3 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?

States a specific verb (calculate) and resource (rent-increase guideline and new rent) scoped to ON/BC/MB, which an agent can distinguish from rent_vs_buy or property_tax among siblings. It stops short of naming siblings or contrasting them, so it is clear but not fully differentiating.

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?

Provides no when-to-use or when-not-to-use guidance, and names no alternative tool. The only conditional hint is 'capped:false = exempt unit', which describes an output field rather than when to call the tool.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real value by explaining the comparison methodology (home equity after selling vs. renter investing the down payment and monthly savings) and what it returns, though it omits assumptions about tax treatment, inflation of rent, or how milestone years are chosen. With annotations carrying safety, 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?

One front-loaded sentence that leads with the action and then enumerates the outputs. The parenthetical is dense but each clause adds meaning (methodology plus return values). Minor loss for cramming everything into one comma-chain that is slightly hard to parse.

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?

With 18 parameters and no output schema, the description usefully explains the return values and the underlying comparison model, which an agent would otherwise not have. It falls short on modeling assumptions (taxes on investment returns, rent vs. home growth interplay) that materially affect results, which for a financial calculator is a notable omission.

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 all 18 parameters are already documented in the schema, including city-specific land transfer tax and rebate flags. The description mentions none of them, so the baseline 3 applies. It neither compensates nor detracts.

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 comparison ('Compare renting with buying over a time horizon') and names the two outputs produced (net cost, net wealth, break-even year, milestone years). This clearly distinguishes it from the single-purpose siblings like mortgage_payment, cap_rate, or closing_costs, which each compute one component.

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 'over a time horizon' framing implies the tool suits long-horizon rent-vs-buy decisions, but it gives no explicit when-to-use/when-not guidance and never points to related siblings (e.g., closing_costs or cap_rate to refine inputs). Usage is inferable rather than stated.

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?

Annotations already declare it is read-only, closed-world and non-destructive. The description adds useful context beyond that: that the 55% figure is the lender's published ceiling rather than an approval, and that the balance compounds semi-annually with no payments. It doesn't say which rate drives the projection or what the output looks like, so a 3 fits.

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?

A single dense sentence with the key caveat (ceiling not approval) front-loaded and the projection horizons at the end. Every clause carries information, though the em-dash nesting makes it slightly harder to scan.

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?

With no output schema, the description carries the burden of explaining what comes back, and it only sketches the outputs (max amount, balance vs equity at four horizons). Given that all five parameters are fully documented in the schema, the definition is 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?

Schema description coverage is 100%, including the rateTerm enum and the 55% cap on amountTaken, so the schema already does the work. The description reinforces the ceiling concept but adds no syntax or format meaning beyond the 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?

Names a specific computation on a specific resource: the theoretical maximum (55% of value) and the compounding balance versus home equity at 5/10/15/20 year horizons. It doesn't explicitly distinguish itself from the nearby siblings heloc_second_mortgage or mortgage_amortization, but the '55+' and 'no payments' framing makes the concept recognizable on its own.

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 '55+' eligibility and 'CHIP-style' framing imply the context in which to use it, but nothing states when to pick this over heloc_second_mortgage or a standard amortization tool, and there are no exclusions or prerequisites beyond the age requirement.

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?

Annotations already declare a safe, read-only, closed-world calculation. The description adds substantive behavioral context beyond that: combined TDS across both properties, subject-property GDS, a 20% minimum down payment unless occupying, and optional rental income add-back. It still does not explain the returned breakdown or lender assumptions.

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?

It is one front-loaded sentence with no filler, and the colon list efficiently summarizes the calculation. It is dense and jargon-heavy, but appropriately sized for a compact tool description.

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 19-parameter calculator with no output schema, the description supplies the headline output and main qualification mechanics. It omits return-value structure, assumptions or caveats, and how province and intent materially affect results, so it is 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?

Schema coverage is 100%, so the schema already documents all 19 parameters in detail. The description adds high-level relationships such as combined TDS, the down-payment rule, and rental add-back, but little parameter-specific meaning beyond what the schema provides.

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 states a specific computed output—maximum purchase price for a second property while retaining the current home—and distinguishes the scenario from primary-home affordability via combined TDS across both properties. Cottage, rental, and second-home cases are explicitly named.

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?

It gives clear usage context: a second property while keeping the current home, with vacation/rental/personal-home intent cases named. It does not explicitly route the agent to or away from sibling tools such as mortgage_affordability or mortgage_qualifier, and it states no exclusions or 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?

Annotations already declare a safe, closed-world, read-only computation, so the burden is light. The description adds real value by disclosing what the calculation returns beyond the purchase price: the profit remaining after repairs plus the commission and closing costs on the sale. It does not state units or rounding, but the schema covers currency.

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?

It is a single front-loaded sentence that leads with the primary output and the formula, with no filler. The trailing clause ('plus the profit left after repairs and the commission and closing costs on the sale') is dense and slightly awkward to parse, costing it a point.

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?

There is no output schema, so the description must carry the return-value burden, and it does list the three result components (max price, profit after repairs, commission and closing costs). The only residual gap is whether the stated profit already nets out the purchase price, which is left for the agent to infer from the formula.

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 the baseline is 3, but the description goes further by expressing how the inputs combine (ARV × rule − repairs) and by noting that commission and closing costs are charged on the sale. That formula framing tells the agent the role of rulePct, commissionRatePct, and closingCostRatePct relative to each other, not just their individual definitions.

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 names a specific computation (maximum purchase price for a flip) and the exact formula (ARV × rule − repairs), so the agent knows precisely what the tool produces. It implicitly separates this from sibling calculators like house_flipping or renovation_roi by focusing on purchase-price ceiling, though it never names an alternative explicitly.

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?

Usage is only implied: the mention of 'for a flip' and the 65%/70% variants signals the flipping context, and the description notes the stricter option exists. There is no explicit statement of when to choose this over house_flipping, renovation_roi, or cost_of_selling, and no prerequisites or exclusions are given.

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