cenogram-mcp-server

Official

Overview Schema Source Related Servers Discussions Admin

compare_locations

Read-only

Compare median price per m², average area, and transaction counts across 2-5 districts side-by-side. Requires RCN district names and at least one filter like propertyType.

Instructions

Compare 2-5 districts side-by-side: median price/m², average area and transaction counts. Matches names only: call list_locations(search=...) first and use names it flags as RCN districts (rcn_district) - other names (most TERYT unit names) silently return no data. Needs at least one filter besides districts (e.g. propertyType).

Input Schema

Name	Required	Description
`floor`	No	Unit floor, multi-select: integers ('0' = parter, negatives = basement), 'Nplus' ('0plus' = ground and above), 'unknown' (none recorded). Not building storeys; rows with no floor drop out unless 'unknown' is listed.
`rooms`	No	Rooms (izby), residential units only; multi-select ('8plus' = 8 or more). Rows with no count drop out unless 'unknown' is listed.
`dateTo`	No	End date (YYYY-MM-DD)
`street`	No	Street name filter
`maxArea`	No	Maximum area in m²
`minArea`	No	Minimum area in m²
`dateFrom`	No	Start date (YYYY-MM-DD)
`maxPrice`	No	Maximum price in PLN
`minPrice`	No	Minimum price in PLN
`districts`	Yes	Comma-separated district names (2-5, unique), e.g. 'Mokotów,Wola,Ursynów'
`marketType`	No	primary (developer) or secondary (resale); the ~55% of records with no market type drop out when this is set.
`buildingType`	No	Building type (PKOB); 'unknown' = none recorded (NULL, ~39% of buildings), any other value excludes such rows.
`propertyType`	No	Property type filter (recommended - API requires at least one filter)
`unitFunction`	No	Unit function; 'unknown' = none recorded (NULL), any other value excludes such rows. Garages only via 'garage'.
`ownershipType`	No	Legal-right type (rodzaj prawa), multi-select; perpetual_usufruct = użytkowanie wieczyste; 'unknown' = none recorded.
`mpzpDesignation`	No	MPZP zoning designation, exact token match; comma-separated = OR; 'unknown' = none recorded. Same codes as search_transactions mpzpDesignation.
`transactionType`	No	Multi-select. For market analysis ALWAYS set it to exclude non-market deeds (subsidized, foreclosure, public_purpose); no-type rows (~2%) drop out unless 'unknown' is listed.
`includeDemographics`	No	Add a GUS BDL demographics block per district (county-level: density, wages, unemployment, median age, price-to-income). Districts that do not resolve to a county are omitted from it.

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv0.18.0Oct 27, 2026

changedInput schema / properties / buildingType / description

Previous value: -"Building type filter (PKOB classification). 'unknown' = no type recorded (NULL); without it such rows are excluded (~39% of buildings have no type)."New value: +"Building type (PKOB); 'unknown' = none recorded (NULL, ~39% of buildings), any other value excludes such rows."

changedInput schema / properties / districts / description

Previous value: -"Comma-separated district names to compare (2-5, must be unique). E.g. 'Mokotów,Wola,Ursynów'"New value: +"Comma-separated district names (2-5, unique), e.g. 'Mokotów,Wola,Ursynów'"

changedInput schema / properties / floor / description

Previous value: -"Floor of the unit (piętro lokalu, residential). Multi-select buckets: exact integers incl. '0' (parter) and negatives e.g. '-1' (basement), 'Nplus' e.g. '10plus' = 10 or more, '0plus' = ground and above, 'unknown' = no floor recorded (NULL). E.g. ['0','1','2'] for ground-to-2nd floor. Building storeys are a different attribute. Without 'unknown', rows with no floor are excluded."New value: +"Unit floor, multi-select: integers ('0' = parter, negatives = basement), 'Nplus' ('0plus' = ground and above), 'unknown' (none recorded). Not building storeys; rows with no floor drop out unless 'unknown' is listed."

changedInput schema / properties / includeDemographics / description

