Skip to main content
Glama
chrischall

OurFamilyWizard MCP

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Calculate a Swedish monthly mortgage cost

hemnet_calculate_mortgage
Read-onlyIdempotent

Calculate a Swedish mortgage's monthly cost in SEK from price and interest rate. Returns breakdown of interest, amortisation, BRF fee, operating costs, and gross/after-tax totals.

Instructions

Local-only Swedish mortgage calculator (all amounts SEK). Returns the monthly cost broken into interest, mandated amortisation (amorteringskrav from LTV, rules as of 1 April 2026), BRF fee (avgift), and operating cost — with both gross and after-tax (ränteavdrag) totals. Provide down_payment OR down_payment_percent (defaults to the legal 10% minimum). No network call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
priceYesPurchase price in SEK.
monthly_feeNoBRF monthly fee (avgift) in SEK — for bostadsrätt apartments.
down_paymentNoSEK
interest_rateYesAnnual interest rate %, e.g. 3.5
amortization_rateNoOverride the computed amortisation rate (annual % of loan).
gross_yearly_incomeNoDeprecated and ignored: income no longer affects amortisation (the debt-ratio rule was abolished 1 April 2026).
down_payment_percentNoPercent of price; defaults to the legal 10% minimum.
monthly_operating_costNoMonthly operating cost (driftkostnad) in SEK — typically houses.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.1.3
    • changedInput schema / properties / down_payment_percent / description
      Previous value: -"Percent of price; defaults to the legal 15% minimum."New value: +"Percent of price; defaults to the legal 10% minimum."
    • changedInput schema / properties / gross_yearly_income / description
      Previous value: -"Gross household income/year in SEK — enables the +1% debt-ratio amortisation surcharge."New value: +"Deprecated and ignored: income no longer affects amortisation (the debt-ratio rule was abolished 1 April 2026)."
  2. Changed1 schema field changedv1.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  3. Addedv0.2.0

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses that the tool is local-only, makes no network call, applies Swedish amortisation rules as of 1 April 2026, handles after-tax deductions (ränteavdrag), and ignores the deprecated income parameter. This is rich behavioral context and contradicts nothing in the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is information-dense but compact: purpose, output breakdown, key parameter rule, and side-effect note all fit in three sentences. Each sentence contributes meaning and important facts are front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having eight parameters and no output schema, the description explains the return composition, currency, and tax treatment, while the schema covers all parameter details. An agent has everything needed to decide when to call it and what response shape to expect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 adds useful semantic value by stating the down_payment OR down_payment_percent choice and the legal 10% default, which is not obvious from the JSON schema alone.

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?

The description opens with a specific verb and resource: 'Local-only Swedish mortgage calculator,' then lists exactly what the tool returns (interest, amortisation, BRF fee, operating cost, gross and after-tax totals). It is clearly distinct from sibling listing/search/photo tools, which all concern property lookup rather than calculation.

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?

It supplies clear context for invocation: Swedish property purchase in SEK, with the legal 10% down-payment default and the choice between down_payment and down_payment_percent. Because no sibling performs mortgage calculation, there is no need for an explicit alternative; 'No network call' and 'Local-only' further signal the intended use as a pure calculator.

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

Deploy Server

Other Tools