Skip to main content
Glama

HomeCalc — Canadian Mortgage & Tax Calculators

Rent vs Buy Calculator (Canada)

rent_vs_buy
Read-only

Compare renting with buying over a time horizon: net cost and net wealth of each (home equity after selling vs the renter investing the down payment and monthly savings), the break-even year, and milestone years.

Input Schema

NameRequiredDescriptionDefault
cityNoCity; Toronto adds municipal LTT, Montreal uses its own welcome-tax bracketsToronto
provinceNoProvince or territory; sets the land transfer taxOntario
monthlyRentYesMonthly rent for a comparable home in CAD
yearsToStayNoHow many years you plan to stay
purchasePriceYesPurchase price of the home in CAD
rentGrowthPctNoYearly rent increase as a percent
downPaymentPctNoDown payment as a percent of the price
sellingCostPctNoCost of selling as a percent of the sale price
landTransferTaxNoYour own land transfer tax figure in CAD, replacing the computed one
mortgageRatePctNoAnnual mortgage rate as a percent
condoFeesMonthlyNoMonthly condo fees in CAD
isFirstTimeBuyerNoEligible for the first-time buyer land transfer tax rebate
amortizationYearsNoAmortization in years
homePriceGrowthPctNoYearly home price growth as a percent
maintenanceMonthlyNoMonthly maintenance and repairs in CAD
propertyTaxRatePctNoAnnual property tax as a percent of value
homeInsuranceAnnualNoAnnual home insurance in CAD
investmentReturnPctNoYearly return the renter earns on invested savings

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / city / description
      Previous value: -"City name; 'Toronto' adds the municipal land transfer tax"New value: +"City; Toronto adds municipal LTT, Montreal uses its own welcome-tax brackets"
    • addedInput schema / properties / landTransferTax
      Added value: +{
      +  "description": "Your own land transfer tax figure in CAD, replacing the computed one",
      +  "minimum": 0,
      +  "type": "number"
      +}
    • changedInput schema / properties / province / description
      Previous value: -"Province (land transfer tax is computed for Ontario only)"New value: +"Province or territory; sets the land transfer tax"
    • changedInput schema / properties / province / enum
      Previous value: -[
      -  "Ontario",
      -  "British Columbia",
      -  "Alberta",
      -  "Quebec",
      -  "Nova Scotia",
      -  "Manitoba",
      -  "Saskatchewan",
      -  "New Brunswick",
      -  "PEI",
      -  "Newfoundland and Labrador"
      -]New value: +[
      +  "Ontario",
      +  "British Columbia",
      +  "Quebec",
      +  "Alberta",
      +  "Manitoba",
      +  "Nova Scotia",
      +  "New Brunswick",
      +  "Saskatchewan",
      +  "PEI",
      +  "Newfoundland & Labrador",
      +  "Northwest Territories",
      +  "Nunavut",
      +  "Yukon",
      +  "Newfoundland and Labrador"
      +]
  2. Added

TDQS

A3.7/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources