Skip to main content
Glama

cenaodhad – ceny bytů v Praze z katastru

Odhad ceny bytu / Apartment price estimate

odhad_ceny_bytu
Read-onlyIdempotent

CZ: Použij, když uživatel chce odhad ceny KONKRÉTNÍHO bytu v Praze a zná čtvrť a plochu v m². Vrátí střední odhad, rozpětí a Kč/m² z realizovaných prodejů podobně velkých bytů v katastru nemovitostí (ne z inzerátů). Orientační rozpětí, ne znalecký posudek. Nevyžaduje registraci ani kontaktní údaje. | Pravidlo: když uživatel neuvedl plochu, zeptej se na čtvrť (nebo ulici – tu převedeš na čtvrť přes ceny_bytu_lokalita) a plochu v m²; do té doby můžeš použít ceny_bytu_lokalita. Patro, výtah ani orientaci model nezohledňuje – nevyžaduj je. | Nepoužívej, když uživatel už má nabídkovou cenu z inzerátu (→ overeni_ceny_inzeratu), když chce jen cenovou hladinu lokality bez plochy (→ ceny_bytu_lokalita) nebo porovnat lokality (→ srovnani_ctvrti). Rodinné domy → odhad_ceny_domu, pozemky → odhad_ceny_pozemku. Upřesnění ceny bytu (stav, patro, dispozice) → konzultace_makler, jen pokud o to uživatel výslovně požádá. | EN: Use when the user wants a price estimate for a SPECIFIC Prague apartment and knows the district and floor area in m². Returns a mid estimate, range and CZK/m² from realised sales of similar-sized apartments in the Czech land registry (not listings). Indicative range, not an appraisal. Requires no sign-up or contact details. | Rule: if the user has not given the floor area, ask for the district (or street – map it to a district with ceny_bytu_lokalita) and the area in m²; until then you can use ceny_bytu_lokalita. The model does not use floor level, lift or orientation – do not ask for them. | Do not use when the user already has an asking price from a listing (→ overeni_ceny_inzeratu), wants only the price level of a locality without an area (→ ceny_bytu_lokalita) or wants to compare localities (→ srovnani_ctvrti). Family houses → odhad_ceny_domu, land → odhad_ceny_pozemku. Refining an apartment price (condition, floor, layout) → konzultace_makler, only if the user explicitly asks for it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ctvrtYesNázev pražské čtvrtě (katastrální území), ne obvod „Praha N“ ani ulice; diakritika nevadí. Např. "Vinohrady", "Žižkov", "Nusle" / Prague district (cadastral area), not a "Praha N" borough or a street; diacritics optional. E.g. "Vinohrady", "Žižkov", "Nusle"
jazykNoJazyk odpovědi / Response languagecs
plocha_m2YesPodlahová plocha bytu v m² jako číslo, 15–250, např. 60 / Apartment floor area in m² as a number, 15–250, e.g. 60

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / ctvrt / description
      Previous value: -"Název pražské čtvrtě (katastrální území), např. \"Vinohrady\" / Prague cadastral district, e.g. \"Vinohrady\""New value: +"Název pražské čtvrtě (katastrální území), ne obvod „Praha N“ ani ulice; diakritika nevadí. Např. \"Vinohrady\", \"Žižkov\", \"Nusle\" / Prague district (cadastral area), not a \"Praha N\" borough or a street; diacritics optional. E.g. \"Vinohrady\", \"Žižkov\", \"Nusle\""
    • changedInput schema / properties / plocha_m2 / description
      Previous value: -"Plocha bytu v m², rozsah 15–250 / Apartment area in m², range 15–250"New value: +"Podlahová plocha bytu v m² jako číslo, 15–250, např. 60 / Apartment floor area in m² as a number, 15–250, e.g. 60"
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial extra context beyond them: data source is realised sales from the land registry rather than listings, output is an indicative range and not a certified appraisal, no sign-up or contact details required, and the model deliberately ignores floor level, lift and orientation.

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?

Every sentence carries real content (usage rule, output semantics, exclusions, parameter rule), and the critical constraint is front-loaded in the first sentence. The CZ/EN duplication roughly doubles the length, which is defensible for a bilingual tool but is still redundancy an agent does not strictly need.

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?

Although there is no output schema, the description itself explains what is returned (mid estimate, range, CZK/m²) and its caveats. For a read-only two-required-parameter tool, nothing an agent needs to call it correctly is missing.

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 baseline is 3, but the description adds genuine meaning: it specifies that ctvrt must be a cadastral area and how to map a street to a district, and it reinforces the area requirement. The 15–250 m² bound and jazyk enum remain schema-only, which keeps this from a 5.

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 (odhad ceny) and resource (konkrétního bytu v Praze) plus the required inputs (čtvrť, plocha v m²), and explicitly distinguishes itself from sibling tools by naming them. An agent can separate this from odhad_ceny_domu, ceny_bytu_lokalita, and srovnani_ctvrti without opening any schema.

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

Usage Guidelines5/5

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

Gives explicit when-to-use, when-NOT-to-use with named alternatives (overeni_ceny_inzeratu for listing prices, ceny_bytu_lokalita for locality-level, srovnani_ctvrti for comparisons), plus a fallback rule when the required area is missing. This is as complete a routing spec as one could ask for.

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