Rychlá Hypo – Czech mortgages

Server Details

Czech mortgage rates, payment comparison and max loan per bank for 6 major Czech banks.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-10-01 07:41
Transport: Streamable HTTP · MCP 2025-06-18
URL
Repository: emil-asistent/rychlahypo-mcp
GitHub Stars: 0

TDQS

A4.3/5.0

Scored 2026-09-30 20:31 across 4 tools

Disambiguation5/5

Each tool targets a clearly distinct question: calculate_max_mortgage handles creditworthiness and approval, compare_mortgages handles product cost comparison for a given amount, get_mortgage_rates provides current published rates, and get_advisor_contact provides a path to a binding offer. The descriptions explicitly differentiate creditworthiness vs product comparison, preventing misselection.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern (calculate_, compare_, get_, get_). The minor plural variation ('mortgages' vs 'mortgage') is trivial and does not break predictability.

Tool Count5/5

Four tools cover the core decision-support journey—rates lookup, borrowing capacity, cross-bank cost comparison, and advisor contact—without redundancy. The count is well-scoped for this niche mortgage information service.

Completeness5/5

The surface covers the full mortgage information lifecycle: current rates, borrowing capacity, cross-bank cost comparison, and a path to a binding offer via advisor. No obvious gaps or dead ends for the stated purpose of helping users evaluate Czech mortgages.

Available Tools

4 tools

calculate_max_mortgageKolik mi která banka půjčíA

Read-onlyIdempotent

Inspect

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.

ParametersJSON 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).

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.

compare_mortgagesSrovnání splátek hypotéky u 6 bankA

Read-onlyIdempotent

Inspect

Compare the monthly payment, interest rate, RPSN (APRC), total cost and interest of a given mortgage amount across 6 Czech banks, sorted from cheapest. Applies each bank's LTV and small-loan surcharges and product limits (not creditworthiness). Above 80 % LTV banks lend only if all applicants are under 36 (set all_applicants_under_36). Use for 'which bank is cheapest for X CZK'.

ParametersJSON Schema

Name	Required	Description	Default
`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
`term_years`	No	Repayment term in years.
`loan_amount`	Yes	Mortgage amount in CZK.
`property_value`	No	Property price or valuation in CZK. Used for LTV surcharges and bank LTV limits. Optional.
`all_applicants_under_36`	No	True if every applicant is younger than 36. Banks lend above 80 % LTV (up to 90 %) only to applicants under 36 (Czech National Bank limit); UniCredit also waives its 81–90 % LTV surcharge for them.

TDQS

A4.5/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), and the description adds real behavior beyond them: it applies bank LTV and small-loan surcharges and product limits, explicitly excludes creditworthiness, and notes that a bank not offering a fixation is reported as unavailable.

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?

Three sentences, each load-bearing: what is compared and how it is sorted, what adjustments are applied, then the decision rule and a usage trigger. Nothing is repeated from the schema or annotations verbatim.

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?

With no output schema, the description still names the returned fields (monthly payment, rate, RPSN, total cost, interest) and the sort order, and it discloses the eligibility rule that can make a bank unavailable. An agent has everything needed to call and interpret this correctly.

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 baseline is 3, but the description adds cross-parameter meaning the schema does not: the >80% LTV lending rule and the flag to set (all_applicants_under_36), including UniCredit's surcharge waiver. That linkage is genuinely operational information.

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 (compare) and the exact resource (monthly payment, rate, RPSN, total cost, interest across 6 Czech banks), plus the output ordering. This clearly distinguishes it from calculate_max_mortgage and get_mortgage_rates.

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 an explicit usage trigger ("Use for 'which bank is cheapest for X CZK'") and an exclusion ("not creditworthiness"), and explains the LTV>80% under-36 condition that governs whether a quote is returned. It stops short of naming a sibling as the alternative for max-loan or rate-only queries.

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

get_advisor_contactKontakt na hypotečního specialistuA

Read-onlyIdempotent

Inspect

How the user can get a binding assessment and have the mortgage arranged for free by a licensed Czech mortgage intermediary (Rychlá Hypo). Returns phone, e-mail and links.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, and closed-world, so the safety profile is covered. The description adds genuinely useful context beyond that: the service is free, the intermediary is licensed and Czech-specific, and the return payload is phone/e-mail/links. It does not cover edge cases (e.g., what happens if no advisor is available), which keeps it 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.

Conciseness4/5

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

Two tight sentences with no filler, and the return payload is stated up front in the second sentence. The first sentence is slightly roundabout in its 'How the user can...' construction but remains economical.

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 zero-parameter, no-output-schema tool, the description supplies the missing return-value information (phone, e-mail, links) that an agent would otherwise have to guess. It is sufficient to invoke correctly, with the only gap being the absence of explicit routing guidance against siblings.

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?

The tool takes zero parameters, so the baseline is 4. The description appropriately does not invent parameter details and instead spends its words on what the call yields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete outcome (obtaining a binding assessment and free mortgage arrangement via a licensed Czech intermediary) and specifies what is returned (phone, e-mail, links). It is clearly distinct from the sibling rate/calculation tools, though the 'How the user can get...' framing makes the tool's own action slightly indirect rather than an explicit verb+resource.

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?

Usage is only implied: an agent can infer this is for users wanting personalized mortgage advice rather than raw rates or calculations. There is no explicit when-to-use statement, no statement of when not to use it, and no mention of the sibling tools it should be chosen over.

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

get_mortgage_ratesAktuální sazby hypoték 6 bankA

Read-onlyIdempotent

Inspect

Current published mortgage rates of 6 major Czech banks (Česká spořitelna, ČSOB, Komerční banka, UniCredit Bank, Raiffeisenbank, mBank) by fixation period, with LTV surcharges, limits and fees. Source: Rychlá Hypo (rychlahypo.cz), rates verified in the banks' calculators.

ParametersJSON Schema

Name	Required	Description	Default
`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

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds genuine context beyond that: source attribution (Rychlá Hypo, verified in bank calculators), the specific set of banks, and the ancillary data returned (LTV surcharges, limits, fees). Freshness/verification framing is useful but no caching or refresh cadence is given.

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?