Previous value: -"Add a GUS BDL demographics block per district (county-level: population density, wages, unemployment, median age, plus a few cross-source ratios like price-to-income). Districts that don't resolve to a county are omitted from the demographics section."New value: +"Add a GUS BDL demographics block per district (county-level: density, wages, unemployment, median age, price-to-income). Districts that do not resolve to a county are omitted from it."

changedInput schema / properties / marketType / description

Previous value: -"Market type filter"New value: +"primary (developer) or secondary (resale); the ~55% of records with no market type drop out when this is set."

changedInput schema / properties / mpzpDesignation / description

Previous value: -"MPZP zoning designation prefix filter (e.g. 'terenRolniczy', 'budownictwoMieszkanioweJednorodzinne', 'budownictwoMieszkanioweWielorodzinne'). Use 'unknown' for rows with no designation recorded (NULL); distinct from the registry code 'brakMPZPLubWZ'."New value: +"MPZP zoning designation, exact token match; comma-separated = OR; 'unknown' = none recorded. Same codes as search_transactions mpzpDesignation."

changedInput schema / properties / ownershipType / description

Previous value: -"Ownership / legal-right type filter (rodzaj prawa do nieruchomości). land_ownership; perpetual_usufruct (użytkowanie wieczyste — covers both registry codes for this right); cooperative_ownership; unit_sale; ownership; unit_ownership_with_appurtenant_right; building_ownership_with_appurtenant_right. 'unknown' = no right recorded (NULL). Multi-select; e.g. ['land_ownership','perpetual_usufruct'] to compare ownership vs perpetual usufruct on undeveloped land."New value: +"Legal-right type (rodzaj prawa), multi-select; perpetual_usufruct = użytkowanie wieczyste; 'unknown' = none recorded."

changedInput schema / properties / rooms / description

Previous value: -"Number of rooms (izby) filter, residential units only. Multi-select; '8plus' means 8 or more, 'unknown' = no room count recorded (NULL). E.g. ['2','3'] for 2-3 izby flats. Without 'unknown', rows with no room count are excluded."New value: +"Rooms (izby), residential units only; multi-select ('8plus' = 8 or more). Rows with no count drop out unless 'unknown' is listed."

changedInput schema / properties / transactionType / description

Previous value: -"Transaction type filter. For market analysis, ALWAYS specify to exclude non-market transactions."New value: +"Multi-select. For market analysis ALWAYS set it to exclude non-market deeds (subsidized, foreclosure, public_purpose); no-type rows (~2%) drop out unless 'unknown' is listed."

changedInput schema / properties / unitFunction / description

Previous value: -"Unit/apartment function filter. 'unknown' = no function recorded (NULL); without it such rows are excluded. Garages appear only when 'garage' is selected, not via 'unknown'."New value: +"Unit function; 'unknown' = none recorded (NULL), any other value excludes such rows. Garages only via 'garage'."

First observedv0.5.0Jul 29, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely non-obvious behavior: silent empty results for non-RCN district names and the hidden filter requirement. It does not describe result ordering or how districts with no transactions appear, which would push it to 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.

Conciseness5/5

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

Three sentences, front-loaded with purpose, then the naming trap, then the filter prerequisite. No filler; every clause carries an operational constraint the agent would otherwise get wrong.

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 an 18-parameter read tool with no output schema, the description covers the highest-risk gaps (name matching, mandatory second filter) and names the returned metrics. Minor gaps remain: it doesn't say how districts without sufficient data are represented or whether includeDemographics affects the shape of the response.

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. The description still adds value beyond the schema for the key parameter: districts matches by name only, requires RCN-flagged names, and silently fails otherwise — semantics the schema does not convey. It also hints at propertyType as the typical second filter.

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 and resource (compare 2-5 districts side-by-side) plus the exact output metrics (median price/m², average area, transaction counts). This is clearly distinguishable from sibling aggregators like get_price_statistics or get_market_overview, which are not district-comparison tools.

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?

Explicitly routes the agent through a prerequisite (call list_locations(search=...)) and names the condition that gates success (only names flagged as rcn_district). It also states an exclusion: TERYT unit names silently return no data, and notes the requirement of at least one filter besides districts, e.g. propertyType.

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

compare_locations

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools