Skip to main content
Glama

Casatoo

Simulate a Portugal mortgage

casatoo_simulate_mortgage
Read-onlyIdempotent

Estimate Portugal residential purchase costs with the same logic as the Casatoo calculator: 2026 mainland/island IMT, youth relief, stamp duty, loan payment, savings shortfall, effort rate, rate scenarios and annual amortisation. Anonymous, read-only, no account or location lookup needed. EUR amounts; TAN is percent. Omitted fields use published illustrative defaults, not known facts about the user. Include assumptions when presenting results.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "casatoo_simulate_mortgage"
  }
}

Input Schema

NameRequiredDescriptionDefault
priceNoPurchase price in EUR. Residential property only.
yearsNoTerm in years; rounds to the nearest whole year, halves upwards. Bank eligibility is not assessed.
regionNoMainland Portugal or Madeira/Azores tax tables.mainland
savingsNoSavings allocated to this purchase, including taxes and fees, in EUR.
tax_valueNoVPT in EUR. Zero if unknown; taxes use the higher of this and price.
other_debtNoExisting monthly loan payments in EUR, included in effort rate.
annual_rateNoConstant annual nominal rate (TAN), percent, not TAEG.
young_buyerNoTrue only if every buyer qualifies for IMT Jovem: age up to 35, not IRS-dependent, first primary home, no residential ownership in prior three years.
monthly_costsNoMonthly insurance and ownership costs in EUR, added to housing budget only.
purchase_typeNoPrimary permanent residence or secondary/rental residential property.primary
monthly_incomeNoNet monthly household income in EUR. Zero means effort rate is unavailable.

Output Schema

NameRequiredDescriptionDefault
resultYes
currencyYes
tax_yearYes
assumptionsYes
rate_scenariosYes
annual_scheduleYes
effort_rate_availableYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • removedInput schema / properties / annual_rate / title
      Removed value: -"Annual Rate"
    • removedInput schema / properties / purchase_type / title
      Removed value: -"Purchase Type"
    • removedInput schema / properties / region / title
      Removed value: -"Region"
    • removedInput schema / properties / years / title
      Removed value: -"Years"
    • removedInput schema / properties / young_buyer / title
      Removed value: -"Young Buyer"
    • removedInput schema / title
      Removed value: -"MortgageSimulationRequest"
  2. Added

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover read-only/idempotent/non-destructive, so the bar is lower; the description still adds meaningful context: inputs are anonymous, no account or location lookup occurs, and defaults are illustrative rather than inferred user facts, plus a presentation instruction to include assumptions. It does not address output/pagination, but for a pure computation that is minor.

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?

Two dense sentences front-load the purpose and scope, followed by short clauses on anonymity, units, defaults and presentation. Every sentence earns its place, though the middle listing of computed outputs is slightly packed.

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?

An output schema exists so return values need not be described, and the description correctly focuses on scope, default-handling policy and presentation caveats. It is complete enough for an agent to call the tool correctly with any subset of the 11 optional parameters.

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 every parameter is already documented in the schema; the description only restates cross-cutting conventions (EUR amounts, TAN as percent) which largely duplicate the schema text. Baseline 3 is appropriate.

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+resource (simulate/estimate Portugal residential purchase costs) and enumerates the computed outputs (IMT, stamp duty, loan payment, savings shortfall, effort rate, rate scenarios, amortisation). This clearly distinguishes it from the listing/search siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear operating context: anonymous, read-only, no account or location lookup needed, and omitted fields fall back to published illustrative defaults rather than user facts. It stops short of an explicit when-to-use / when-not statement versus siblings, but the context is unambiguous.

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