Effectively two sentences, front-loaded with what is returned and then source attribution. The parenthetical list of six banks is long but earns its place by telling the agent exactly which institutions are covered.

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 no output schema, the description must convey the return shape, and it does list the categories returned (rates by fixation, LTV surcharges, limits, fees) plus source. It stops short of describing the actual structure/fields, but is adequate for a single-optional-param read tool.

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% and the fixation enum is documented in the schema itself, including the unavailable/fixation_offered=false behavior. The description only adds 'by fixation period', so it neither needs to nor does add meaning beyond the schema; baseline 3 applies.

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 resource (current published mortgage rates) and scope (6 named Czech banks, by fixation period) with the data's coverage (LTV surcharges, limits, fees). An agent can distinguish it from calculate_max_mortgage and compare_mortgages, which operate on rather than supply this data.

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?

Usage is only implied: this is the raw rates source, so an agent infers it should be called when benchmark rate data is needed. There is no explicit when-to-use, when-not, or pointer to compare_mortgages/calculate_max_mortgage as follow-ups or alternatives.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

3 tool updatesSep 30, 2026

Changedcalculate_max_mortgage11 fields changed

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)."

Changedcompare_mortgages2 fields changed

changedInput schema / properties / all_applicants_under_36 / description

Previous value: -"True if every applicant is younger than 36 (UniCredit waives the 81–90 % LTV surcharge)."New value: +"True if every applicant is younger than 36. Banks lend above 80 % LTV (up to 90 %) only to applicants under 36 (Czech National Bank limit); UniCredit also waives its 81–90 % LTV surcharge for them."

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)."

Changedget_mortgage_rates1 field changed

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)."

4 tool updatesSep 27, 2026
- First observedcalculate_max_mortgage
- First observedcompare_mortgages
- First observedget_advisor_contact
- First observedget_mortgage_rates

Related MCP Connectors

IUSTORIA – české právní kalkulačky a průvodci A
cz.iustoria
Czech law calculators (deadlines, fees, inheritance, employment) and lawyer-reviewed guides.
Legal & Compliance Education & Learning Tools
381
cnb A
dev.cz-agents
Official ČNB exchange rates — daily & historical CZK vs EUR, USD, 30+ currencies. For accounting.
Finance Government Data Open Data
326
tax-engine A
cz.freelax
Deterministic Czech OSVC tax tools for 2026: tax, insurance, deadlines, VAT and exchange rates.
Finance Government Data
141
DokladBotOAuth
cz.dokladbot
Czech accounting for freelancers: invoices, VAT, tax deadlines, bank and data box.
Finance Legal & Compliance
1

Related MCP Servers

rabobank-mortgage-demo
Finance
RemseyMailjard
A
license
A
quality
B
maintenance
Enables transparent, indicative mortgage calculations for annuities and linear mortgages, including comparisons, product listings, and interest rate information.
Updated 14 days ago (2026-09-17 15:55 UTC)
5
MIT
UK Mortgage Repayment MCP
Finance Real Estate
kstephens1
F
license
Not graded
quality
C
maintenance
Estimates UK repayment mortgage payments, including monthly payment, total interest, and overpayment impact, for use in ChatGPT.
Updated 2 months ago (2026-08-01 10:52 UTC)
-
Mortgage Calculator AI MCP
Finance Real Estate
CSOAI-ORG
A
license
Not graded
quality
B
maintenance
Mortgage Calculator AI - MCP server providing AI-powered tools and automation by MEOK AI Labs
Updated a month ago (2026-09-04 12:41 UTC)
7 npm
MIT
home-slice-mcp
Finance Real Estate
sgoley
F
license
A
quality
D
maintenance
MCP server providing mortgage calculation tools and live interest rates from Home Slice.
Updated a year ago (2025-10-05 16:02 UTC)
2
-

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.

Server Details

Available Tools

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

Glama MCP Gateway

Resources