Rychlá Hypo – Czech mortgages

Kolik mi která banka půjčí

calculate_max_mortgage

Read-onlyIdempotent

Calculate how much each of 6 Czech banks will lend (or whether a requested amount gets approved) from household income, expenses, debts and property, using each bank's own credit methodology (DSTI, DTI, LTV, living costs, recognition of self-employed, pension, rental and other income). No personal data needed: ages and amounts only.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`region`	No	Prague, other larger town, small municipality (affects living costs).	regional
`married`	No	Applicants are spouses with joint property (SJM).
`purpose`	No	Purpose: purchase, refinancing, construction, renovation, non-purpose (American mortgage), settlement.	koupe
`children`	No	Number of dependent children (counted as 6–15 years old). For precise living costs send children_ages instead.
`fixation`	No	Rate fixation period: 1R, 3R, 5R, 7R or 10R (years). Numbers 1/3/5/7/10 are accepted too. A bank that does not offer the fixation is listed as unavailable (compare) or rejected with fixation_offered=false (max-loan).	3R
`own_funds`	No	Own funds / savings in CZK.
`applicants`	Yes	1–4 applicants (household members who will be borrowers).
`investment`	No	Buy-to-let / third or further residential property (LTV 70 %, DTI 7).
`term_years`	No	Repayment term in years ("30 let" or "360 měsíců" accepted).
`alimony_paid`	No	Monthly alimony paid, CZK.
`housing_cost`	No	Monthly housing cost that continues after the purchase (e.g. rent), CZK.
`children_ages`	No	Ages of dependent children, e.g. [3, 9]. Overrides children.
`loan_payments`	No	Monthly payments of all existing loans and leasing, CZK.
`property_type`	No	Flat, house, cooperative flat, land, recreational, commercial.
`property_value`	No	Property price in CZK. Without it the result is the income-based maximum only.
`requested_loan`	No	Specific loan amount to assess (approved yes/no per bank); needs property_value (or valuation), otherwise only the maximum is returned with an input_warnings note. Omit to get the maximum per bank.
`overdraft_limits`	No	Sum of overdraft limits, CZK.
`credit_card_limits`	No	Sum of credit card limits, CZK.
`existing_debt_balance`	No	Outstanding principal of all existing loans, CZK (DTI limit).

Schema Changelog

Changes observed during successful MCP inspections.

Changed11 schema fields changedSep 30, 2026

changedInput schema / properties / applicants / items / properties / age / description
```
Previous value: -"Age in years."New value: +"Age in years (or year of birth)."
```

addedInput schema / properties / applicants / items / properties / avg_monthly_revenue

Added value: +{
+  "description": "income_type=osvc_paus (flat tax): average monthly revenue in CZK. Required for osvc_paus (or annual_revenue, divided by 12).",
+  "type": "number"
+}

addedInput schema / properties / applicants / items / properties / business_industry

Added value: +{
+  "default": "jine",
+  "description": "income_type=osvc_paus: line of business (banks apply industry margins to revenue).",
+  "enum": [
+    "it",
+    "remeslo",
+    "poradenstvi",
+    "zdravotnictvi",
+    "obchod",
+    "kreativni",
+    "osobni_sluzby",
+    "doprava",
+    "pravo_ucto",
+    "architektura",
+    "vzdelavani",
+    "finance",
+    "vyroba_gastro",
+    "provozni_sluzby",
+    "zemedelstvi",
+    "reality",
+    "jine"
+  ],
+  "type": "string"
+}

addedInput schema / properties / applicants / items / properties / flat_tax_band

Added value: +{
+  "description": "income_type=osvc_paus: monthly flat tax actually paid in CZK, or band number 1–3. Omit to derive it from revenue.",
+  "type": "number"
+}

changedInput schema / properties / applicants / items / properties / months_employed / description

Previous value: -"Months at current employer."New value: +"Months at current employer (text with a unit like \"2 roky\" or \"18 měsíců\" is accepted)."

addedInput schema / properties / applicants / items / properties / months_in_business

Added value: +{
+  "description": "Months in business (self-employed: osvc_paus, osvc_vydpausal, osvc_skutecne). Omit if unknown.",
+  "type": "number"
+}

changedInput schema / properties / applicants / items / properties / net_income / description

Previous value: -"Net monthly income in CZK (for employees and pensions). For self-employed use annual_revenue and annual_tax_base."New value: +"Net monthly income in CZK (for employees and pensions). For self-employed use annual_revenue and annual_tax_base; for osvc_paus (flat tax) avg_monthly_revenue."

addedInput schema / properties / applicants / items / properties / paid_full_prev_year

Added value: +{
+  "default": true,
+  "description": "income_type=osvc_paus: was in the flat-tax regime for the whole previous year.",
+  "type": "boolean"
+}

changedInput schema / properties / fixation / description

Previous value: -"Rate fixation period: 1R, 3R, 5R, 7R or 10R (years). Numbers 1/3/5/7/10 are accepted too."New value: +"Rate fixation period: 1R, 3R, 5R, 7R or 10R (years). Numbers 1/3/5/7/10 are accepted too. A bank that does not offer the fixation is listed as unavailable (compare) or rejected with fixation_offered=false (max-loan)."

changedInput schema / properties / requested_loan / description

Previous value: -"Specific loan amount to assess (approved yes/no per bank). Omit to get the maximum per bank."New value: +"Specific loan amount to assess (approved yes/no per bank); needs property_value (or valuation), otherwise only the maximum is returned with an input_warnings note. Omit to get the maximum per bank."

addedInput schema / properties / term_years / description

Added value: +"Repayment term in years (\"30 let\" or \"360 měsíců\" accepted)."

First observedSep 27, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations cover the safety profile (readOnly, idempotent, closed-world), so the bar is lower. The description adds real behavioral context: it discloses the multi-bank modeling approach (DSTI, DTI, LTV, living costs, income type recognition), that ages/amounts only are needed (no personal identifiers), and that unavailable fixations lead to per-bank unavailability. It stops short of describing output shape or edge-case warnings, but this is above the annotation baseline.

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 sentences, front-loaded with the core action and scope. The parenthetical list of methodologies and income types is dense but relevant, not filler. Slightly long for what it conveys, but every clause earns its place.

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?

For a 19-parameter, multi-bank financial calculator with no output schema, the description supplies essential framing: what is computed, from which inputs, using which regulatory methodologies, and the privacy posture. It does not explain return structure, but annotations and the schema's param descriptions carry enough weight that the definition is complete for correct invocation.

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 the schema already documents all 19 parameters including nested applicant fields, enums, and defaults. The description adds domain framing (DTI/DSTI/LTV/living costs) but no parameter syntax or value semantics beyond what the schema provides. Baseline 3 is appropriate when the schema carries the full parameter burden.

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 ('Calculate how much each of 6 Czech banks will lend') with clear scope: household-based borrowing capacity using each bank's methodology. This distinguishes it from sibling 'compare_mortgages', which likely compares products rather than computing a maximum. An agent can route between them without opening schemas.

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?

Provides clear context: 'or whether a requested amount gets approved' maps to the requested_loan param, and 'No personal data needed: ages and amounts only' sets usage expectations. However, it does not explicitly name when to use this versus compare_mortgages or get_mortgage_rates — the differentiator is implied by 'maximum lend' rather than stated as an alternative rule.

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

All Rychlá Hypo – Czech mortgages tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Kolik mi která banka půjčí

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources