7M+ real estate transactions from Poland's RCN registry. Search, compare, and analyze prices.
Scored across 22 tools
Most tools target distinct resources, but several overlap: get_parcel_report subsumes get_parcel_mpzp, get_parcel_land_class and get_transaction_layer, while get_price_statistics, get_price_distribution, search_transactions and get_market_overview all expose price views. The descriptions explicitly steer between them, so misselection risk is mitigated but not eliminated.
All tool names use snake_case verb_noun patterns (get_*, list_*, estimate_*, resolve_*, search_*, compare_*), with consistent domain prefixes such as parcel and price. There is no mixed casing or vague naming.
22 tools is heavy for a single server; the broad real-estate domain justifies some breadth, but per-layer parcel tools and multiple beta analytics add density. Each tool has a niche, yet several could be consolidated without losing core functionality.
The surface covers transactions, parcels, zoning, permits, prices, demographics, flood risk, infrastructure and valuation, so core workflows are well supported. Minor gaps remain around direct transaction-detail or broader listing/building lookups, but agents can work around them.
Compare 2-5 districts side-by-side: median price/m², average area and transaction counts. Filters drop rows lacking the value unless 'unknown' is listed. 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).
| Name | Required | Description | Default |
|---|---|---|---|
| floor | No | Unit floor, multi-select: integers ('0' = ground, negatives = basement), 'Nplus', 'unknown' (no floor). Not building storeys. | |
| rooms | No | Rooms (izby), residential units only, multi-select ('8plus' = 8+); 'unknown' = no count. | |
| 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); untyped records (~55%) drop out. | |
| buildingType | No | Building type (PKOB); 'unknown' = none recorded (~39%). | |
| propertyType | No | Property type: building = no land; house with plot = developed_land (recommended - API requires at least one filter) | |
| unitFunction | No | Unit function; 'unknown' = none recorded. Garages only via 'garage'. | |
| ownershipType | No | Legal right (rodzaj prawa), multi-select; 'unknown' = none recorded. | |
| mpzpDesignation | No | MPZP zoning designation, exact token match; comma-separated = OR (e.g. 'MN,MW'); 'unknown' = none recorded. An unrecognised value triggers a warning listing all codes. | |
| transactionType | No | Multi-select. For market analysis ALWAYS set it to drop non-market deeds (subsidized, foreclosure, public_purpose); untyped rows drop out unless 'unknown'. | |
| includeDemographics | No | Add a GUS BDL block per district (county-level: density, wages, unemployment, median age, price-to-income); districts not resolving to a county are omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. Beyond that the description discloses the non-obvious failure mode (silent empty results for non-RCN district names) and the row-dropping rule for missing values unless 'unknown' is listed — real behavioral detail not present in annotations. It stops short of describing response shape/pagination, but the metric list partly covers that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences that are front-loaded with purpose, then caveats, then prerequisites — no filler. The middle sentence about filter row-dropping is compact but slightly cryptic on first read, and the required-filter caveat would be easier to scan if it preceded the name-matching rules.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 18-parameter tool with no output schema, the description supplies the output metrics, the mandatory-filter rule, and the name-resolution trap — the three things most likely to cause a failed call. The includeDemographics option and the interaction between the many optional filters are left entirely to the schema, which is acceptable given 100% coverage but is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 earns a bump by adding meaning the schema cannot: 'districts' must be RCN district names sourced from list_locations, and at least one non-district filter must accompany it. The note that filters drop rows lacking the value unless 'unknown' is listed clarifies the unknown-handling semantics of the enum arrays.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb, resource and arity: 'Compare 2-5 districts side-by-side', and immediately names the exact outputs (median price/m², average area, transaction counts). This is clearly distinguishable from sibling aggregate tools such as get_price_statistics or get_market_overview, and it explicitly routes the agent away from itself for name resolution by pointing to list_locations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit prerequisite chain ('call list_locations(search=...) first and use names it flags as RCN districts') plus an explicit precondition ('Needs at least one filter besides districts'). It also states a negative condition (non-RCN names, most TERYT unit names, silently return no data), which is exactly the when-not guidance an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[Beta] Estimate an undeveloped plot's market value from comparable registered transaction prices near a point. An orientation estimate, NOT a certified appraisal. Address by lat + lng OR parcelId (the parcel centroid is used) - exactly one. area (m², 100–1000000) is REQUIRED with lat/lng; with parcelId it defaults to the cadastre area. landType (plot or agricultural) is chosen by the caller. Returns the estimate per m² and per hectare, a likely and a wide range, a confidence band, the comparable count and an as_of date (lags by county: NOT comparable across areas with different as_of). Comparables are chosen by the designation recorded in the transaction register (not a local zoning plan), so this does not assert the plot is buildable. Undeveloped land only. Too few comparables, or an undeterminable area → no estimate. Costs 5 API tokens, refunded when none is produced. Can be switched off for maintenance ("temporarily unavailable"). Aggregates exclude fractional shares and non-market deeds.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Plot latitude (WGS84); pair with lng. This OR parcelId (area then required). | |
| lng | No | Plot longitude (WGS84); pair with lat. This OR parcelId (area then required). | |
| area | No | Plot area in m² (100–1000000). REQUIRED with lat/lng; with parcelId read from the cadastre when omitted. | |
| landType | No | Comparable segment: plot (building plot, default) or agricultural (farmland); the caller chooses. | |
| parcelId | No | Full cadastral id or internal UUID; the parcel centroid is used. Instead of lat/lng. | |
| includeComps | No | Echo the comparables weighed (default true); false = estimate only. | |
| mpzpDesignation | No | Narrow comparables to a recorded land-designation token (e.g. 'budownictwoMieszkanioweJednorodzinne'); 'unknown' = none recorded. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/openWorld annotations: token cost of 5 with refund on no-estimate, possible maintenance unavailability, no-estimate conditions (too few comparables, undeterminable area), as_of county lag that makes results non-comparable across areas, and aggregation exclusions for fractional shares and non-market deeds. It also discloses the key methodological caveat that comparables follow register designation, not local zoning, so buildability is not asserted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded with the beta marker, followed by addressing, then return shape, then caveats and cost. It is dense and long, but nearly every sentence carries decision-relevant information; the as_of/lag point is repeated in spirit and could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description compensates by enumerating the returned fields (per m², per hectare, likely and wide range, confidence band, comparable count, as_of). Combined with the failure modes, cost model, and methodological limits, an agent has everything needed to call it and to interpret or discard the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameter meaning is already documented; the description still adds real semantics by emphasizing the exactly-one exclusivity between coordinate and parcelId addressing, the cadastre-area default, and the caller's responsibility for landType. It adds little on includeComps and mpzpDesignation beyond the schema, so not a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise verb and resource ('Estimate an undeveloped plot's market value from comparable registered transaction prices'), adds the addressability model (point or parcelId), and scopes itself with 'Undeveloped land only' and 'NOT a certified appraisal'. That scope line effectively separates it from the sibling estimate_value and from the transaction-listing tools without needing to name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear selection rules: exactly one of lat+lng or parcelId, area required with coordinates, landType chosen by the caller, undeveloped land only. It stops short of naming alternatives such as estimate_value or get_transaction_farmland for developed property or raw comps, so the agent must infer the routing for those cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[Beta] Estimate an apartment's market value from comparable registered transaction prices near a point. An orientation estimate, NOT a certified appraisal: it ignores condition, finish standard and floor. Address by lat + lng OR parcelId (the parcel centroid is used) - exactly one. area (usable m², 10–250) is REQUIRED. Returns the point estimate, a likely and a wide range, a confidence band, the comparable count and an as_of date (lags by county: NOT comparable across cities with different as_of). Apartments only; for a building plot or farmland use estimate_land_value. Too few comparables → no estimate. Costs 5 API tokens, refunded when none is produced. Aggregates exclude fractional shares and non-market deeds.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Apartment latitude (WGS84); pair with lng. This OR parcelId. | |
| lng | No | Apartment longitude (WGS84); pair with lat. This OR parcelId. | |
| area | Yes | Apartment usable area in m² (REQUIRED, 10–250). | |
| rooms | No | Room count (1–10); narrows comparables to ±1 room. | |
| market | No | Restrict comparables to the primary (new-build) or secondary market. | |
| parcelId | No | Full cadastral id (slash or dash form) or internal UUID; the parcel centroid is used. Instead of lat/lng. | |
| includeComps | No | Echo the comparables weighed (default true); false = estimate only. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already declaring readOnly/non-destructive/openWorld=false, the description still adds substantial context beyond them: the not-a-certified-appraisal caveat and what it ignores (condition, finish standard, floor), the beta status, the comparability limitation of as_of lags across counties, the cost of 5 API tokens with refund on no-estimate, and the exclusion of fractional shares and non-market deeds. This is unusually complete disclosure for a read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but well front-loaded: purpose first, then addressing rules, then return shape, then sibling routing and cost. Every sentence carries information, though the parenthetical caveats make it slightly heavy to parse in one pass.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description compensates fully by naming the return components (point estimate, likely and wide range, confidence band, comparable count, as_of). Combined with the cost model, the minimum-data failure mode, and the sibling alternative, nothing needed to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 real meaning the schema cannot express: the mutual exclusivity of lat/lng and parcelId ('exactly one') and that the parcel centroid is used when parcelId is supplied. It also reinforces that area is REQUIRED, though the schema already marks it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Estimate an apartment's market value from comparable registered transaction prices near a point') and immediately scopes it as apartments only, naming estimate_land_value for the alternatives. An agent can distinguish it from the land-estimation sibling 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit routing rules: 'Apartments only; for a building plot or farmland use estimate_land_value', plus the addressing rule 'lat + lng OR parcelId - exactly one' and the failure condition 'Too few comparables → no estimate'. These are exactly the when-to-use and when-not-to-use signals an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Local statistics for a Polish location from GUS BDL (Poland's Central Statistical Office): ~50 indicators across 11 categories (population, economy, housing, planning, infrastructure, environment, safety, education, prices) plus a few derived metrics. Address by location or teryt (codes from list_locations); neighborhoods/osiedla are NOT addressable. Returns the requested level PLUS all parent levels. Cost: 1 token.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Single year (2003-present); exclusive with yearFrom/yearTo. Omit for the latest year per indicator. | |
| teryt | No | TERYT: 2-digit voivodeship (14), 4 county (1465), 6 or 7 gmina (1465011). 7th digit: 3 = urban-rural gmina overall, 4/5 = urban/rural part only, 8 = Warszawa district (1465108 = Śródmieście). Wins over location. | |
| yearTo | No | End year for a time series (max current year + 1). | |
| category | No | Categories to return; omit for all. | |
| location | No | City, county, gmina or district name (e.g. 'Warszawa', 'Wieliczka'): city/county → county level, gmina → that gmina, a Warszawa district ('Mokotów') → that district, another city's delegatura ('Kraków-Podgórze') → its parent county. Shared name → candidates; pass one as teryt. Use this OR teryt. | |
| yearFrom | No | Start year for a time series (min 2003). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, closed-world, non-destructive behavior, so the description wisely spends its words elsewhere: it discloses that results include the requested level PLUS all parent levels, that ambiguous names yield candidate lists requiring a teryt, and that a call costs 1 token. That is meaningful context beyond the annotations; only the exact response shape/pagination is left unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the value proposition and indicator/category scope, followed by addressing rules and cost. Dense and mostly waste-free, though the parenthetical category list and multi-clause addressing sentence make it heavier than strictly necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does tell the agent that parent levels are returned in addition to the requested level and that a query costs 1 token, which is the key completeness signal here. It could say more about failure modes (unknown location, missing indicator) but covers the essentials for a 6-param, all-optional read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents year, teryt formats, yearFrom/yearTo, category enum, and location precedence — the description largely restates this. It adds only the pointer that teryt codes are obtainable from list_locations and the note that derived metrics exist. Baseline 3 is appropriate when the schema carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: local statistics for a Polish location from GUS BDL, with concrete scope (~50 indicators across 11 named categories) and derived metrics. It clearly delimits what is addressable (locations/teryt, not neighborhoods). It does not explicitly contrast itself with siblings like compare_locations or get_price_statistics, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear usage context: address by location name or teryt, teryt codes come from list_locations, and neighborhoods/osiedla are explicitly NOT addressable — a real exclusion. It also notes teryt wins over location when both are supplied. It lacks explicit routing guidance against sibling tools that overlap (e.g., get_price_statistics, get_market_overview).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
EXPERIMENTAL (beta): may change or be withdrawn; no critical workflows on it. What share of a Polish county's real-estate transactions sit on land in a mapped flood-hazard zone, by severity, from the RCN registry. Bands are return periods: high = most frequent (~1-in-10-year), medium ~1-in-100, low = rarest (~1-in-500). Counts land in a mapped zone only; absence of a zone is never asserted as 'safe' (an area may be unmapped). All-time, no date window; suppressed below 5 assessed transactions. Coverage is county-level: unless the location is a major city you know is covered, call list_coverage(metric="flood_risk") FIRST or pass a 4-digit county TERYT.
| Name | Required | Description | Default |
|---|---|---|---|
| teryt | No | TERYT code. 4 digits = county (e.g. 1465 = Warszawa). Longer codes (gmina/precinct/district) resolve to the county. Wins over location. | |
| location | No | City or county name (e.g. 'Warszawa', 'Gdańsk'). District and gmina names are accepted ('Kraków-Podgórze', 'Wieliczka'), answered at the parent county with a note; a gmina name shared by counties returns candidates. A town within a larger powiat or an osiedle may 404 - check the catalog or use teryt. This OR teryt. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, non-destructive, closed-world, but the description adds substantive behavior: all-time with no date window, suppression below 5 assessed transactions, counting only land inside a mapped zone, and the explicit refusal to assert safety from absence of a zone. Those caveats are not recoverable from the annotations and materially change how an agent should interpret results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the experimental warning, then purpose, then band definitions, then caveats, then the routing hint. It is dense but each sentence carries information; the band definitions and the 'not safe' caveat are the only parts that could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 conveys the return shape (share by severity band), the time scope, the suppression threshold, and the interpretation limits. For a two-parameter read-only metric tool, an agent has everything needed to call it and read the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are fully documented in the schema, including TERYT length rules and location fallback behavior. The description reinforces the county-level resolution constraint but adds little syntax or format detail beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise measure (share of a Polish county's real-estate transactions on land in a mapped flood-hazard zone, by severity) plus the data source (RCN registry). The severity bands are defined inline as return periods, so an agent knows exactly what the tool produces and how it differs from siblings like get_transaction_layer or get_parcel_land_class.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit prerequisite workflow: call list_coverage(metric="flood_risk") first or pass a 4-digit county TERYT unless the location is a known major city. It also names the alternative (list_coverage) and states the condition that selects it, plus the beta/experimental caveat about critical workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Signals that a Polish municipality is about to build infrastructure, from three public sources: tenders in the national procurement bulletin (rolling 12 months), membership in an agglomeration of the national urban waste-water programme, and the municipality's planned capital expenditure from its multi-year forecast. State these limits when reporting: the bulletin has only contracts BELOW EU thresholds (from 2021), so the largest investments are invisible; a tender is attributed to the contracting authority's SEAT, not the works location, so the counters include municipal authorities only while the notice list shows every authority with a flag. Absence of tenders is NOT evidence that a municipality is not investing. Cost: 1 token.
| Name | Required | Description | Default |
|---|---|---|---|
| teryt | No | TERYT code (from list_locations): 6 or 7 digits = one municipality (e.g. 146501), 4 digits = a county aggregate (e.g. 1465). Wins over location. | |
| location | No | City, county, gmina or district name (e.g. 'Warszawa', 'Krotoszyn'): city/county → every municipality in the county, gmina → that gmina alone, a Warszawa district ('Mokotów') → that gmina, another city's delegatura ('Kraków-Podgórze') → its parent county. Shared name → candidates; pass one as teryt. Use this OR teryt. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld annotations, the description discloses cost (1 token) and three substantive data caveats: coverage limited to below-EU-threshold contracts, attribution by contracting authority seat rather than works location, and the critical warning that absence of tenders is not evidence of no investment. That last point prevents a specific, likely reasoning error and is exactly the kind of disclosure annotations cannot carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in the first sentence, and the caveat block is dense but each clause carries real information (threshold limits, seat attribution, false-negative risk, cost). It is a long single block rather than separated reporting instructions, which makes it slightly harder to scan than it needs to be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does most of the work and even hints at the response shape ('counters include municipal authorities only while the notice list shows every authority with a flag'). It does not state what happens when neither teryt nor location is supplied (both parameters are optional), which is the one gap an agent could stumble on.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains the TERYT digit-length conventions, the teryt-over-location precedence, and name-resolution fallbacks. The description adds nothing about either parameter, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Signals that a Polish municipality is about to build infrastructure') and enumerates the three underlying sources, which is far more specific than the title alone. It does not, however, contrast itself with nearby siblings such as get_permits_in_area or get_transaction_permits, so an agent must infer the boundary from the sources listed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the three-source framing and the 'State these limits when reporting' directive, which tells the agent how to present results. There is no explicit when-to-use / when-not-to-use guidance and no named alternative for a caller who actually wants permit or transaction records rather than a forward-looking signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start here for the shape of the whole Polish transaction database (not one place; for a place use get_price_statistics or search_transactions): total count, date range, breakdown by property and market type, top locations, price statistics. marketType is unknown for ~55% of records, transaction_date missing for ~1.7%.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only and non-destructive annotations, it discloses important data-quality limitations: marketType is unknown for about 55% of records and transaction_date is missing for about 1.7%. These caveats help an agent interpret aggregates cautiously, though details such as how "top locations" is ranked or limited are not specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads the recommended use, scope, and sibling alternatives, then lists the returned overview components and key data caveats. Its two dense sentences contain no filler or redundant restatement of the annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-input aggregate read tool, the description covers scope, selection guidance, alternatives, expected content, and material data limitations. Despite the absence of an output schema, an agent has enough information to choose the tool and set appropriate expectations for its results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so there is no parameter behavior requiring explanation. The description appropriately clarifies the fixed whole-database scope instead of inventing filtering options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource and scope precisely: an aggregate overview of the entire Polish transaction database, including counts, dates, breakdowns, locations, and price statistics. It explicitly distinguishes this whole-database view from single-place analysis using get_price_statistics or search_transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Start here" gives a clear entry-point recommendation, while "not one place" states when not to use it. The named sibling tools provide concrete alternatives for place-specific requests.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The official land-use and soil-quality classification of one land parcel and what it implies for taking the land out of agricultural use. Use it only for that question; for anything else about the parcel call get_parcel_report (one flat-price call, includes this classification). Returns the land-use categories and soil grades entered for the parcel, whether any grade is in the protected I-III range, whether the parcel is inside a city boundary (changes the rule), and a re-designation note with the date the legal state was verified. They come back as SETS with no area, so the answer can never say which category prevails or give a share. Answers only where the county publishes the classification; many counties, including several large cities, do not. States: covered; covered_no_data (published, none for this parcel; billed); not_covered (county does not publish it, or parcel not held; refunded); not_computed (timed out; refunded, retry). Costs 4 API tokens, refunded on not_covered and not_computed. Not legal advice, and never a statement that a parcel can or cannot be built on.
| Name | Required | Description | Default |
|---|---|---|---|
| parcelId | Yes | Cadastral id ('142907_2.0014.342/5' or '-' form) or internal UUID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, yet the description adds substantial independent context: cost of 4 tokens, refund policy on not_covered and not_computed, the four coverage states, and the caveat that results are sets with no area so no share or prevailing category can be computed. It also disclaims legal-advice and buildability interpretations, which matters for a read-only tool whose output is easily over-interpreted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is front-loaded with the purpose and the sibling routing before the operational detail, and essentially every sentence carries distinct information (scope, output shape, coverage, cost, caveats). It is dense and long for a one-parameter tool, but there is little that could be cut without losing decision-relevant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only lookup with no output schema, the description covers what comes back, what it cannot express, when data is unavailable, the four result states with billing consequences, and interpretive limits. An agent has everything needed to call it, price it, and interpret the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter and the schema documents it fully (cadastral id or internal UUID, 100% coverage), so the schema carries the parameter burden. The description adds nothing about the identifier format or behavior, which is acceptable at high coverage but is the baseline rather than added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (one land parcel's official land-use and soil-quality classification) plus a specific implied question (taking land out of agricultural use). It also explicitly distinguishes itself from get_parcel_report, so an agent can tell which tool answers which question without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the single question this tool answers, says to use it only for that, and routes any other parcel question to get_parcel_report, noting that the broader report also includes this classification. When-to-use, when-not-to-use, and the alternative are all present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The local spatial development plans (MPZP) that cover one land parcel - per plan: title, resolution, legal status, share of the parcel, links, check date; if the state is unknown, get_parcel_report(preset="zoning") adds the general plan (POG) and a nearby-deeds signal, not a finding on the designation. Use it for "which local plan covers this parcel"; for anything else call get_parcel_report (one flat-price call, includes this section). It is not the general plan (POG, plan ogólny), a separate instrument in get_parcel_report's planning layer and get_transaction_layer(layer="planning"). Designations come in the municipality's own wording (not a statutory code) for the part of the parcel inside an in-force plan. States: in_plan (an in-force plan covers it); no_plan (our plan set for the municipality is complete and none covers the parcel on the stated date; draft plans still listed; billed); unknown (no or incomplete municipal data, a plan of unknown legal status, or a parcel we do not hold; NEVER a claim that no plan exists; refunded); not_computed (timed out; refunded, retry). Costs 4 API tokens, refunded on unknown and not_computed. The extent of a plan is not a statement about what may be built on the parcel. Not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| parcelId | Yes | Cadastral id ('142907_2.0014.342/5' or '-' form) or internal UUID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnly/openWorld/non-destructive, but the description discloses cost (4 API tokens), the refund policy (unknown, not_computed), timeout behavior, and the meaning of each state including the explicit warning that 'unknown' is never a claim that no plan exists. It also adds scoping caveats (extent is not a buildability statement, not legal advice) that annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is front-loaded: what it returns, then when to use it, then what it is not, then the state vocabulary and cost. It is dense but each block carries decision-relevant information; the state enumeration is long but necessary since those values drive follow-up behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by listing the returned fields per plan (title, resolution, legal status, share, links, check date) and by fully defining the state vocabulary and its billing consequences. An agent has everything needed to decide, call, and interpret the result, including what to do on unknown or not_computed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parcelId parameter is already documented in the schema with both cadastral-id formats and UUID. The description only implies the input is a parcel and adds no format or validation detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first clause names a specific verb and resource ('local spatial development plans (MPZP) that cover one land parcel') and enumerates exactly what is returned per plan. It then explicitly disambiguates from siblings: not the general plan (POG), not get_transaction_layer(layer="planning"), and not the full get_parcel_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a literal selection rule ('Use it for "which local plan covers this parcel"') and redirects everything else to get_parcel_report, noting that report call already includes this section. It also names the fallback path for unknown state (get_parcel_report(preset="zoning")) so the agent knows the next call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The whole dossier for one land parcel in one call - prefer it over the per-layer parcel tools. Contains the parcel core (location, area, land use, designation); fourteen layers (flood, heritage, landslide, subsurface, surroundings, transit, general-plan zoning (POG), local plans (MPZP), buildings, building activity, agricultural eligibility, land/soil class, nature, road access); the parcel's transactions (newest first, up to 20); local price context (county and gmina median zł/m², last 12 months); municipal context (demographics, infrastructure signals); and a parcel-shape section (outline geometry only). For a coordinate or 'locality + number' use resolve_parcel first; for a street address use list_parcels_in_area. For the plan or designation pass preset="zoning" (core, MPZP, POG, nearby-designation signal only). Section states: covered; covered_no_data (checked, nothing found; billed); not_covered (outside our data; refunded); not_computed (timed out; refunded - the report can be partial). The local-plan section answers in_plan / no_plan / unknown (unknown is never a claim that no plan exists). Context sections use full / low_sample / suppressed / no_data (shape: full / no_data). Long lists are capped with a count. Reading it: the nearby designation signal comes from RCN deeds of neighbouring land, not the planning register - it describes the neighbourhood, not this parcel; confirm with the local plan (MPZP) or a zoning decision. Neither it nor the shape section says whether a parcel can be built on or divided. Construction age is an ESTIMATE with an interval (permit records start in 2016), often "not established". Costs 45 API tokens (preset="zoning": 11), billed by outcome: an unresolvable parcel is refunded; a resolved one with no layer data pays only the 1-token core floor; with a covered layer, in full. Requests are rate-limited per API key per minute (parallel agents on one key share it). On "Too many requests", wait the given seconds and retry sequentially.
| Name | Required | Description | Default |
|---|---|---|---|
| preset | No | "zoning": planning sections only (11 tokens). | |
| parcelId | Yes | Cadastral id ('142907_2.0014.342/5' or '-' form) or internal UUID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, openWorld), yet the description adds substantial behavior: token costs and outcome-based billing/refunds, section states including partial reports on timeout, capped lists, and rate-limit retry semantics. It also discloses important interpretive caveats (nearby-designation signal derived from RCN deeds, construction age an estimate with an interval) that an agent could not infer from structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but front-loaded: purpose first, then routing, then section semantics, then reading caveats, then cost/rate limits. Nearly every sentence carries decision-relevant information, though the single long block of section-state definitions could be tightened or split for faster scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter, high-fan-out report tool with no output schema, the description covers return contents, section-state vocabulary, partial-result semantics, cost model, and known interpretive pitfalls. An agent has everything needed to decide, call, budget, and correctly read the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description goes further by quantifying what preset="zoning" returns (core, MPZP, POG, nearby-designation signal only) and its 11-token cost versus 45 for full. It doesn't add format detail for parcelId beyond the schema's cadastral/UUID note.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource+scope ('The whole dossier for one land parcel in one call') and enumerates the exact contents (parcel core, fourteen named layers, transactions, price context, municipal context, shape). It explicitly distinguishes itself from the per-layer parcel siblings, so an agent can route without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit routing: resolve_parcel first for coordinates or 'locality + number', list_parcels_in_area for street addresses, and preset="zoning" for plan/designation questions only. It also names the alternative to prefer ('per-layer parcel tools'), which is the strongest form of when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the building permits and works notifications registered since 2016 within a radius of a point - issued decisions only, matched through the parcel geometry we hold, which is near-complete but not the whole cadastre - to see what is being built nearby. Returns cases newest first, NOT nearest first (a permit and a notification for one investment are two cases), plus an aggregate by year and statutory object category over ALL matched cases (do not add it up across pages) with the permit/notification split and building volume. truncated = more cases than the limit: pass the returned cursor back with the same filters. Examples: apartment blocks → categories=[XIII]; drop utility-network noise (XXVI can be most of a list) → excludeCategories=[XXVI]; utility works as a sign that land is being serviced for development → categories=[XXVI]. For "how many / how much" pass aggregateOnly=true (same price). The list is by date: for what is closest use a smaller radiusKm (e.g. 0.3) instead of paging; radiusKm is 0.1–2 (default 2), for a wider area make several calls for neighbouring centres. Reading it: decision outcomes (granted or refused) are not held; notifications only where accepted without objection; pending cases not at all. Matching uses the parcel's current identifier and geometry, so cases filed before a split or merge may be missed, parcels without geometry are not searched and a number with a sheet segment may match less exactly. The answer states how many parcels we hold in the circle (0 = no data for the area) and the last refresh date (periodic, not live). A volume marked suspect stays in the sums. A short or empty list is never a statement that nothing is being built. A query over the time limit returns an error asking for a smaller radius. Coordinates: for a parcel use resolve_parcel (or resolve_parcel(prefix)); for a street list_parcels_in_area(location, street) and a returned row's centre point; otherwise from the user - never guess them. Cost: 5 API tokens per call, also for an empty list; each page is a separate call. Can be switched off for maintenance ("temporarily unavailable").
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | Circle centre latitude (WGS84, Poland); never guessed. | |
| lng | Yes | Circle centre longitude (WGS84, Poland); never guessed. | |
| limit | No | Cases in the list, 1–200 (default 50). | |
| cursor | No | Cursor from the previous answer (next page); pass it back unchanged with the same filters. Not with aggregateOnly. | |
| dateTo | No | Window end, YYYY-MM-DD, inclusive, not before dateFrom. When older than two years, pass dateFrom as well. | |
| intent | No | multi_family = categories [XIII], single_family = [I] (incl. semi-detached and terraced), all = no filter (default). Not with categories. | |
| dateFrom | No | Window start, YYYY-MM-DD (decision date; intake date for notifications). Default two years back; earlier than 2016-01-01 counts as 2016-01-01. | |
| radiusKm | No | Radius in km, 0.1–2 (default 2). | |
| worksType | No | new_construction (default) or all (adds extensions, demolitions and other works). | |
| categories | No | Keep only these object categories (Roman numerals I–XXX). Not with intent other than all; must not overlap excludeCategories. | |
| aggregateOnly | No | true = only the aggregate (year × category counts, split, volumes), no case list. Same price; not with cursor. | |
| excludeCategories | No | Drop these object categories (cases without a category stay). Must not overlap categories. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, non-destructive, closed-world, but the description adds genuinely new behavioural facts: sort order is date not distance, one investment can yield two cases, the aggregate spans ALL matched cases and must not be summed across pages, truncated/cursor semantics, silent error on time-limit overrun, 5-token cost even for empty results, periodic (not live) refresh, and possible maintenance shutdown. It also discloses coverage limits (near-complete but not whole cadastre, parcels without geometry unsearched, split/merge misses, missing decision outcomes) and warns that a short list is not evidence of no construction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Strongly front-loaded: purpose first, then return semantics, then worked examples, then interpretation caveats, then coordinates and cost - an agent can stop reading after the first sentence and still be safe. It is, however, a dense ~330-word block with a few restatements of schema constraints (radius range/default), so it is efficient rather than tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter tool with no output schema, the description covers return shape, ordering, aggregation behaviour, pagination, empty-result interpretation, data-refresh staleness and failure modes. There is nothing an agent needs to know to call it correctly or to avoid misreading its output that is missing here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 earns extra by giving concrete category-to-intent mappings, the excludeCategories-vs-categories interplay, the 'same price' rationale for aggregateOnly, and the tradeoff between radiusKm and paging. Some content merely restates schema facts (radiusKm 0.1-2 default 2), which keeps it short of a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb, resource and scope: lists building permits and works notifications within a radius since 2016, issued decisions only, matched via parcel geometry. It also states up front what the tool is for ('to see what is being built nearby') and distinguishes itself from resolve_parcel / list_parcels_in_area, which it names as the coordinate sources rather than as competitors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit routing advice is given for each mode: category examples (apartment blocks -> XIII, utility noise -> excludeCategories XXVI, utility works as a servicing signal -> XXVI), aggregateOnly=true for 'how many / how much', a smaller radiusKm instead of paging for proximity, and several calls around neighbouring centres for wider areas. Coordinate sourcing is prescribed (resolve_parcel, list_parcels_in_area, or the user - 'never guess them'), which is exactly the when/when-not guidance an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
National histogram (all Poland) of transactions per price range - use it for the overall price structure of the market. No location filter (location/teryt are ignored); for one place use get_price_statistics or search_transactions.
| Name | Required | Description | Default |
|---|---|---|---|
| bins | No | Number of price bins (5-50, default 20) | |
| teryt | No | Ignored: histogram is national. | |
| location | No | Ignored: histogram is national. | |
| maxPrice | No | Maximum price to include (default 3,000,000 PLN) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly=true, destructive=false, openWorld=false), so the description's real contribution is the scope constraint: results are always national and location/teryt are silently ignored. That is a meaningful behavioral caveat beyond the annotations. It does not describe the returned shape (bin edges vs counts) or how maxPrice truncates/affects binning, which keeps it below 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, and the national-scope constraint is front-loaded before the routing advice. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a four-optional-parameter read tool with no output schema, the description covers scope, the ignored-filter trap, and fallback siblings — enough to invoke correctly. The only real gap is the shape of the returned histogram (bin boundaries, count field names), which an agent would need to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already labels location and teryt as 'Ignored: histogram is national', so the description largely reiterates that rather than adding new meaning. It also says nothing about bins or maxPrice semantics, leaving the schema to carry those. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 — a national histogram of transactions per price range — plus a stated purpose ('overall price structure of the market'). It explicitly distinguishes itself from get_price_statistics and search_transactions, so the agent can separate it from siblings without reading any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use ('overall price structure'), when-not (no location filter; location/teryt are ignored), and names the alternatives to use for a single place. This is the full when/when-not/alternatives pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
EXPERIMENTAL (beta): may change or be withdrawn; no critical workflows on it. Asking-vs-transaction price spread for a Polish city or county: how far the median asking price per m² of apartments for sale sits above (or below) the median apartment transaction price per m² (RCN). spread_pct = (asking − transaction) / transaction × 100; it can be NEGATIVE in premium-secondary cities (a valid answer). Different sources, so an approximation; not comparable across cities with different as_of dates. Both sides need at least 5 samples or the result is suppressed. marketType 'all' (default) = whole market; 'secondary' or 'primary' narrows both sides to that segment. Coverage: counties (miasta na prawach powiatu) plus Warszawa's 18 districts, only cities with asking-sale data. A gmina name resolves to its county (shown in the answer); a name shared by gminas in several counties returns candidates. Aggregates exclude fractional shares and non-market deeds.
| Name | Required | Description | Default |
|---|---|---|---|
| teryt | No | TERYT: 4 digits = county (1465 = Warszawa); 6 digits = a Warszawa district (146510 = Śródmieście); other longer codes truncate to the county. Wins over location. | |
| location | No | County-level city name (a miasto na prawach powiatu or a catalog entry, e.g. 'Warszawa', 'Gdańsk'); a Warszawa district ('Mokotów') narrows to it, 'Kraków-Podgórze' resolves to its parent county; an osiedle 404s - use teryt. This OR teryt. | |
| areaBucket | No | Apartment area range in m², restricting both sides (all = whole stock, default). Buckets are not additive. | |
| marketType | No | Transaction-side segment: 'all' (default, matched to mixed sale offers), 'secondary' or 'primary'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description layers substantial extra behavior on top: beta/experimental status, a 5-sample suppression rule on both sides, that the two sides come from different sources and are therefore approximate, and that aggregates exclude fractional shares and non-market deeds. These are non-obvious operational facts an agent could not infer from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The beta warning is correctly front-loaded, followed by the metric definition and then caveats in descending importance. It is dense and a few clauses run long (coverage and gmina resolution are compressed into single sentences), but no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return burden and does explain the key output field (spread_pct), that the resolved county appears in the answer, and that ambiguous names return candidates. It does not describe the rest of the response shape or whether sample counts are returned, which would matter for judging the 5-sample suppression.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are already documented, including enum meanings and the teryt-over-location precedence. The description mostly restates that 'all' means the whole market and that primary/secondary narrow both sides, which duplicates the schema rather than adding new parameter-level meaning; the genuinely additive bits (spread definition, suppression threshold) are not parameter-specific.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific metric (asking-vs-transaction price spread per m²), states the exact formula (spread_pct = (asking − transaction) / transaction × 100), and scopes it to Polish counties and Warszawa districts. It is clearly separable from siblings like get_price_statistics or get_price_distribution, which do not compute an asking/transaction gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives real usage context: coverage limits (only cities with asking-sale data), the caveat that results are not comparable across different as_of dates, that a negative spread is a valid answer, and that a gmina name resolves to its county while ambiguous names return candidates. It stops short of explicitly routing the agent to a sibling (e.g. list_price_spread_locations for coverage discovery or get_price_statistics for absolute prices).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Price per m² statistics for residential apartments by location; for other property types use search_transactions. Default window: last 24 months (same as the search_transactions median); period="all" for full history. The response states the period used. Notarial-deed prices, not asking prices; coverage varies by county (some have data gaps of 5+ years).
| Name | Required | Description | Default |
|---|---|---|---|
| teryt | No | TERYT: 4 digits = county (1465 = Warszawa), 6 = Warszawa district (146505 = Mokotów). A gmina code is an error, unlike get_price_spread (narrows to county): pass the county. Wins over location. | |
| dateTo | No | Custom window end, YYYY-MM-DD, inclusive (default today). Overrides period. | |
| period | No | Window: "24m" (default) = last 24 months, "all" = full history. Ignored when dateFrom or dateTo is set. | |
| dateFrom | No | Custom window start, YYYY-MM-DD. Overrides period. | |
| location | No | Location name; 'Warszawa'/'Kraków'/'Łódź' expand to all sub-districts, other names use case-insensitive partial match (e.g. 'Wrocł' matches 'Wrocław'). Omit for all Poland. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/destructive annotations, the description discloses substantive behavioral context: values are notarial-deed prices rather than asking prices, coverage varies by county with gaps of 5+ years, and the response self-reports the period used. It also pins the default window to the same 24 months used by search_transactions, which helps the agent keep comparisons consistent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences with the primary purpose and sibling routing front-loaded, followed by default-window semantics and data-quality caveats. No filler, and every clause carries decision-relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description covers property-type scope, time window defaults, data source, and coverage caveats well. It never says which statistics are returned (median, mean, percentiles, sample counts) or the shape of the result, which is the one thing an agent would still have to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each parameter already carries detailed semantics (TERYT digit-length rules, date overrides, location expansion). The description reinforces only the period default and the period="all" option, adding little the schema does not already say, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and verb-phrase: price per m² statistics for residential apartments, scoped by location. It explicitly rules out other property types and routes them to search_transactions. It does not, however, distinguish itself from the two closest siblings, get_price_distribution and get_price_spread, which an agent could easily confuse with 'statistics'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Names one alternative explicitly ('for other property types use search_transactions') and gives a clear condition for choosing it. It also explains the default window and the period="all" option. The gap is that no guidance is given on when to prefer this tool over get_price_distribution or get_price_spread, the siblings with the most semantic overlap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
EXPERIMENTAL (beta): may change or be withdrawn; no critical workflows on it. Gross rental yield for a Polish city or county: annualized median asking rent (PLN/m²/month × 12) divided by the median secondary-market apartment transaction price per m² (RCN). Top-line only (excludes vacancy, management, tax, maintenance), indicative, not investment advice. Different sources, so an approximation; not comparable across cities with different as_of dates. Both sides need at least 5 samples or the result is suppressed. Coverage: counties (miasta na prawach powiatu) plus Warszawa's 18 districts, only cities with asking-rent data. A gmina name resolves to its county (shown in the answer); a name shared by gminas in several counties returns candidates. Aggregates exclude fractional shares and non-market deeds.
| Name | Required | Description | Default |
|---|---|---|---|
| teryt | No | TERYT: 4 digits = county (1465 = Warszawa); 6 digits = a Warszawa district (146510 = Śródmieście); other longer codes truncate to the county. Wins over location. | |
| location | No | County-level city name (a miasto na prawach powiatu or a catalog entry, e.g. 'Warszawa', 'Gdańsk'); a Warszawa district ('Mokotów') narrows to it, 'Kraków-Podgórze' resolves to its parent county; an osiedle 404s - use teryt. This OR teryt. | |
| areaBucket | No | Apartment area range in m², restricting both sides (all = whole stock, default). Buckets are not additive. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false and a beta title, so the safety profile is covered. The description goes further by disclosing the suppression rule (min 5 samples on both sides), the approximation caveat from mismatched sources, the top-line exclusions (vacancy, management, tax, maintenance), and that aggregates exclude fractional shares and non-market deeds — solid extra context, though the response shape is only vaguely gestured at ('shown in the answer').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The beta warning is correctly front-loaded, then the definition, then caveats and coverage rules. Almost every sentence carries operational information, but it reads as a dense paragraph without breaks, and the final sentence about fractional shares/non-market deeds is a niche detail buried at the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 carry the interpretive load, and it mostly does: it names the metric components, unit basis, caveats, and that the resolved county is echoed back. It stops short of describing the actual response fields (as_of dates, sample counts, yield units) that an agent would need to consume the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 real meaning about resolution behavior beyond the schema: a gmina name resolves to its county, ambiguous names shared across counties return a candidate list rather than failing, and the area bucket restricts both sides of the ratio. It still doesn't explain how areaBucket interacts with suppression or which parameters win in conflicts beyond what the schema already says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific named metric (gross rental yield) for a specific scope (Polish city or county) and spells out the exact formula — annualized median asking rent divided by median RCN transaction price per m². This is immediately distinguishable from siblings like get_price_statistics, get_market_overview, or get_price_distribution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It sets clear boundaries on when the output is meaningful: experimental/beta status, indicative not investment advice, not comparable across cities with different as_of dates, suppression under 5 samples, and coverage limited to counties plus Warszawa districts with asking-rent data. What's missing is explicit routing to siblings — notably list_rental_yield_locations, which an agent would need to find a valid location name, is never mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detail of one layer for one transaction taken from a search result (search_transactions): buildings, flood, heritage, landslide, subsurface, roads, surroundings, transit, permits, planning, farmland or nature. One layer per call - call again with another layer for more. For a parcel without a transaction use get_parcel_report. Cost: 4 tokens per call, refunded when the layer holds nothing (buildings: not refunded; planning: refunded unless covered).
| Name | Required | Description | Default |
|---|---|---|---|
| layer | Yes | Layer to read, each with its limit: buildings = footprint, storeys, estimated floor area per building; needs a search result with building data; age is an estimate from permits, never a registry date. flood = worst hazard category, type, plot share, scenarios; none mapped is never 'safe'. heritage = listed monument or protected zone, plot share; indicative, none detected is never 'not listed'. landslide = mapped slide area or at-risk zone, plot share; overlap is a mapped area, not a slide on the parcel; none is never 'safe'. subsurface = mining terrain and groundwater reservoir overlap; advisory, verify with the mining authority; a reservoir alone imposes no restriction. roads = distances to the nearest public road, any road and motorway, access indicator; geometric evidence, not legal access or easements. surroundings = distances to cemetery, landfill, sewage plant, industrial area, large plant, livestock farm, high-voltage lines; null = none in range, never a guarantee. transit = nearest stop by mode within 1-3 km from open GTFS data; none is never 'no transit'. permits = permits and works notifications since 2016 per case; outcome and pending cases not held; coverage covered, covered_no_data or not_covered; empty never confirms nothing was planned; around a point use get_permits_in_area. planning = general-plan (POG) zoning, not a local plan (MPZP); not_covered is never proof of no plan. farmland = agricultural eligibility area, not soil class; none is never proof the land is non-agricultural. nature = forest within 2 km and protected areas, building restriction; empty is never permission to build. | |
| transactionId | No | ||
| transaction_id | No | Transaction id (UUID) from a search result. Required (or transactionId). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, closed-world), so the description focuses on what annotations cannot express: a token cost of 4 per call with refund rules that differ per layer (buildings never refunded, planning refunded unless covered). That is genuinely useful pricing behavior, though it does not describe response shape or failure modes beyond the cost model.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then the one-layer-per-call rule, then the sibling pointer, then cost. Efficient, but the twelve-layer enumeration duplicates the enum and adds length without new information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description supplies enough to call correctly: which tool to use, that layers are fetched one at a time, and the cost/refund model. The per-layer return contents are covered by the enum description rather than the prose, which is an acceptable division of labor, though a one-line hint about what a layer result looks like would close the remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% and the enum's own description already documents each layer's contents and caveats in depth, so the description's listing of the twelve layer names largely repeats structured data. It does not explain the transactionId/transaction_id alias duplication or which id format source is canonical, leaving the one genuinely ambiguous parameter aspect to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Detail of one layer for one transaction taken from a search result'), enumerates the twelve layers, and explicitly names the sibling tool it is not (get_parcel_report for a parcel without a transaction). An agent can distinguish it from search_transactions and get_parcel_report without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit usage rule ('One layer per call - call again with another layer for more') and a clear exclusion with the correct alternative ('For a parcel without a transaction use get_parcel_report'). The routing condition is stated, not inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
EXPERIMENTAL (beta). Cities or counties a beta metric covers, with the sample behind each: valid location/teryt values for get_rental_yield, get_price_spread or get_flood_risk. Optional search (min 2 chars). Free.
| Name | Required | Description | Default |
|---|---|---|---|
| metric | Yes | Whose coverage to list: rental_yield (n = rent offers), price_spread (n = sale offers), flood_risk (n = flood-assessed transactions; counties). | |
| search | No | Name substring, diacritic-insensitive (e.g. 'gda' → Gdańsk). Omit for the full catalog. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the description's job is to add context — and it does: it flags the tool as EXPERIMENTAL (beta), declares it 'Free', and states the minimum search length. It does not say whether the beta catalog is stable or how large result sets are paginated/limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence plus a fragment, with the beta warning and the value proposition front-loaded. It reads as telegraphic rather than prose, but nothing is redundant and no sentence wastes space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two parameters and no output schema, the description should carry the return shape — 'with the sample behind each' conveys that a count accompanies each location, but the actual response fields (location name, teryt identifier, metric, n) are never described. The beta caveat and cost signal are present, leaving the tool mostly, but not fully, specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already documented, including the enum semantics and the minLength=2 constraint that the description merely repeats. The description's one genuine addition is the hint that flood_risk coverage is county-level while the others are city-level, which the schema buries in the enum text. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: listing cities/counties a given metric covers, along with the sample size behind each. It also ties the output to concrete consumers ('valid location/teryt values for get_rental_yield, get_price_spread or get_flood_risk'), which helps distinguish it from lookup siblings. It stops short of contrasting with list_locations, the most likely alternative for location enumeration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: by saying the results are the valid location/teryt values for the three get_* tools, it hints this is a validation/coverage pre-check before calling them, and 'Omit for the full catalog' clarifies search behavior. There is no explicit when-to-use/when-not, and no guidance on choosing this over list_locations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Beta: developers' investments with a current price list in an area, with partial coverage (only price lists matched to an address); at times briefly "temporarily unavailable". Asking prices from the price lists developers publish by law, NOT transaction prices. Returns a summary over ALL matched investments (investments, units on offer, median PLN/m², unit mix, price range; none below three investments) plus a cursor-paged list (name, brand, company, address, units, PLN/m² median and range, first and last seen). investmentId narrows the list only. ONE area: teryt (county, municipality or Warsaw district; codes from list_locations) or location (name; ambiguous → candidates), optional street; or lat + lng + radiusKm (0.1-5, default 2; nearest first, else most units first). Natural persons and partnerships are never listed (counted as unnamed). A short or empty list never proves nothing is being built (permits: get_permits_in_area; deeds: search_transactions with latitude, longitude, radiusKm). Cost: 10 API tokens per call, also when empty.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Circle centre latitude (WGS84, Poland); never guessed. Needs lng. | |
| lng | No | Circle centre longitude (WGS84, Poland); never guessed. Needs lat. | |
| limit | No | Investments per page, 1-50 (default 20). | |
| teryt | No | One TERYT code: 4 digits county, 6-7 digits municipality or Warsaw district. Wins over location. | |
| cursor | No | Cursor from the previous answer, unchanged; same area and investmentId. | |
| street | No | Narrows teryt/location to this street. | |
| location | No | City, county, municipality or district name. This OR teryt. | |
| radiusKm | No | Radius in km, 0.1-5 (default 2); with lat and lng. | |
| investmentId | No | investment_id from an earlier answer; narrows the list, not the summary. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered; the description adds substantial context beyond that: beta status, partial address-matching coverage, occasional 'temporarily unavailable' responses, legal asking prices rather than transaction prices, suppression of natural persons and of areas with fewer than three investments, and a 10-token cost. The only real gap is pagination behavior beyond the cursor mention.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the beta caveat and the asking-price disclaimer, then area selection, then return shape and alternatives. It is dense and reads as a single wall of text, but nearly every clause carries decision-relevant information; minor trimming of the parenthetical enumerations would help.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter, zero-required, no-output-schema tool, the description covers the return shape explicitly (summary aggregates plus cursor-paged per-investment fields), the area-selection constraint, pagination via cursor, and the pitfalls of interpreting empty results. 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.
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 genuine meaning: investmentId narrows the list only and not the summary, cursor must reuse the same area and investmentId, teryt wins over location, and radiusKm defaults to 2 with nearest-first ordering. It clarifies cross-parameter interactions the schema documents only field-by-field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (list developers' investments with current price lists in an area) plus the scope qualifier 'Beta' and the coverage caveat. It explicitly contrasts with siblings — permits via get_permits_in_area, deeds via search_transactions, codes via list_locations — so an agent can distinguish it 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete when-to-use routing ('A short or empty list never proves nothing is being built') and names the alternative tool for each missing-signal case. Also specifies the exactly-one-area rule (teryt/location or lat+lng) and warns about cost per call including empty results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a place name to TERYT codes, or browse the TERYT hierarchy - the first step before search_transactions (pass the returned code as teryt=).
search (a name): looks it up across all levels (voivodeship, county, municipality, precinct); each match carries its TERYT code, parent unit and exact follow-up calls; exact and prefix matches come first under 'Best matches'. Rows flagged rcn_district also accept the name in search_transactions(location=) and compare_locations; RCN district names with no TERYT code are listed separately. RCN district matches show their transaction count and date range, with a warning when the label covers only part of a gmina.
parent (a code): browse children (none = the 16 voivodeships); parent wins when both are given. Returns administrative units, never streets: for parcels on a street pass the name to list_parcels_in_area as street=. Prefer teryt where a name is ambiguous ('Wałcz' is both a county and a municipality).
| Name | Required | Description | Default |
|---|---|---|---|
| parent | No | TERYT parent code: 2-digit (voivodeship → counties), 4-digit (county → municipalities), 6-digit (municipality → precincts). Omit for all voivodeships. | |
| search | No | Place name, case- and diacritics-insensitive partial match (e.g. 'wejher' for Wejherowo); returns TERYT codes and any RCN district names. Ignored when parent is set. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, so the safety profile is covered; the description goes further by disclosing result shape (each match carries TERYT code, parent unit, follow-up calls), match ordering ('Best matches'), and the rcn_district special case with its transaction count, date range, and partial-gmina warning. That is behavior the agent could not infer from structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the one-line purpose, then two labeled mode bullets, then cross-cutting caveats — a structure that matches how an agent scans. The RCN-district sentences are dense and slightly over-packed, but each carries a distinct fact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description compensates fully by describing what each mode returns, how matches are ordered, and what follow-up calls the codes enable. For a two-parameter lookup tool this leaves no material gap an agent would need to guess at.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline would be 3; the description adds genuine meaning by explaining that search spans all hierarchy levels at once and that parent with no value yields all 16 voivodeships. Some of it overlaps the schema (it already says search is 'Ignored when parent is set'), hence not a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Resolve a place name to TERYT codes, or browse the TERYT hierarchy') and immediately positions it relative to siblings by naming search_transactions as the downstream consumer. It also explicitly disclaims a wrong interpretation ('Returns administrative units, never streets'), which no sibling name alone would convey.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit mode selection ('search (a name)' vs 'parent (a code)'), a precedence rule ('parent wins when both are given'), and a routing alternative for a near-miss task ('for parcels on a street pass the name to list_parcels_in_area as street='). It even advises preferring teryt over ambiguous names with a concrete example ('Wałcz').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List cadastral parcels in an area - the land plots themselves, NOT transactions (for deeds and prices use search_transactions with latitude/longitude or polygon). For an id prefix use resolve_parcel(prefix); for a coordinate or 'locality + number' use resolve_parcel (a street address goes here, via street= and buildingNumber=); for everything about one parcel use get_parcel_report.
Name the area (at least one): teryt (codes from list_locations); location (county, city or gmina NAME; a shared name is an error listing the candidates, never a guess); bbox; lat + lng + radiusKm (a circle; not with a bbox); polygon (alone).
Two answer shapes: the default LIGHT list (parcel id, district, centre point, held street address; 2 API tokens; cursor paging) and OUTLINES, with includeGeometry=true (needs a bbox) or a polygon (GeoJSON per parcel; 5 API tokens; no paging). A TRUNCATED outline answer is an arbitrary subset (not the first, nearest or largest): never report it as the area's parcel list, ask for a smaller area.
Light-list filters (not on outline calls) need a narrow scope - a bbox, a circle, a location name, or a teryt of at least 4 digits (county) - and do not name the area. minArea / maxArea (m²) = registered parcel surface.
street: whole-word, case- and accent-insensitive ('Górna' does not find 'Podgórna'; a fragment finds nothing). Pass the NOMINATIVE ('Karmelickiej' answers empty). An empty page is free and carries close-name suggestions - read them before concluding anything.
buildingNumber (needs street): exact ('12A' does not find '12a'); RCN often records compound numbers ('84/92'), so '84' will not find '84/92'. If empty, official address points are tried (still exact); if both miss, the page is empty (free) and lists the numbers held on the street. Most rural parcels have no street: outside towns use resolve_parcel (precinct name + parcel number); an empty street search in the countryside says nothing about the parcel. parcel_id is returned only to API-token / OAuth callers and paid or trial accounts.
Coverage gaps: (1) the cadastral data is near-complete but not live (fresh splits, merges or renumbering may be missing) for EVERY entrance: a short list or no truncation marker never means every parcel; each answer has a corpus_coverage block (null for bbox/circle/polygon). (2) bbox, circle and polygon miss the few parcels whose outline has an unreadable coordinate system; teryt/location list those with no location. A returned parcel is real; never read an empty or short answer as proof the land is not there. Refused: area over 500 km², radius over 12.6 km, polygon over 500 vertices.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Circle centre latitude (WGS84). Needs lng and radiusKm. | |
| lng | No | Circle centre longitude (WGS84). Needs lat and radiusKm. | |
| bbox | No | Bounding box "minLng,minLat,maxLng,maxLat" (WGS84), at most 500 km². Required for includeGeometry=true. | |
| limit | No | Max parcels. Light list: up to 1000, default 250. Outlines: up to 100, default 50. | |
| teryt | No | TERYT code prefix (2/4/6 digits or finer), comma-separated for several. Wins over location. | |
| cursor | No | Cursor from the previous light-list answer for the next page; pass it back unchanged. Not for outline calls. | |
| street | No | Street name in the NOMINATIVE (min 4 letters or digits). Light list, narrow scope (teryt of at least 4 digits). | |
| maxArea | No | Maximum parcel surface in m². Same rules as minArea. | |
| minArea | No | Minimum parcel surface in m². Light list, narrow scope. | |
| polygon | No | GeoJSON Polygon: [longitude, latitude] pairs, first and last point identical, max 500 vertices. Always returns outlines. Pass it instead of the other area parameters. | |
| location | No | County, city, gmina or district name, resolved to its TERYT code ('Mokotów' = that Warszawa district; 'Kraków-Podgórze' = its parent county; a gmina name answers at municipality level). | |
| radiusKm | No | Circle radius in km (max 12.6, the radius covering 500 km²). Needs lat and lng. | |
| buildingNumber | No | Building number, exact; needs street. If nothing is found, drop the number and read the numbers off the street's rows. | |
| includeGeometry | No | Full outlines instead of the light row (5 tokens, not 2). Requires a bbox; a polygon returns outlines anyway. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes far beyond the readOnly/destructive annotations: it quantifies cost per answer shape (2 vs 5 API tokens), discloses cursor paging for light lists, warns that a TRUNCATED outline is an arbitrary subset that must not be reported as an area list, documents a corpus_coverage block, and names hard refusals (500 km², 12.6 km radius, 500 vertices). It even explains that empty street pages are free and carry close-name suggestions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then area naming, then answer shapes, then filters, then caveats – a logical order for a 14-parameter tool. It is long and dense, with some overlap (resolve_parcel routing appears twice; the 'short list never means every parcel' caution is restated), which keeps it short of a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-parameter, two-mode query tool with no output schema, it covers entry modes, mutual exclusions, paging, cost, truncation, coverage gaps and refusals – everything an agent needs to avoid a wrong answer. No output schema is needed because return shapes ('parcel id, district, centre point, held street address' vs GeoJSON outlines) are described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds matching semantics the schema omits: street must be NOMINATIVE and whole-word ('Górna' does not find 'Podgórna'; fragment finds nothing), buildingNumber is exact and RCN compound numbers like '84/92' break prefix matching. It clarifies minArea/maxArea apply to registered surface and that light-list filters are rejected on outline calls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening states a specific verb and resource ('List cadastral parcels in an area') and immediately disambiguates against the nearest siblings: 'the land plots themselves, NOT transactions (for deeds and prices use search_transactions)'. A routing paragraph then assigns id prefixes, coordinates, addresses and single-parcel lookups to resolve_parcel and get_parcel_report, so the tool's scope is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use rules for each entry path: 'teryt (codes from list_locations)', 'location (county, city or gmina NAME; a shared name is an error... never a guess)', 'lat + lng + radiusKm (a circle; not with a bbox)', 'polygon (alone)'. It also states when filters are legal ('need a narrow scope... and do not name the area') and when the tool is pointless (rural parcels without streets should use resolve_parcel).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a land parcel to its cadastral identity using exactly ONE of:
parcelId: a full cadastral id ('142907_2.0014.342/5' or the '-' form) or internal UUID.
q: a full id, a UUID, or 'locality name + parcel number' (e.g. 'Sabnie 342/5'): the name is a gmina or cadastral precinct (obręb), matched exactly, case-insensitively; a gmina name plus a number also works for a gmina made of several precincts (e.g. 'Ełk 461/3'). An ambiguous name returns candidates, not a guess. NOT a street address: for that use list_parcels_in_area(street=, buildingNumber=).
lat & lng: a WGS84 point inside the parcel (a road parcel is flagged: the point probably fell on the street).
prefix: a cadastral id PREFIX (min 3 chars, e.g. '146518_8.01'), autocomplete only; limit (1-10, default 10) goes with it. Never by area: for parcels in a place or shape use list_parcels_in_area. Returns matching parcels with district, area and coordinates; 'truncated' when capped. not_covered: for a FULL id, we could not confirm the parcel live; in the DISCOVERY modes (name + number, coordinate) only "not among the parcels we hold" (near-complete, not live) - a fresh change or odd spelling is likelier than a missing parcel, so never report "no such parcel". not_computed = lookup did not finish, also not a finding. corpus_coverage says how much of the register was searched. Then feed the id to search_transactions(parcelId) for its sale history. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Full cadastral id, UUID, or 'locality name + parcel number' (e.g. 'Sabnie 342/5'); not a street address. | |
| lat | No | Latitude WGS84; pair with lng. | |
| lng | No | Longitude WGS84; pair with lat. | |
| limit | No | Max results (1-10, default 10); only with prefix. | |
| prefix | No | Cadastral id prefix (min 3 chars), e.g. '146518_8.01'; not combined with the other modes. | |
| parcelId | No | Full cadastral id (slash or dash form) or internal UUID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the read-only/open-world safety profile; the description adds substantive behavior beyond them: ambiguity yields candidates instead of a guess, road parcels are flagged, 'truncated' marks capped results, and the critical caveat that not_covered/not_computed are not evidence of a missing parcel. It also states ambiguity handling and cost ('Free'). This is exactly the kind of context annotations cannot carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The mode list is front-loaded and scannable, and the alternatives are placed inline where they matter. It loses a point for density: the not_covered/not_computed paragraph packs several nested caveats into one long run-on, and a few details (limit default, supported id forms) duplicate the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 explains what comes back (parcels with district, area, coordinates), introduces the 'truncated' flag and the not_covered/not_computed/corpus_coverage status semantics. For a six-parameter, multi-mode lookup tool this leaves nothing an agent needs missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 goes further: exact case-insensitive name matching, gmina vs cadastral precinct (obręb) acceptance, multi-precinct gmina names, WGS84 point-in-parcel semantics, prefix as autocomplete-only with min 3 chars. The remaining gap is that the mutual exclusivity rules are stated per-bullet rather than as one crisp guard, and limit's default is repeated from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('Resolve a land parcel to its cadastral identity') and then enumerates the four mutually exclusive input modes. It explicitly distinguishes itself from siblings list_parcels_in_area and search_transactions, so an agent can route without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Every mode carries a 'use this when' clause, and two negative cases are named with the correct alternative ('NOT a street address: for that use list_parcels_in_area'; 'Never by area: for parcels in a place or shape use list_parcels_in_area'). The trailing instruction to chain into search_transactions(parcelId) gives an explicit next step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find individual Polish real-estate transactions from the national RCN registry (8M+ notarial deeds, not asking prices) by place, property type, price, area, date or street. Returns address, date, price, area, price/m² and property type. Resolve the place first: list_locations(search=...), then pass its TERYT code as teryt= (exact match). Use location= only for a name that result flags as an RCN district (rcn_district) - other names silently return zero rows. Neighborhoods (osiedla) are not TERYT districts: pass latitude + longitude (+ radiusKm, default 2) instead of a place. Radius 0.3-0.5 km for a street, 0.5-1 km for a neighborhood, 2-5 km for a city area; the area is a bounding box, so corners extend beyond radiusKm. Take coordinates from the user, never invent them. A point excludes location, teryt, street, buildingNumber and parcelId, and is sorted by date only (pages 1-10). For an exact boundary pass polygon instead of a place or a point: rows only (no summary), newest first, pages 1-20, costs 5 API tokens. location (as district) and street narrow it; teryt, parcelId, buildingNumber, summaryOnly, groupBy, flood/heritage/landslide filters, sort and order are refused. For the land plots inside a shape (not deeds) pass the same polygon to list_parcels_in_area. Data note: ~1.7% of records have no transaction_date. Permalink: https://cenogram.pl/ceny-transakcyjne?src=mcphttp#v=1&lat=&lng=&z=16&tx= (use row id and coordinates A,B = lat,lng; omit &tx= for area only). Inline [...] notes flag computed values (summed or converted parcel area, inferred property type) and approximated streets; all else is as recorded in the deed.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number; a point serves pages 1-10, a polygon 1-20. | |
| sort | No | Sort by field, default date; a point is sorted by date only, a polygon takes no sort. | |
| 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. | |
| limit | No | Number of results. | |
| order | No | Sort order, default desc; a polygon takes no order. | |
| rooms | No | Rooms (izby), residential units only; multi-select ('8plus' = 8 or more). Rows with no count drop out unless 'unknown' is listed. | |
| teryt | No | TERYT code(s), comma-separated, max 10: 2-digit (voivodeship), 4 (county), 6 (municipality) or a precinct code (e.g. '321705_2.0054'). | |
| dateTo | No | End date (YYYY-MM-DD) | |
| format | No | Row detail; compact by default, full = every recorded field. | |
| street | No | Street name (partial match). Give the NOMINATIVE ('Karmelickiej' misses 'Karmelicka'); with buildingNumber, case and diacritics are ignored. | |
| groupBy | No | Per-year series (median price/m², sample size, deed count; up to 20 years, default last 10) instead of rows. Same filters; one summary call. | |
| landUse | No | Land-use category, multi-select, case-sensitive (gruntyZabudowaneIZurbanizowane = built-up, gruntyRolne = agricultural, gruntyLesne = forest, terenyKomunikacyjne = transport); 'unknown' = none recorded (NULL), not 'no use'. | |
| maxArea | No | Maximum area in m² | |
| minArea | No | Minimum area in m² | |
| polygon | No | GeoJSON Polygon: [longitude, latitude] pairs, first and last point identical, max 500 vertices total. Replaces the point; of the place filters only location and street apply. | |
| dateFrom | No | Start date (YYYY-MM-DD) | |
| latitude | No | Latitude of the search point; pair with longitude. Replaces the place filters. | |
| location | No | City (e.g. 'Warszawa') or RCN district (e.g. 'Mokotów', 'Kraków-Podgórze'); 'Warszawa', 'Kraków', 'Łódź' expand to all sub-districts. | |
| maxPrice | No | Maximum price in PLN | |
| minPrice | No | Minimum price in PLN | |
| parcelId | No | Exact parcel ID, copied from a search result's parcel_id field (e.g. '146518_8.0108.27'). | |
| radiusKm | No | Search radius in km around the point (default 2). | |
| floodRisk | No | Flood-hazard zone, multi-select: high ~1-in-10-year, medium ~1-in-100, low ~1-in-500. Mapped zones only; absence of a zone is never 'safe'. | |
| longitude | No | Longitude of the search point; pair with latitude. | |
| marketType | No | primary (developer) or secondary (resale); the ~55% of records with no market type drop out when this is set. | |
| summaryOnly | No | Aggregates only (total, median price/m² with sample size, period), no rows; cheapest call. limit/sort/page/format ignored. | |
| buildingType | No | Building type (PKOB); 'unknown' = none recorded (NULL, ~39% of buildings), any other value excludes such rows. | |
| propertyType | No | Property type: building = no land; house with plot = developed_land | |
| unitFunction | No | Unit function; 'unknown' = none recorded (NULL), any other value excludes such rows. Garages only via 'garage'. | |
| landslideRisk | No | Landslide hazard, multi-select: landslide = mapped landslide area; threatened = area threatened by mass movements. Mapped areas only; absence of a zone is never 'safe'. | |
| ownershipType | No | Legal-right type (rodzaj prawa), multi-select; perpetual_usufruct = użytkowanie wieczyste; 'unknown' = none recorded. | |
| buildingNumber | No | Building number (e.g. '12A'). Needs location or street; with street, both on one address. An empty page may list nearby numbers. | |
| heritageStatus | No | Heritage listing, multi-select: listed = protected monument on the land; zone = protected urban layout or monument surroundings. Detected listings only; absence of a detection is never 'not listed'. | |
| buildingStoreys | No | Above-ground storeys, multi-select: integers, 'Nplus' ('3plus' = 3+), 'unknown' (no count). Single-building deeds only, so 'unknown' also covers multi-building deeds. Not the unit floor; rows with no count drop out unless 'unknown' is listed. | |
| mpzpDesignation | No | MPZP zoning designation, exact token match; comma-separated = OR (e.g. 'MN,MW'). 'unknown' = none recorded (NULL), distinct from the code 'brakMPZPLubWZ' (no plan/WZ). Common codes: budownictwoMieszkanioweJednorodzinne, brakMPZPLubWZ, terenRolniczy, innyNiewymieniony, terenZabudowyUslugowej, terenDrogPublicznych, budownictwoMieszkanioweWielorodzinne, las, and short plan symbols (MN, MW, U, KD). An unrecognised value is still sent, with a warning listing every known code. | |
| 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. | |
| maxFootprintArea | No | Maximum building footprint in m²; same rules as minFootprintArea. | |
| minFootprintArea | No | Minimum building footprint in m², summed over the transaction's buildings; measured rows only (absence = 'not measured', not 'no building'). Not usable area. | |
| excludeFractionalShares | No | true = clean land prices: drops fractional ownership shares, whose price reflects the whole deed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/non-destructive/closed-world, and the description adds substantial context beyond them: per-mode paging caps (10 for a point, 20 for a polygon), the 5 API-token cost of polygon mode, the exact list of filters silently refused in polygon mode, the exclusion side-effects of a point search, a data-quality caveat (~1.7% missing transaction_date), and the meaning of inline [...] computed-value markers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with what it does and what it returns, then organized by search mode (place, point, polygon), which mirrors the decision the agent must make. It is dense and long, and some mode restrictions restated in the prose duplicate parameter-level schema text, but nearly every sentence carries operational value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 39-parameter tool with no output schema, the description still conveys the row shape (address, date, price, area, price/m², type), how summary and groupBy differ from rows, and how to construct a permalink from row id plus coordinates. An agent has enough to select a mode, build the call and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 earns above that by explaining cross-parameter interactions the schema only states piecemeal — a point excludes location/teryt/street/buildingNumber and is sorted by date only, and a polygon refuses sort, order, summaryOnly and the hazard/heritage filters. It does not re-explain individual filter semantics, which is appropriate since the schema already handles those.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence names a specific verb and resource ('Find individual Polish real-estate transactions from the national RCN registry'), quantifies scope (8M+ notarial deeds, not asking prices) and lists the returned fields. It immediately differentiates itself from data siblings by stressing actual deeds rather than listings, and later names list_parcels_in_area for the adjacent-but-different land-plot use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit routing rules: resolve the place via list_locations first, use location= only for names flagged as rcn_district, use lat/lng for neighborhoods, and polygon for exact boundaries, with concrete radius guidance per scenario. The gap is that overlapping siblings like get_transaction_layer, get_price_statistics and compare_locations are never addressed, so the agent must infer when this search is preferable to those aggregate tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
list_coveragelist_flood_risk_locationslist_price_spread_locationslist_rental_yield_locationsresolve_parcel2 fields changedInput schema / properties / limitAdded value: +{
+ "description": "Max results (1-10, default 10); only with prefix.",
+ "maximum": 10,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / prefixAdded value: +{
+ "description": "Cadastral id prefix (min 3 chars), e.g. '146518_8.01'; not combined with the other modes.",
+ "maxLength": 200,
+ "minLength": 3,
+ "type": "string"
+}search_by_areasearch_by_polygonsearch_parcelssearch_transactions9 fields changedInput schema / properties / latitudeAdded value: +{
+ "description": "Latitude of the search point; pair with longitude. Replaces the place filters.",
+ "maximum": 55,
+ "minimum": 49,
+ "type": "number"
+}Input schema / properties / longitudeAdded value: +{
+ "description": "Longitude of the search point; pair with latitude.",
+ "maximum": 25,
+ "minimum": 14,
+ "type": "number"
+}Input schema / properties / order / defaultRemoved value: -"desc"Input schema / properties / order / descriptionPrevious value: -"Sort order."New value: +"Sort order, default desc; a polygon takes no order."Input schema / properties / page / descriptionPrevious value: -"Page number."New value: +"Page number; a point serves pages 1-10, a polygon 1-20."Input schema / properties / polygonAdded value: +{
+ "additionalProperties": false,
+ "description": "GeoJSON Polygon: [longitude, latitude] pairs, first and last point identical, max 500 vertices total. Replaces the point; of the place filters only location and street apply.",
+ "properties": {
+ "coordinates": {
+ "items": {
+ "items": {
+ "items": {
+ "type": "number"
+ },
+ "type": "array"
+ },
+ "type": "array"
+ },
+ "minItems": 1,
+ "type": "array"
+ },
+ "type": {
+ "const": "Polygon",
+ "type": "string"
+ }
+ },
+ "required": [
+ "type",
+ "coordinates"
+ ],
+ "type": "object"
+}Input schema / properties / radiusKmAdded value: +{
+ "description": "Search radius in km around the point (default 2).",
+ "maximum": 50,
+ "minimum": 0.1,
+ "type": "number"
+}Input schema / properties / sort / defaultRemoved value: -"date"Input schema / properties / sort / descriptionPrevious value: -"Sort by field."New value: +"Sort by field, default date; a point is sorted by date only, a polygon takes no sort."get_building_breakdownget_price_statistics1 field changedInput schema / properties / terytAdded value: +{
+ "description": "TERYT: 4 digits = county (1465 = Warszawa), 6 = Warszawa district (146505 = Mokotów). A gmina code is an error, unlike get_price_spread (narrows to county): pass the county. Wins over location.",
+ "type": "string"
+}get_transaction_farmlandget_transaction_floodget_transaction_heritageget_transaction_landslideget_transaction_layerget_transaction_natureget_transaction_permitsget_transaction_planningget_transaction_roadsget_transaction_subsurfaceget_transaction_surroundingsget_transaction_transitsearch_transactions2 fields changedInput schema / properties / buildingNumber / descriptionPrevious value: -"Building/house number (e.g. '30', '12A'). Requires location or street."New value: +"Building number (e.g. '12A'). Needs location or street; with street, both on one address. An empty page may list nearby numbers."Input schema / properties / street / descriptionPrevious value: -"Street name, matched anywhere inside the name. Give the NOMINATIVE with Polish diacritics - matching is literal ('Karmelickiej' does not find 'Karmelicka'); a miss looks exactly like 'no such transactions'."New value: +"Street name (partial match). Give the NOMINATIVE ('Karmelickiej' misses 'Karmelicka'); with buildingNumber, case and diacritics are ignored."search_transactions2 fields changedInput schema / properties / buildingNumber / descriptionPrevious value: -"Building number (e.g. '12A'). Needs location or street; with street, both on one address. An empty page may list nearby numbers."New value: +"Building/house number (e.g. '30', '12A'). Requires location or street."Input schema / properties / street / descriptionPrevious value: -"Street name (partial match). Give the NOMINATIVE ('Karmelickiej' misses 'Karmelicka'); with buildingNumber, case and diacritics are ignored."New value: +"Street name, matched anywhere inside the name. Give the NOMINATIVE with Polish diacritics - matching is literal ('Karmelickiej' does not find 'Karmelicka'); a miss looks exactly like 'no such transactions'."search_transactions2 fields changedInput schema / properties / buildingNumber / descriptionPrevious value: -"Building/house number (e.g. '30', '12A'). Requires location or street."New value: +"Building number (e.g. '12A'). Needs location or street; with street, both on one address. An empty page may list nearby numbers."Input schema / properties / street / descriptionPrevious value: -"Street name, matched anywhere inside the name. Give the NOMINATIVE with Polish diacritics - matching is literal ('Karmelickiej' does not find 'Karmelicka'); a miss looks exactly like 'no such transactions'."New value: +"Street name (partial match). Give the NOMINATIVE ('Karmelickiej' misses 'Karmelicka'); with buildingNumber, case and diacritics are ignored."list_developer_investmentscompare_locations9 fields changedInput schema / properties / buildingType / descriptionPrevious value: -"Building type (PKOB); 'unknown' = none recorded (NULL, ~39% of buildings), any other value excludes such rows."New value: +"Building type (PKOB); 'unknown' = none recorded (~39%)."Input schema / properties / floor / descriptionPrevious 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."New value: +"Unit floor, multi-select: integers ('0' = ground, negatives = basement), 'Nplus', 'unknown' (no floor). Not building storeys."Input schema / properties / includeDemographics / descriptionPrevious 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."New value: +"Add a GUS BDL block per district (county-level: density, wages, unemployment, median age, price-to-income); districts not resolving to a county are omitted."Input schema / properties / marketType / descriptionPrevious value: -"primary (developer) or secondary (resale); the ~55% of records with no market type drop out when this is set."New value: +"primary (developer) or secondary (resale); untyped records (~55%) drop out."Input schema / properties / mpzpDesignation / descriptionPrevious value: -"MPZP zoning designation, exact token match; comma-separated = OR; 'unknown' = none recorded. Same codes as search_transactions mpzpDesignation."New value: +"MPZP zoning designation, exact token match; comma-separated = OR (e.g. 'MN,MW'); 'unknown' = none recorded. An unrecognised value triggers a warning listing all codes."Input schema / properties / ownershipType / descriptionPrevious value: -"Legal-right type (rodzaj prawa), multi-select; perpetual_usufruct = użytkowanie wieczyste; 'unknown' = none recorded."New value: +"Legal right (rodzaj prawa), multi-select; 'unknown' = none recorded."Input schema / properties / rooms / descriptionPrevious value: -"Rooms (izby), residential units only; multi-select ('8plus' = 8 or more). Rows with no count drop out unless 'unknown' is listed."New value: +"Rooms (izby), residential units only, multi-select ('8plus' = 8+); 'unknown' = no count."Input schema / properties / transactionType / descriptionPrevious 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."New value: +"Multi-select. For market analysis ALWAYS set it to drop non-market deeds (subsidized, foreclosure, public_purpose); untyped rows drop out unless 'unknown'."Input schema / properties / unitFunction / descriptionPrevious value: -"Unit function; 'unknown' = none recorded (NULL), any other value excludes such rows. Garages only via 'garage'."New value: +"Unit function; 'unknown' = none recorded. Garages only via 'garage'."estimate_land_value2 fields changedInput schema / properties / lat / descriptionPrevious value: -"Latitude of the plot (WGS84, Poland); pair with lng. Use this OR parcelId (area is then required)."New value: +"Plot latitude (WGS84); pair with lng. This OR parcelId (area then required)."Input schema / properties / lng / descriptionPrevious value: -"Longitude of the plot (WGS84, Poland); pair with lat. Use this OR parcelId (area is then required)."New value: +"Plot longitude (WGS84); pair with lat. This OR parcelId (area then required)."estimate_value2 fields changedInput schema / properties / lat / descriptionPrevious value: -"Latitude of the apartment (WGS84, Poland); pair with lng. Use this OR parcelId."New value: +"Apartment latitude (WGS84); pair with lng. This OR parcelId."Input schema / properties / lng / descriptionPrevious value: -"Longitude of the apartment (WGS84, Poland); pair with lat. Use this OR parcelId."New value: +"Apartment longitude (WGS84); pair with lat. This OR parcelId."get_building_breakdown1 field changedInput schema / properties / transaction_id / descriptionPrevious value: -"Transaction id (UUID) from a search result that carries building data. This or transactionId is required."New value: +"Transaction id (UUID) from a search result that carries building data. Required (or transactionId)."get_flood_risk1 field changedInput schema / properties / location / descriptionPrevious value: -"City or county name (e.g. 'Warszawa', 'Gdańsk'). District and gmina names are accepted ('Kraków-Podgórze', 'Wieliczka') but coverage is county-level, so the answer is the parent county with a note. A gmina name shared by counties returns candidates. A town within a larger powiat or an osiedle may 404 - check the catalog or use teryt. This OR teryt."New value: +"City or county name (e.g. 'Warszawa', 'Gdańsk'). District and gmina names are accepted ('Kraków-Podgórze', 'Wieliczka'), answered at the parent county with a note; a gmina name shared by counties returns candidates. A town within a larger powiat or an osiedle may 404 - check the catalog or use teryt. This OR teryt."get_infrastructure_signals1 field changedInput schema / properties / teryt / descriptionPrevious value: -"TERYT code: 6 or 7 digits = one municipality (e.g. 146501), 4 digits = a county aggregate (e.g. 1465). Wins over location."New value: +"TERYT code (from list_locations): 6 or 7 digits = one municipality (e.g. 146501), 4 digits = a county aggregate (e.g. 1465). Wins over location."get_parcel_land_class1 field changedInput schema / properties / parcelId / descriptionPrevious value: -"Full cadastral id ('142907_2.0014.342/5' or the '-' form) or internal UUID."New value: +"Cadastral id ('142907_2.0014.342/5' or '-' form) or internal UUID."get_parcel_mpzp1 field changedInput schema / properties / parcelId / descriptionPrevious value: -"Full cadastral id ('142907_2.0014.342/5' or the '-' form) or internal UUID."New value: +"Cadastral id ('142907_2.0014.342/5' or '-' form) or internal UUID."get_parcel_report1 field changedInput schema / properties / parcelId / descriptionPrevious value: -"Full cadastral id ('142907_2.0014.342/5' or the '-' form) or internal UUID."New value: +"Cadastral id ('142907_2.0014.342/5' or '-' form) or internal UUID."get_permits_in_area4 fields changedInput schema / properties / cursor / descriptionPrevious value: -"Cursor from the previous answer, for the next page; pass it back unchanged with the same filters. Not with aggregateOnly."New value: +"Cursor from the previous answer (next page); pass it back unchanged with the same filters. Not with aggregateOnly."Input schema / properties / lat / descriptionPrevious value: -"Circle centre latitude (WGS84, Poland), from resolve_parcel / list_parcels_in_area or the user; never guessed."New value: +"Circle centre latitude (WGS84, Poland); never guessed."Input schema / properties / limit / descriptionPrevious value: -"Cases in the list, 1–200 (default 50). The aggregate counts all matched cases."New value: +"Cases in the list, 1–200 (default 50)."Input schema / properties / lng / descriptionPrevious value: -"Circle centre longitude (WGS84, Poland), from resolve_parcel / list_parcels_in_area or the user; never guessed."New value: +"Circle centre longitude (WGS84, Poland); never guessed."get_price_spread2 fields changedInput schema / properties / areaBucket / descriptionPrevious value: -"Apartment area range in m² (all = whole stock, default). Buckets are not additive."New value: +"Apartment area range in m², restricting both sides (all = whole stock, default). Buckets are not additive."Input schema / properties / location / descriptionPrevious value: -"County-level city name (a miasto na prawach powiatu or a catalog entry, e.g. 'Warszawa', 'Gdańsk'); a Warszawa district ('Mokotów') narrows to it, 'Kraków-Podgórze' resolves to its parent county. A gmina name resolves to its county (candidates if shared by gminas in several counties); an osiedle 404s - use teryt. This OR teryt."New value: +"County-level city name (a miasto na prawach powiatu or a catalog entry, e.g. 'Warszawa', 'Gdańsk'); a Warszawa district ('Mokotów') narrows to it, 'Kraków-Podgórze' resolves to its parent county; an osiedle 404s - use teryt. This OR teryt."get_rental_yield2 fields changedInput schema / properties / areaBucket / descriptionPrevious value: -"Apartment area range in m² (all = whole stock, default). Buckets are not additive."New value: +"Apartment area range in m², restricting both sides (all = whole stock, default). Buckets are not additive."Input schema / properties / location / descriptionPrevious value: -"County-level city name (a miasto na prawach powiatu or a catalog entry, e.g. 'Warszawa', 'Gdańsk'); a Warszawa district ('Mokotów') narrows to it, 'Kraków-Podgórze' resolves to its parent county. A gmina name resolves to its county (candidates if shared by gminas in several counties); an osiedle 404s - use teryt. This OR teryt."New value: +"County-level city name (a miasto na prawach powiatu or a catalog entry, e.g. 'Warszawa', 'Gdańsk'); a Warszawa district ('Mokotów') narrows to it, 'Kraków-Podgórze' resolves to its parent county; an osiedle 404s - use teryt. This OR teryt."get_transaction_farmland1 field changedInput schema / properties / transaction_id / descriptionPrevious value: -"Transaction id (UUID) from a search result. This or transactionId is required."New value: +"Transaction id (UUID) from a search result. Required (or transactionId)."get_transaction_flood1 field changedInput schema / properties / transaction_id / descriptionPrevious value: -"Transaction id (UUID) from a search result. This or transactionId is required."New value: +"Transaction id (UUID) from a search result. Required (or transactionId)."get_transaction_heritage1 field changedInput schema / properties / transaction_id / descriptionPrevious value: -"Transaction id (UUID) from a search result. This or transactionId is required."New value: +"Transaction id (UUID) from a search result. Required (or transactionId)."get_transaction_landslide1 field changedInput schema / properties / transaction_id / descriptionPrevious value: -"Transaction id (UUID) from a search result. This or transactionId is required."New value: +"Transaction id (UUID) from a search result. Required (or transactionId)."get_transaction_nature1 field changedInput schema / properties / transaction_id / descriptionPrevious value: -"Transaction id (UUID) from a search result. This or transactionId is required."New value: +"Transaction id (UUID) from a search result. Required (or transactionId)."get_transaction_permits1 field changedInput schema / properties / transaction_id / descriptionPrevious value: -"Transaction id (UUID) from a search result. This or transactionId is required."New value: +"Transaction id (UUID) from a search result. Required (or transactionId)."get_transaction_planning1 field changedInput schema / properties / transaction_id / descriptionPrevious value: -"Transaction id (UUID) from a search result. This or transactionId is required."New value: +"Transaction id (UUID) from a search result. Required (or transactionId)."get_transaction_roads1 field changedInput schema / properties / transaction_id / descriptionPrevious value: -"Transaction id (UUID) from a search result. This or transactionId is required."New value: +"Transaction id (UUID) from a search result. Required (or transactionId)."get_transaction_subsurface1 field changedInput schema / properties / transaction_id / descriptionPrevious value: -"Transaction id (UUID) from a search result. This or transactionId is required."New value: +"Transaction id (UUID) from a search result. Required (or transactionId)."get_transaction_surroundings1 field changedInput schema / properties / transaction_id / descriptionPrevious value: -"Transaction id (UUID) from a search result. This or transactionId is required."New value: +"Transaction id (UUID) from a search result. Required (or transactionId)."get_transaction_transit1 field changedInput schema / properties / transaction_id / descriptionPrevious value: -"Transaction id (UUID) from a search result. This or transactionId is required."New value: +"Transaction id (UUID) from a search result. Required (or transactionId)."list_flood_risk_locations1 field changedInput schema / properties / search / descriptionPrevious value: -"County name filter (diacritic-insensitive substring, min 2 chars), e.g. 'gda' → Gdańsk. Omit for the full catalog."New value: +"County name substring, diacritic-insensitive (e.g. 'gda' → Gdańsk). Omit for the full catalog."list_locations2 fields changedInput schema / properties / parent / descriptionPrevious value: -"TERYT parent code to browse children: 2-digit (voivodeship → counties), 4-digit (county → municipalities), 6-digit (municipality → precincts). Omit for all voivodeships."New value: +"TERYT parent code: 2-digit (voivodeship → counties), 4-digit (county → municipalities), 6-digit (municipality → precincts). Omit for all voivodeships."Input schema / properties / search / descriptionPrevious value: -"Place name, case- and diacritics-insensitive partial match (e.g. 'wejher' for Wejherowo). Returns TERYT codes plus, where applicable, RCN district names. Ignored when parent is set."New value: +"Place name, case- and diacritics-insensitive partial match (e.g. 'wejher' for Wejherowo); returns TERYT codes and any RCN district names. Ignored when parent is set."list_parcels_in_area6 fields changedInput schema / properties / buildingNumber / descriptionPrevious value: -"Building number, exact; needs street, same scope requirement. If nothing is found, drop the number and read the numbers off the street's rows."New value: +"Building number, exact; needs street. If nothing is found, drop the number and read the numbers off the street's rows."Input schema / properties / cursor / descriptionPrevious value: -"Opaque cursor from the previous light-list answer, for the next page; pass it back unchanged. Not available on outline calls."New value: +"Cursor from the previous light-list answer for the next page; pass it back unchanged. Not for outline calls."Input schema / properties / includeGeometry / descriptionPrevious value: -"Return full outlines instead of the light row (5 tokens instead of 2). Requires a bbox; with a polygon outlines come back anyway."New value: +"Full outlines instead of the light row (5 tokens, not 2). Requires a bbox; a polygon returns outlines anyway."Input schema / properties / maxArea / descriptionPrevious value: -"Maximum parcel surface in m². Same scope requirement as minArea."New value: +"Maximum parcel surface in m². Same rules as minArea."Input schema / properties / minArea / descriptionPrevious value: -"Minimum parcel surface in m². Needs a narrow scope; not with includeGeometry or a polygon."New value: +"Minimum parcel surface in m². Light list, narrow scope."Input schema / properties / street / descriptionPrevious value: -"Street name in the NOMINATIVE (min 4 letters or digits). Needs a bbox, a circle, a location name, or a teryt of at least 4 digits; not with includeGeometry or a polygon."New value: +"Street name in the NOMINATIVE (min 4 letters or digits). Light list, narrow scope (teryt of at least 4 digits)."list_price_spread_locations1 field changedInput schema / properties / search / descriptionPrevious value: -"City name filter (diacritic-insensitive substring, min 2 chars), e.g. 'gda' → Gdańsk. Omit for the full catalog."New value: +"City name substring, diacritic-insensitive (e.g. 'gda' → Gdańsk). Omit for the full catalog."list_rental_yield_locations1 field changedInput schema / properties / search / descriptionPrevious value: -"City name filter (diacritic-insensitive substring, min 2 chars), e.g. 'gda' → Gdańsk. Omit for the full catalog."New value: +"City name substring, diacritic-insensitive (e.g. 'gda' → Gdańsk). Omit for the full catalog."resolve_parcel4 fields changedInput schema / properties / lat / descriptionPrevious value: -"Latitude WGS84; pair with lng. Exclusive with q and parcelId."New value: +"Latitude WGS84; pair with lng."Input schema / properties / lng / descriptionPrevious value: -"Longitude WGS84; pair with lat. Exclusive with q and parcelId."New value: +"Longitude WGS84; pair with lat."Input schema / properties / parcelId / descriptionPrevious value: -"Full cadastral id (slash or dash form) or internal UUID. Exclusive with q and lat/lng."New value: +"Full cadastral id (slash or dash form) or internal UUID."Input schema / properties / q / descriptionPrevious value: -"Full cadastral id, UUID, or 'locality name + parcel number' (e.g. 'Sabnie 342/5'); not a street address. Exclusive with parcelId and lat/lng."New value: +"Full cadastral id, UUID, or 'locality name + parcel number' (e.g. 'Sabnie 342/5'); not a street address."search_by_area18 fields changedInput schema / properties / buildingStoreys / descriptionPrevious value: -"Above-ground storeys, multi-select: integers, 'Nplus' ('3plus' = 3+), 'unknown' (no count). Single-building deeds only, so 'unknown' also covers multi-building deeds. Not the unit floor; rows with no count drop out unless 'unknown' is listed."New value: +"Above-ground storeys, multi-select: integers, 'Nplus', 'unknown' (no count; also multi-building deeds). Not the unit floor."Input schema / properties / buildingType / descriptionPrevious value: -"Building type (PKOB); 'unknown' = none recorded (NULL, ~39% of buildings), any other value excludes such rows."New value: +"Building type (PKOB); 'unknown' = none recorded (~39%)."Input schema / properties / excludeFractionalShares / descriptionPrevious value: -"true = clean land prices: drops fractional ownership shares, whose price reflects the whole deed."New value: +"true = clean land prices: drops fractional ownership shares."Input schema / properties / floodRisk / descriptionPrevious value: -"Flood-hazard zone, multi-select: high ~1-in-10-year, medium ~1-in-100, low ~1-in-500. Mapped zones only; absence of a zone is never 'safe'."New value: +"Flood zone, multi-select: high ~1-in-10-year, medium ~1-in-100, low ~1-in-500. No zone is never 'safe'."Input schema / properties / floor / descriptionPrevious 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."New value: +"Unit floor, multi-select: integers ('0' = ground, negatives = basement), 'Nplus', 'unknown' (no floor). Not building storeys."Input schema / properties / groupBy / descriptionPrevious value: -"Return a per-year series (median price/m², sample size, deed count; up to 20 years, default last 10) instead of rows. Same filters; one summary call."New value: +"Per-year series (median price/m², sample size, deed count; up to 20 years, default last 10) instead of rows. Same filters; one summary call."Input schema / properties / heritageStatus / descriptionPrevious value: -"Heritage listing, multi-select: listed = protected monument on the land; zone = protected urban layout or monument surroundings. Detected listings only; absence of a detection is never 'not listed'."New value: +"Heritage, multi-select: listed = protected monument; zone = protected urban layout or monument surroundings. Undetected is never 'not listed'."Input schema / properties / landUse / descriptionPrevious value: -"Land-use category, multi-select, case-sensitive (gruntyZabudowaneIZurbanizowane = built-up, gruntyRolne = agricultural, gruntyLesne = forest, terenyKomunikacyjne = transport); 'unknown' = none recorded (NULL), not 'no use'."New value: +"Land use, multi-select, case-sensitive; in enum order: built-up, agricultural, forest, transport, other. 'unknown' = none recorded."Input schema / properties / landslideRisk / descriptionPrevious value: -"Landslide hazard, multi-select: landslide = mapped landslide area; threatened = area threatened by mass movements. Mapped areas only; absence of a zone is never 'safe'."New value: +"Landslide, multi-select: landslide = mapped slide area; threatened = threatened by mass movements. No zone is never 'safe'."Input schema / properties / marketType / descriptionPrevious value: -"primary (developer) or secondary (resale); the ~55% of records with no market type drop out when this is set."New value: +"primary (developer) or secondary (resale); untyped records (~55%) drop out."Input schema / properties / maxFootprintArea / descriptionPrevious value: -"Maximum building footprint in m²; same rules as minFootprintArea."New value: +"Max building footprint in m²; same rules as minFootprintArea."Input schema / properties / minFootprintArea / descriptionPrevious value: -"Minimum building footprint in m², summed over the transaction's buildings; measured rows only (absence = 'not measured', not 'no building'). Not usable area."New value: +"Min building footprint in m², summed over the deed's buildings; measured rows only."Input schema / properties / mpzpDesignation / descriptionPrevious value: -"MPZP zoning designation, exact token match; comma-separated = OR; 'unknown' = none recorded. Same codes as search_transactions mpzpDesignation."New value: +"MPZP zoning designation, exact token match; comma-separated = OR (e.g. 'MN,MW'); 'unknown' = none recorded. An unrecognised value triggers a warning listing all codes."Input schema / properties / ownershipType / descriptionPrevious value: -"Legal-right type (rodzaj prawa), multi-select; perpetual_usufruct = użytkowanie wieczyste; 'unknown' = none recorded."New value: +"Legal right (rodzaj prawa), multi-select; 'unknown' = none recorded."Input schema / properties / rooms / descriptionPrevious value: -"Rooms (izby), residential units only; multi-select ('8plus' = 8 or more). Rows with no count drop out unless 'unknown' is listed."New value: +"Rooms (izby), residential units only, multi-select ('8plus' = 8+); 'unknown' = no count."Input schema / properties / summaryOnly / descriptionPrevious value: -"Aggregate stats only (total, median price/m² with sample size, period), no rows. Costs only the summary call; limit/sort/page/format ignored."New value: +"Aggregates only (total, median price/m² with sample size, period), no rows; cheapest call. limit/sort/page/format ignored."Input schema / properties / transactionType / descriptionPrevious 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."New value: +"Multi-select. For market analysis ALWAYS set it to drop non-market deeds (subsidized, foreclosure, public_purpose); untyped rows drop out unless 'unknown'."Input schema / properties / unitFunction / descriptionPrevious value: -"Unit function; 'unknown' = none recorded (NULL), any other value excludes such rows. Garages only via 'garage'."New value: +"Unit function; 'unknown' = none recorded. Garages only via 'garage'."search_by_polygon13 fields changedInput schema / properties / buildingStoreys / descriptionPrevious value: -"Above-ground storeys, multi-select: integers, 'Nplus' ('3plus' = 3+), 'unknown' (no count). Single-building deeds only, so 'unknown' also covers multi-building deeds. Not the unit floor; rows with no count drop out unless 'unknown' is listed."New value: +"Above-ground storeys, multi-select: integers, 'Nplus', 'unknown' (no count; also multi-building deeds). Not the unit floor."Input schema / properties / buildingType / descriptionPrevious value: -"Building type (PKOB); 'unknown' = none recorded (NULL, ~39% of buildings), any other value excludes such rows."New value: +"Building type (PKOB); 'unknown' = none recorded (~39%)."Input schema / properties / excludeFractionalShares / descriptionPrevious value: -"true = clean land prices: drops fractional ownership shares, whose price reflects the whole deed."New value: +"true = clean land prices: drops fractional ownership shares."Input schema / properties / floor / descriptionPrevious 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."New value: +"Unit floor, multi-select: integers ('0' = ground, negatives = basement), 'Nplus', 'unknown' (no floor). Not building storeys."Input schema / properties / landUse / descriptionPrevious value: -"Land-use category, multi-select, case-sensitive (gruntyZabudowaneIZurbanizowane = built-up, gruntyRolne = agricultural, gruntyLesne = forest, terenyKomunikacyjne = transport); 'unknown' = none recorded (NULL), not 'no use'."New value: +"Land use, multi-select, case-sensitive; in enum order: built-up, agricultural, forest, transport, other. 'unknown' = none recorded."Input schema / properties / marketType / descriptionPrevious value: -"primary (developer) or secondary (resale); the ~55% of records with no market type drop out when this is set."New value: +"primary (developer) or secondary (resale); untyped records (~55%) drop out."Input schema / properties / maxFootprintArea / descriptionPrevious value: -"Maximum building footprint in m²; same rules as minFootprintArea."New value: +"Max building footprint in m²; same rules as minFootprintArea."Input schema / properties / minFootprintArea / descriptionPrevious value: -"Minimum building footprint in m², summed over the transaction's buildings; measured rows only (absence = 'not measured', not 'no building'). Not usable area."New value: +"Min building footprint in m², summed over the deed's buildings; measured rows only."Input schema / properties / mpzpDesignation / descriptionPrevious value: -"MPZP zoning designation, exact token match; comma-separated = OR; 'unknown' = none recorded. Same codes as search_transactions mpzpDesignation."New value: +"MPZP zoning designation, exact token match; comma-separated = OR (e.g. 'MN,MW'); 'unknown' = none recorded. An unrecognised value triggers a warning listing all codes."Input schema / properties / ownershipType / descriptionPrevious value: -"Legal-right type (rodzaj prawa), multi-select; perpetual_usufruct = użytkowanie wieczyste; 'unknown' = none recorded."New value: +"Legal right (rodzaj prawa), multi-select; 'unknown' = none recorded."Input schema / properties / rooms / descriptionPrevious value: -"Rooms (izby), residential units only; multi-select ('8plus' = 8 or more). Rows with no count drop out unless 'unknown' is listed."New value: +"Rooms (izby), residential units only, multi-select ('8plus' = 8+); 'unknown' = no count."Input schema / properties / transactionType / descriptionPrevious 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."New value: +"Multi-select. For market analysis ALWAYS set it to drop non-market deeds (subsidized, foreclosure, public_purpose); untyped rows drop out unless 'unknown'."Input schema / properties / unitFunction / descriptionPrevious value: -"Unit function; 'unknown' = none recorded (NULL), any other value excludes such rows. Garages only via 'garage'."New value: +"Unit function; 'unknown' = none recorded. Garages only via 'garage'."search_transactions3 fields changedInput schema / properties / groupBy / descriptionPrevious value: -"Return a per-year series (median price/m², sample size, deed count; up to 20 years, default last 10) instead of rows. Same filters; one summary call."New value: +"Per-year series (median price/m², sample size, deed count; up to 20 years, default last 10) instead of rows. Same filters; one summary call."Input schema / properties / mpzpDesignation / descriptionPrevious value: -"MPZP zoning designation, exact token match; comma-separated = OR (e.g. 'MN,MW'). 'unknown' = none recorded (NULL), distinct from the code 'brakMPZPLubWZ' (no plan/WZ). Known codes: budownictwoMieszkanioweJednorodzinne, brakMPZPLubWZ, terenRolniczy, innyNiewymieniony, terenZabudowyUslugowej, terenDrogWewnetrznych, terenDrogPublicznych, terenZabudowyZagrodowejGospodarstwRolnych, budownictwoMieszkanioweWielorodzinne, las, terenObiektowProdukcyjnychSkladowIMagazynow, terenSportuIRekreacji, decyzjaWarunkiZabudowy, terenZieleniUrzadzonej, terenZieleniObjetyFormaOchronyPrzyrody, terenWodPowierzchniowychSrodladowych, obszarITerenGorniczy, terenObslugiProdukcjiWGospodarstwachRolnych, terenInfrastrukturyTechnicznej, terenOgrodowDzialkowych, terenRozmieszczeniaDuzcychObiektowHandlowych, cmentarz, terenKomunikacjiWodnejSzlakWodny, terenWodPowierzchniowychMorskich, MN, BP, KD, U, INN, MW, KDW, R, ZP, P, WZ, ZN, WS, UC, ZL, ZD, US, TIT. An unrecognised value is still sent, with a warning."New value: +"MPZP zoning designation, exact token match; comma-separated = OR (e.g. 'MN,MW'). 'unknown' = none recorded (NULL), distinct from the code 'brakMPZPLubWZ' (no plan/WZ). Common codes: budownictwoMieszkanioweJednorodzinne, brakMPZPLubWZ, terenRolniczy, innyNiewymieniony, terenZabudowyUslugowej, terenDrogPublicznych, budownictwoMieszkanioweWielorodzinne, las, and short plan symbols (MN, MW, U, KD). An unrecognised value is still sent, with a warning listing every known code."Input schema / properties / summaryOnly / descriptionPrevious value: -"Aggregate stats only (total, median price/m² with sample size, period), no rows. Costs only the summary call; limit/sort/page/format ignored."New value: +"Aggregates only (total, median price/m² with sample size, period), no rows; cheapest call. limit/sort/page/format ignored."get_parcel_report1 field changedInput schema / properties / presetAdded value: +{
+ "description": "\"zoning\": planning sections only (11 tokens).",
+ "enum": [
+ "full",
+ "zoning"
+ ],
+ "type": "string"
+}get_parcel_mpzpsearch_by_area1 field changedInput schema / properties / groupByAdded value: +{
+ "description": "Return a per-year series (median price/m², sample size, deed count; up to 20 years, default last 10) instead of rows. Same filters; one summary call.",
+ "enum": [
+ "year"
+ ],
+ "type": "string"
+}search_transactions1 field changedInput schema / properties / groupByAdded value: +{
+ "description": "Return a per-year series (median price/m², sample size, deed count; up to 20 years, default last 10) instead of rows. Same filters; one summary call.",
+ "enum": [
+ "year"
+ ],
+ "type": "string"
+}search_by_area7 fields changedInput schema / properties / excludeFractionalShares / descriptionPrevious value: -"true = clean land prices: drops fractional ownership shares, whose price reflects the whole deed. Default false."New value: +"true = clean land prices: drops fractional ownership shares, whose price reflects the whole deed."Input schema / properties / formatAdded value: +{
+ "description": "Row detail; compact by default, full = every recorded field.",
+ "enum": [
+ "compact",
+ "full"
+ ],
+ "type": "string"
+}Input schema / properties / latitude / descriptionPrevious value: -"Latitude (Poland range: 49-55)"New value: +"Latitude."Input schema / properties / limit / descriptionPrevious value: -"Number of results (1-50, default 20)"New value: +"Number of results."Input schema / properties / longitude / descriptionPrevious value: -"Longitude (Poland range: 14-25)"New value: +"Longitude."Input schema / properties / radiusKm / descriptionPrevious value: -"Search radius in km (0.1-50, default 2)."New value: +"Search radius in km."Input schema / properties / summaryOnly / descriptionPrevious value: -"Return only aggregate stats (total, median price/m² with its sample size, period) and no rows. Costs only the summary call; limit/sort/page are ignored."New value: +"Aggregate stats only (total, median price/m² with sample size, period), no rows. Costs only the summary call; limit/sort/page/format ignored."search_by_polygon3 fields changedInput schema / properties / excludeFractionalShares / descriptionPrevious value: -"true = clean land prices: drops fractional ownership shares, whose price reflects the whole deed. Default false."New value: +"true = clean land prices: drops fractional ownership shares, whose price reflects the whole deed."Input schema / properties / formatAdded value: +{
+ "description": "Row detail; compact by default, full = every recorded field.",
+ "enum": [
+ "compact",
+ "full"
+ ],
+ "type": "string"
+}Input schema / properties / limit / descriptionPrevious value: -"Max results (1-3000); 50 shown."New value: +"Max results; 50 shown."search_transactions9 fields changedInput schema / properties / excludeFractionalShares / descriptionPrevious value: -"true = clean land prices: drops fractional ownership shares, whose price reflects the whole deed. Default false."New value: +"true = clean land prices: drops fractional ownership shares, whose price reflects the whole deed."Input schema / properties / formatAdded value: +{
+ "description": "Row detail; compact by default, full = every recorded field.",
+ "enum": [
+ "compact",
+ "full"
+ ],
+ "type": "string"
+}Input schema / properties / limit / descriptionPrevious value: -"Number of results (1-50, default 10)"New value: +"Number of results."Input schema / properties / location / descriptionPrevious value: -"City (e.g. 'Warszawa') or RCN district (e.g. 'Mokotów', 'Kraków-Podgórze'); 'Warszawa', 'Kraków', 'Łódź' expand to all sub-districts. Prefer teryt=; confirm a name with list_locations(search=...) (valid ones are flagged rcn_district)."New value: +"City (e.g. 'Warszawa') or RCN district (e.g. 'Mokotów', 'Kraków-Podgórze'); 'Warszawa', 'Kraków', 'Łódź' expand to all sub-districts."Input schema / properties / order / descriptionPrevious value: -"Sort order (default: desc)"New value: +"Sort order."Input schema / properties / page / descriptionPrevious value: -"Page number for pagination (default: 1)"New value: +"Page number."Input schema / properties / sort / descriptionPrevious value: -"Sort by field (default: date)"New value: +"Sort by field."Input schema / properties / summaryOnly / descriptionPrevious value: -"Return only aggregate stats (total, median price/m² with its sample size, period) and no rows. Costs only the summary call; limit/sort/page are ignored."New value: +"Aggregate stats only (total, median price/m² with sample size, period), no rows. Costs only the summary call; limit/sort/page/format ignored."Input schema / properties / teryt / descriptionPrevious value: -"TERYT code(s), comma-separated, max 10: 2-digit (voivodeship), 4 (county), 6 (municipality) or a precinct code (e.g. '321705_2.0054'). Find codes with list_locations. Exact - avoids name ambiguity."New value: +"TERYT code(s), comma-separated, max 10: 2-digit (voivodeship), 4 (county), 6 (municipality) or a precinct code (e.g. '321705_2.0054')."compare_locations1 field changedInput schema / properties / propertyType / descriptionPrevious value: -"Property type filter (recommended - API requires at least one filter)"New value: +"Property type: building = no land; house with plot = developed_land (recommended - API requires at least one filter)"search_by_area2 fields changedInput schema / properties / maxFootprintArea / descriptionPrevious value: -"Maximum building footprint in m², summed over the transaction's buildings; measured rows only (absence = 'not measured', not 'no building'). Not usable area."New value: +"Maximum building footprint in m²; same rules as minFootprintArea."Input schema / properties / propertyType / descriptionPrevious value: -"Property type filter"New value: +"Property type: building = no land; house with plot = developed_land"search_by_polygon2 fields changedInput schema / properties / maxFootprintArea / descriptionPrevious value: -"Maximum building footprint in m², summed over the transaction's buildings; measured rows only (absence = 'not measured', not 'no building'). Not usable area."New value: +"Maximum building footprint in m²; same rules as minFootprintArea."Input schema / properties / propertyType / descriptionPrevious value: -"Property type filter"New value: +"Property type: building = no land; house with plot = developed_land"search_transactions2 fields changedInput schema / properties / maxFootprintArea / descriptionPrevious value: -"Maximum building footprint in m², summed over the transaction's buildings; measured rows only (absence = 'not measured', not 'no building'). Not usable area."New value: +"Maximum building footprint in m²; same rules as minFootprintArea."Input schema / properties / propertyType / descriptionPrevious value: -"Property type filter"New value: +"Property type: building = no land; house with plot = developed_land"search_by_area1 field changedInput schema / properties / pageAdded value: +{
+ "description": "Page 1-10 (50 rows).",
+ "maximum": 10,
+ "minimum": 1,
+ "type": "integer"
+}search_by_polygon2 fields changedInput schema / properties / limit / descriptionPrevious value: -"Max results (1-3000, default 100). MCP displays up to 50 transactions."New value: +"Max results (1-3000); 50 shown."Input schema / properties / pageAdded value: +{
+ "description": "Page 1-20 (50 rows).",
+ "maximum": 20,
+ "minimum": 1,
+ "type": "integer"
+}get_price_spread1 field changedInput schema / properties / location / descriptionPrevious value: -"County-level city name (a miasto na prawach powiatu or a catalog entry, e.g. 'Warszawa', 'Gdańsk'); a Warszawa district ('Mokotów') narrows to it, 'Kraków-Podgórze' resolves to its parent county. A town in a larger powiat or an osiedle 404s - check the catalog or use teryt. This OR teryt."New value: +"County-level city name (a miasto na prawach powiatu or a catalog entry, e.g. 'Warszawa', 'Gdańsk'); a Warszawa district ('Mokotów') narrows to it, 'Kraków-Podgórze' resolves to its parent county. A gmina name resolves to its county (candidates if shared by gminas in several counties); an osiedle 404s - use teryt. This OR teryt."get_rental_yield1 field changedInput schema / properties / location / descriptionPrevious value: -"County-level city name (a miasto na prawach powiatu or a catalog entry, e.g. 'Warszawa', 'Gdańsk'); a Warszawa district ('Mokotów') narrows to it, 'Kraków-Podgórze' resolves to its parent county. A town in a larger powiat or an osiedle 404s - check the catalog or use teryt. This OR teryt."New value: +"County-level city name (a miasto na prawach powiatu or a catalog entry, e.g. 'Warszawa', 'Gdańsk'); a Warszawa district ('Mokotów') narrows to it, 'Kraków-Podgórze' resolves to its parent county. A gmina name resolves to its county (candidates if shared by gminas in several counties); an osiedle 404s - use teryt. This OR teryt."search_by_area1 field changedInput schema / properties / summaryOnlyAdded value: +{
+ "description": "Return only aggregate stats (total, median price/m² with its sample size, period) and no rows. Costs only the summary call; limit/sort/page are ignored.",
+ "type": "boolean"
+}search_transactions1 field changedInput schema / properties / summaryOnlyAdded value: +{
+ "description": "Return only aggregate stats (total, median price/m² with its sample size, period) and no rows. Costs only the summary call; limit/sort/page are ignored.",
+ "type": "boolean"
+}compare_locations10 fields changedInput schema / properties / buildingType / descriptionPrevious 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."Input schema / properties / districts / descriptionPrevious 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'"Input schema / properties / floor / descriptionPrevious 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."Input schema / properties / includeDemographics / descriptionPrevious 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."Input schema / properties / marketType / descriptionPrevious 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."Input schema / properties / mpzpDesignation / descriptionPrevious value: -"MPZP zoning designation filter, exact token match (not prefix). Comma-separated = OR, e.g. 'MN,MW'. Use 'unknown' for rows with no designation recorded (NULL); distinct from the registry code 'brakMPZPLubWZ' (= 'no plan/WZ' recorded as data). Known codes: budownictwoMieszkanioweJednorodzinne, brakMPZPLubWZ, terenRolniczy, innyNiewymieniony, terenZabudowyUslugowej, terenDrogWewnetrznych, terenDrogPublicznych, terenZabudowyZagrodowejGospodarstwRolnych, budownictwoMieszkanioweWielorodzinne, las, terenObiektowProdukcyjnychSkladowIMagazynow, terenSportuIRekreacji, decyzjaWarunkiZabudowy, terenZieleniUrzadzonej, terenZieleniObjetyFormaOchronyPrzyrody, terenWodPowierzchniowychSrodladowych, obszarITerenGorniczy, terenObslugiProdukcjiWGospodarstwachRolnych, terenInfrastrukturyTechnicznej, terenOgrodowDzialkowych, terenRozmieszczeniaDuzcychObiektowHandlowych, cmentarz, terenKomunikacjiWodnejSzlakWodny, terenWodPowierzchniowychMorskich, MN, BP, KD, U, INN, MW, KDW, R, ZP, P, WZ, ZN, WS, UC, ZL, ZD, US, TIT. An unrecognised value is still sent but adds a warning to the reply."New value: +"MPZP zoning designation, exact token match; comma-separated = OR; 'unknown' = none recorded. Same codes as search_transactions mpzpDesignation."Input schema / properties / ownershipType / descriptionPrevious 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."Input schema / properties / rooms / descriptionPrevious 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."Input schema / properties / transactionType / descriptionPrevious 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."Input schema / properties / unitFunction / descriptionPrevious 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'."estimate_land_value7 fields changedInput schema / properties / area / descriptionPrevious value: -"Plot area in m² (100–1000000 = 100 m² to 100 ha). REQUIRED with lat/lng; optional with parcelId (read from the cadastre when omitted)."New value: +"Plot area in m² (100–1000000). REQUIRED with lat/lng; with parcelId read from the cadastre when omitted."Input schema / properties / includeComps / descriptionPrevious value: -"Echo the nearest comparables the estimate weighed (default true). Set false for the estimate only."New value: +"Echo the comparables weighed (default true); false = estimate only."Input schema / properties / landType / descriptionPrevious value: -"Comparable segment: plot (a building plot, default) or agricultural (farmland). The caller chooses it."New value: +"Comparable segment: plot (building plot, default) or agricultural (farmland); the caller chooses."Input schema / properties / lat / descriptionPrevious value: -"Latitude of the plot (WGS84, Poland). Must be paired with lng. Use this OR parcelId. area is required on this path."New value: +"Latitude of the plot (WGS84, Poland); pair with lng. Use this OR parcelId (area is then required)."Input schema / properties / lng / descriptionPrevious value: -"Longitude of the plot (WGS84, Poland). Must be paired with lat. Use this OR parcelId. area is required on this path."New value: +"Longitude of the plot (WGS84, Poland); pair with lat. Use this OR parcelId (area is then required)."Input schema / properties / mpzpDesignation / descriptionPrevious value: -"Narrow the comparables to a recorded land-designation token (e.g. 'budownictwoMieszkanioweJednorodzinne'); 'unknown' matches rows with no designation recorded (optional)."New value: +"Narrow comparables to a recorded land-designation token (e.g. 'budownictwoMieszkanioweJednorodzinne'); 'unknown' = none recorded."Input schema / properties / parcelId / descriptionPrevious value: -"Full cadastral id (slash or dash form) or internal UUID; the parcel centroid is used and area defaults to the cadastre when omitted. Use instead of lat/lng."New value: +"Full cadastral id or internal UUID; the parcel centroid is used. Instead of lat/lng."estimate_value7 fields changedInput schema / properties / area / descriptionPrevious value: -"Apartment usable area in m² (REQUIRED, 10–250). Estimates for 300+ m² are unreliable and rejected."New value: +"Apartment usable area in m² (REQUIRED, 10–250)."Input schema / properties / includeComps / descriptionPrevious value: -"Echo the nearest comparables the estimate weighed (default true). Set false for the estimate only."New value: +"Echo the comparables weighed (default true); false = estimate only."Input schema / properties / lat / descriptionPrevious value: -"Latitude of the apartment (WGS84, Poland). Must be paired with lng. Use this OR parcelId."New value: +"Latitude of the apartment (WGS84, Poland); pair with lng. Use this OR parcelId."Input schema / properties / lng / descriptionPrevious value: -"Longitude of the apartment (WGS84, Poland). Must be paired with lat. Use this OR parcelId."New value: +"Longitude of the apartment (WGS84, Poland); pair with lat. Use this OR parcelId."Input schema / properties / market / descriptionPrevious value: -"Restrict comparables to the primary (new-build) or secondary market (optional)."New value: +"Restrict comparables to the primary (new-build) or secondary market."Input schema / properties / parcelId / descriptionPrevious value: -"Full cadastral id (slash or dash form) or internal UUID; the parcel centroid is used. Use instead of lat/lng."New value: +"Full cadastral id (slash or dash form) or internal UUID; the parcel centroid is used. Instead of lat/lng."Input schema / properties / rooms / descriptionPrevious value: -"Room count (1–10, optional) — narrows the comparables to ±1 room."New value: +"Room count (1–10); narrows comparables to ±1 room."get_building_breakdown2 fields changedInput schema / properties / transactionId / descriptionRemoved value: -"Alias of transaction_id."Input schema / properties / transaction_id / descriptionPrevious value: -"Transaction id (UUID) from a search_transactions / search_by_area / search_by_polygon result that carries building data. One of transaction_id / transactionId is required."New value: +"Transaction id (UUID) from a search result that carries building data. This or transactionId is required."get_demographics4 fields changedInput schema / properties / category / descriptionPrevious value: -"Filter to these categories. Omit to return all available."New value: +"Categories to return; omit for all."Input schema / properties / location / descriptionPrevious value: -"City, county, gmina, or district name (e.g. 'Warszawa', 'Kraków', 'Wieliczka'). A city/county name resolves to county/powiat level; a gmina name resolves to that gmina; a Warszawa district name (e.g. 'Mokotów') resolves to that district, another city's delegatura (e.g. 'Kraków-Podgórze') to its parent county. A name shared by several units returns the candidates with their codes; pass one as teryt. Use this OR teryt."New value: +"City, county, gmina or district name (e.g. 'Warszawa', 'Wieliczka'): city/county → county level, gmina → that gmina, a Warszawa district ('Mokotów') → that district, another city's delegatura ('Kraków-Podgórze') → its parent county. Shared name → candidates; pass one as teryt. Use this OR teryt."Input schema / properties / teryt / descriptionPrevious value: -"TERYT code: 2-digit (voivodeship, e.g. 14), 4-digit (county, e.g. 1465), 6 or 7-digit (gmina, e.g. 1465011). The 7th digit selects the unit type: 3 = urban-rural gmina overall, 4/5 = urban/rural part only, 8 = Warszawa district (1465011 = all of Warszawa, 1465108 = Śródmieście). Wins over location. Use list_locations to find codes."New value: +"TERYT: 2-digit voivodeship (14), 4 county (1465), 6 or 7 gmina (1465011). 7th digit: 3 = urban-rural gmina overall, 4/5 = urban/rural part only, 8 = Warszawa district (1465108 = Śródmieście). Wins over location."Input schema / properties / year / descriptionPrevious value: -"Single year (2003-present). Mutually exclusive with yearFrom/yearTo. Omit for the latest available year per indicator."New value: +"Single year (2003-present); exclusive with yearFrom/yearTo. Omit for the latest year per indicator."get_flood_risk2 fields changedInput schema / properties / location / descriptionPrevious value: -"County-level city/county name (e.g. 'Warszawa', 'Kraków', 'Gdańsk'). District names are accepted (a Warszawa district or another city's delegatura, e.g. 'Kraków-Podgórze'), and so are gmina names (e.g. 'Wieliczka'), but coverage is county-level, so the answer is the parent county with a note. A gmina name shared by counties returns the candidates with their codes. A town within a larger powiat or an osiedle may 404 — check the catalog or use teryt first. Use this OR teryt."New value: +"City or county name (e.g. 'Warszawa', 'Gdańsk'). District and gmina names are accepted ('Kraków-Podgórze', 'Wieliczka') but coverage is county-level, so the answer is the parent county with a note. A gmina name shared by counties returns candidates. A town within a larger powiat or an osiedle may 404 - check the catalog or use teryt. This OR teryt."Input schema / properties / teryt / descriptionPrevious value: -"TERYT code. 4 digits = county (e.g. 1465 = Warszawa). Longer codes (gmina/precinct/district) are truncated/resolved to the county. Wins over location when both are provided."New value: +"TERYT code. 4 digits = county (e.g. 1465 = Warszawa). Longer codes (gmina/precinct/district) resolve to the county. Wins over location."get_infrastructure_signals1 field changedInput schema / properties / location / descriptionPrevious value: -"City, county, gmina, or district name (e.g. 'Warszawa', 'Krotoszyn'). A city/county name aggregates every municipality in the county; a gmina name answers for that gmina alone; a Warszawa district name (e.g. 'Mokotów') narrows to that gmina, another city's delegatura (e.g. 'Kraków-Podgórze') resolves to its parent county. A name shared by several units returns the candidates with their codes; pass one as teryt. Use this OR teryt."New value: +"City, county, gmina or district name (e.g. 'Warszawa', 'Krotoszyn'): city/county → every municipality in the county, gmina → that gmina alone, a Warszawa district ('Mokotów') → that gmina, another city's delegatura ('Kraków-Podgórze') → its parent county. Shared name → candidates; pass one as teryt. Use this OR teryt."get_parcel_land_class1 field changedInput schema / properties / parcelId / descriptionPrevious value: -"Full cadastral id ('142907_2.0014.342/5' or the '-' form) or the internal UUID from a search/resolve result."New value: +"Full cadastral id ('142907_2.0014.342/5' or the '-' form) or internal UUID."get_parcel_report1 field changedInput schema / properties / parcelId / descriptionPrevious value: -"Full cadastral id ('142907_2.0014.342/5' or the '-' form) or the internal UUID from a search/resolve result."New value: +"Full cadastral id ('142907_2.0014.342/5' or the '-' form) or internal UUID."get_permits_in_area11 fields changedInput schema / properties / aggregateOnly / descriptionPrevious value: -"true = return only the aggregate (year × category counts, permit/notification split, volumes) without the case list, for 'how many' questions. Same price; cannot be combined with cursor."New value: +"true = only the aggregate (year × category counts, split, volumes), no case list. Same price; not with cursor."Input schema / properties / categories / descriptionPrevious value: -"Keep only these statutory object categories (Roman numerals I–XXX), e.g. [\"XIII\"] for apartment blocks or [\"XXVI\"] for utility networks. Not combinable with intent other than all, and must not overlap with excludeCategories."New value: +"Keep only these object categories (Roman numerals I–XXX). Not with intent other than all; must not overlap excludeCategories."Input schema / properties / cursor / descriptionPrevious value: -"Opaque cursor from the previous answer, to get the next page. Pass it back unchanged with the same filters (limit may differ); it is not available with aggregateOnly."New value: +"Cursor from the previous answer, for the next page; pass it back unchanged with the same filters. Not with aggregateOnly."Input schema / properties / dateFrom / descriptionPrevious value: -"Window start, YYYY-MM-DD, on the decision date (intake date for notifications). Default: two years back; earlier than 2016-01-01 is treated as 2016-01-01."New value: +"Window start, YYYY-MM-DD (decision date; intake date for notifications). Default two years back; earlier than 2016-01-01 counts as 2016-01-01."Input schema / properties / dateTo / descriptionPrevious value: -"Window end, YYYY-MM-DD, inclusive; not earlier than dateFrom. When it is older than two years, pass dateFrom as well (the default start is two years back)."New value: +"Window end, YYYY-MM-DD, inclusive, not before dateFrom. When older than two years, pass dateFrom as well."Input schema / properties / excludeCategories / descriptionPrevious value: -"Remove these statutory object categories (cases without a category stay), e.g. [\"XXVI\"] to drop utility networks. Must not overlap with categories."New value: +"Drop these object categories (cases without a category stay). Must not overlap categories."Input schema / properties / intent / descriptionPrevious value: -"Shorthand: multi_family = categories [XIII], single_family = categories [I] (includes semi-detached and terraced houses), all = no filter (default). Cannot be combined with categories."New value: +"multi_family = categories [XIII], single_family = [I] (incl. semi-detached and terraced), all = no filter (default). Not with categories."Input schema / properties / lat / descriptionPrevious value: -"Latitude of the circle's centre (WGS84, Poland). From a resolve_parcel / list_parcels_in_area result or the user; never guessed."New value: +"Circle centre latitude (WGS84, Poland), from resolve_parcel / list_parcels_in_area or the user; never guessed."Input schema / properties / limit / descriptionPrevious value: -"Cases in the list, 1–200 (default 50). The aggregate always counts all matched cases."New value: +"Cases in the list, 1–200 (default 50). The aggregate counts all matched cases."Input schema / properties / lng / descriptionPrevious value: -"Longitude of the circle's centre (WGS84, Poland). From a resolve_parcel / list_parcels_in_area result or the user; never guessed."New value: +"Circle centre longitude (WGS84, Poland), from resolve_parcel / list_parcels_in_area or the user; never guessed."Input schema / properties / radiusKm / descriptionPrevious value: -"Radius in km, 0.1–2 (default 2). For a wider area, call again for neighbouring centre points; for what is closest to the point, use a smaller radius."New value: +"Radius in km, 0.1–2 (default 2)."get_price_spread4 fields changedInput schema / properties / areaBucket / descriptionPrevious value: -"Apartment area range in m2: all (default, whole stock), 0-30, 30-40, 40-50, 50-60, 60-80, 80+. Bucket values are not additive."New value: +"Apartment area range in m² (all = whole stock, default). Buckets are not additive."Input schema / properties / location / descriptionPrevious value: -"County-level city name — a miasto na prawach powiatu or a catalog entry from list_price_spread_locations (e.g. 'Warszawa', 'Kraków', 'Gdańsk'). A Warszawa district name (e.g. 'Mokotów') narrows to that district; another city's delegatura (e.g. 'Kraków-Podgórze') resolves to its parent county. A town within a larger powiat or an osiedle will 404 — check the catalog or use teryt first. Use this OR teryt."New value: +"County-level city name (a miasto na prawach powiatu or a catalog entry, e.g. 'Warszawa', 'Gdańsk'); a Warszawa district ('Mokotów') narrows to it, 'Kraków-Podgórze' resolves to its parent county. A town in a larger powiat or an osiedle 404s - check the catalog or use teryt. This OR teryt."Input schema / properties / marketType / descriptionPrevious value: -"Transaction denominator segment: 'all' (default, composition-matched to mixed sale offers), 'secondary', or 'primary'."New value: +"Transaction-side segment: 'all' (default, matched to mixed sale offers), 'secondary' or 'primary'."Input schema / properties / teryt / descriptionPrevious value: -"TERYT code. 4 digits = county (e.g. 1465 = Warszawa). 6 digits = dzielnica where available (today: Warszawa's 18 districts, e.g. 146510 = Śródmieście) → spread for that district. Other longer codes (gmina/precinct) are truncated to the county. Wins over location when both are provided."New value: +"TERYT: 4 digits = county (1465 = Warszawa); 6 digits = a Warszawa district (146510 = Śródmieście); other longer codes truncate to the county. Wins over location."get_price_statistics1 field changedInput schema / properties / location / descriptionPrevious value: -"Filter by location name. 'Warszawa'/'Kraków'/'Łódź' auto-expand to all sub-districts. Other names use case-insensitive partial match (e.g. 'Wrocł' matches 'Wrocław'). Omit for all Poland."New value: +"Location name; 'Warszawa'/'Kraków'/'Łódź' expand to all sub-districts, other names use case-insensitive partial match (e.g. 'Wrocł' matches 'Wrocław'). Omit for all Poland."get_rental_yield3 fields changedInput schema / properties / areaBucket / descriptionPrevious value: -"Apartment area range in m2: all (default, whole stock), 0-30, 30-40, 40-50, 50-60, 60-80, 80+. Bucket values are not additive."New value: +"Apartment area range in m² (all = whole stock, default). Buckets are not additive."Input schema / properties / location / descriptionPrevious value: -"County-level city name — a miasto na prawach powiatu or a catalog entry from list_rental_yield_locations (e.g. 'Warszawa', 'Kraków', 'Gdańsk'). A Warszawa district name (e.g. 'Mokotów') narrows to that district; another city's delegatura (e.g. 'Kraków-Podgórze') resolves to its parent county. A town within a larger powiat or an osiedle will 404 — check the catalog or use teryt first. Use this OR teryt."New value: +"County-level city name (a miasto na prawach powiatu or a catalog entry, e.g. 'Warszawa', 'Gdańsk'); a Warszawa district ('Mokotów') narrows to it, 'Kraków-Podgórze' resolves to its parent county. A town in a larger powiat or an osiedle 404s - check the catalog or use teryt. This OR teryt."Input schema / properties / teryt / descriptionPrevious value: -"TERYT code. 4 digits = county (e.g. 1465 = Warszawa). 6 digits = dzielnica where available (today: Warszawa's 18 districts, e.g. 146510 = Śródmieście) → yield for that district. Other longer codes (gmina/precinct) are truncated to the county. Wins over location when both are provided."New value: +"TERYT: 4 digits = county (1465 = Warszawa); 6 digits = a Warszawa district (146510 = Śródmieście); other longer codes truncate to the county. Wins over location."get_transaction_farmland2 fields changedInput schema / properties / transactionId / descriptionRemoved value: -"Alias of transaction_id."Input schema / properties / transaction_id / descriptionPrevious value: -"Transaction id (UUID) from a search_transactions / search_by_area / search_by_polygon result. One of transaction_id / transactionId is required."New value: +"Transaction id (UUID) from a search result. This or transactionId is required."get_transaction_flood2 fields changedInput schema / properties / transactionId / descriptionRemoved value: -"Alias of transaction_id."Input schema / properties / transaction_id / descriptionPrevious value: -"Transaction id (UUID) from a search_transactions / search_by_area / search_by_polygon result. One of transaction_id / transactionId is required."New value: +"Transaction id (UUID) from a search result. This or transactionId is required."get_transaction_heritage2 fields changedInput schema / properties / transactionId / descriptionRemoved value: -"Alias of transaction_id."Input schema / properties / transaction_id / descriptionPrevious value: -"Transaction id (UUID) from a search_transactions / search_by_area / search_by_polygon result. One of transaction_id / transactionId is required."New value: +"Transaction id (UUID) from a search result. This or transactionId is required."get_transaction_landslide2 fields changedInput schema / properties / transactionId / descriptionRemoved value: -"Alias of transaction_id."Input schema / properties / transaction_id / descriptionPrevious value: -"Transaction id (UUID) from a search_transactions / search_by_area / search_by_polygon result. One of transaction_id / transactionId is required."New value: +"Transaction id (UUID) from a search result. This or transactionId is required."get_transaction_nature2 fields changedInput schema / properties / transactionId / descriptionRemoved value: -"Alias of transaction_id."Input schema / properties / transaction_id / descriptionPrevious value: -"Transaction id (UUID) from a search_transactions / search_by_area / search_by_polygon result. One of transaction_id / transactionId is required."New value: +"Transaction id (UUID) from a search result. This or transactionId is required."get_transaction_permits2 fields changedInput schema / properties / transactionId / descriptionRemoved value: -"Alias of transaction_id."Input schema / properties / transaction_id / descriptionPrevious value: -"Transaction id (UUID) from a search_transactions / search_by_area / search_by_polygon result. One of transaction_id / transactionId is required."New value: +"Transaction id (UUID) from a search result. This or transactionId is required."get_transaction_planning2 fields changedInput schema / properties / transactionId / descriptionRemoved value: -"Alias of transaction_id."Input schema / properties / transaction_id / descriptionPrevious value: -"Transaction id (UUID) from a search_transactions / search_by_area / search_by_polygon result. One of transaction_id / transactionId is required."New value: +"Transaction id (UUID) from a search result. This or transactionId is required."get_transaction_roads2 fields changedInput schema / properties / transactionId / descriptionRemoved value: -"Alias of transaction_id."Input schema / properties / transaction_id / descriptionPrevious value: -"Transaction id (UUID) from a search_transactions / search_by_area / search_by_polygon result. One of transaction_id / transactionId is required."New value: +"Transaction id (UUID) from a search result. This or transactionId is required."get_transaction_subsurface2 fields changedInput schema / properties / transactionId / descriptionRemoved value: -"Alias of transaction_id."Input schema / properties / transaction_id / descriptionPrevious value: -"Transaction id (UUID) from a search_transactions / search_by_area / search_by_polygon result. One of transaction_id / transactionId is required."New value: +"Transaction id (UUID) from a search result. This or transactionId is required."get_transaction_surroundings2 fields changedInput schema / properties / transactionId / descriptionRemoved value: -"Alias of transaction_id."Input schema / properties / transaction_id / descriptionPrevious value: -"Transaction id (UUID) from a search_transactions / search_by_area / search_by_polygon result. One of transaction_id / transactionId is required."New value: +"Transaction id (UUID) from a search result. This or transactionId is required."get_transaction_transit2 fields changedInput schema / properties / transactionId / descriptionRemoved value: -"Alias of transaction_id."Input schema / properties / transaction_id / descriptionPrevious value: -"Transaction id (UUID) from a search_transactions / search_by_area / search_by_polygon result. One of transaction_id / transactionId is required."New value: +"Transaction id (UUID) from a search result. This or transactionId is required."list_flood_risk_locations1 field changedInput schema / properties / search / descriptionPrevious value: -"Filter by county name (diacritic-insensitive substring, min 2 chars). E.g. 'gda' → Gdańsk. Omit to list the full catalog."New value: +"County name filter (diacritic-insensitive substring, min 2 chars), e.g. 'gda' → Gdańsk. Omit for the full catalog."list_locations2 fields changedInput schema / properties / parent / descriptionPrevious value: -"TERYT parent code to browse children. 2-digit (voivodeship → counties), 4-digit (county → municipalities), 6-digit (municipality → precincts). Omit for all voivodeships."New value: +"TERYT parent code to browse children: 2-digit (voivodeship → counties), 4-digit (county → municipalities), 6-digit (municipality → precincts). Omit for all voivodeships."Input schema / properties / search / descriptionPrevious value: -"Look up a place by name (case-insensitive, diacritics-insensitive partial match, e.g. 'wejher' for Wejherowo). Returns TERYT codes plus, where applicable, RCN district names. Ignored when parent is set."New value: +"Place name, case- and diacritics-insensitive partial match (e.g. 'wejher' for Wejherowo). Returns TERYT codes plus, where applicable, RCN district names. Ignored when parent is set."list_parcels_in_area13 fields changedInput schema / properties / bbox / descriptionPrevious value: -"Bounding box in WGS84 as \"minLng,minLat,maxLng,maxLat\", covering at most 500 km². Required for includeGeometry=true."New value: +"Bounding box \"minLng,minLat,maxLng,maxLat\" (WGS84), at most 500 km². Required for includeGeometry=true."Input schema / properties / buildingNumber / descriptionPrevious value: -"Building number. Against the record the match is exact ('12A' does not find '12a') and RCN numbering is often compound ('84/92'), so an exact '84' misses '84/92'. When that comes back empty, the same number is tried against official address points instead, case-insensitively ('12a' finds '12A') but still exact, matching the street by the same whole-word rule as street, not a fragment — if that also misses, drop the number and read the numbers off the street's rows. Requires street. Same scope requirement as street."New value: +"Building number, exact; needs street, same scope requirement. If nothing is found, drop the number and read the numbers off the street's rows."Input schema / properties / cursor / descriptionPrevious value: -"Opaque cursor from the previous light-list answer, to get the next page. Pass it back unchanged; it is not available on outline calls."New value: +"Opaque cursor from the previous light-list answer, for the next page; pass it back unchanged. Not available on outline calls."Input schema / properties / includeGeometry / descriptionPrevious value: -"Return each parcel's full outline instead of the light row (5 tokens instead of 2, at most 100 parcels, no paging). Requires a bbox; with a polygon the outlines come back anyway."New value: +"Return full outlines instead of the light row (5 tokens instead of 2). Requires a bbox; with a polygon outlines come back anyway."Input schema / properties / lat / descriptionPrevious value: -"Latitude of the circle centre (WGS84). Requires lng and radiusKm."New value: +"Circle centre latitude (WGS84). Needs lng and radiusKm."Input schema / properties / limit / descriptionPrevious value: -"Max parcels returned. Light list: up to 1000, default 250. Outlines: up to 100, default 50 — a larger value is clamped there."New value: +"Max parcels. Light list: up to 1000, default 250. Outlines: up to 100, default 50."Input schema / properties / lng / descriptionPrevious value: -"Longitude of the circle centre (WGS84). Requires lat and radiusKm."New value: +"Circle centre longitude (WGS84). Needs lat and radiusKm."Input schema / properties / location / descriptionPrevious value: -"County, city, gmina, or district name, resolved to its TERYT code. A Warszawa district name (e.g. 'Mokotów') narrows to that district; another city's delegatura (e.g. 'Kraków-Podgórze') resolves to its parent county; a gmina name (e.g. 'Wieliczka') answers at municipality level. A name shared by several units is an error listing the candidates with their codes."New value: +"County, city, gmina or district name, resolved to its TERYT code ('Mokotów' = that Warszawa district; 'Kraków-Podgórze' = its parent county; a gmina name answers at municipality level)."Input schema / properties / minArea / descriptionPrevious value: -"Minimum parcel surface in m². Needs a bbox, a circle, a location name, or a teryt of at least 4 digits. Not available with includeGeometry or a polygon."New value: +"Minimum parcel surface in m². Needs a narrow scope; not with includeGeometry or a polygon."Input schema / properties / polygon / descriptionPrevious value: -"GeoJSON Polygon geometry. Coordinates: [longitude, latitude] pairs, first and last point identical, at most 500 vertices. Always returns outlines. Pass it instead of the other area parameters, not alongside them."New value: +"GeoJSON Polygon: [longitude, latitude] pairs, first and last point identical, max 500 vertices. Always returns outlines. Pass it instead of the other area parameters."Input schema / properties / radiusKm / descriptionPrevious value: -"Circle radius in km (max 12.6 — the radius covering the 500 km² ceiling). Requires lat and lng."New value: +"Circle radius in km (max 12.6, the radius covering 500 km²). Needs lat and lng."Input schema / properties / street / descriptionPrevious value: -"Street name, matched by whole words within the name, case- and accent-insensitively (min 4 letters or digits): 'Górna' finds 'ulica Górna' and 'Górna 15' but not 'Podgórna', and a fragment like 'Marsza' finds nothing. NOMINATIVE: 'Karmelickiej' does not fold to 'Karmelicka' and answers empty. Needs a bbox, a circle, a location name, or a teryt of at least 4 digits. Not available with includeGeometry or a polygon."New value: +"Street name in the NOMINATIVE (min 4 letters or digits). Needs a bbox, a circle, a location name, or a teryt of at least 4 digits; not with includeGeometry or a polygon."Input schema / properties / teryt / descriptionPrevious value: -"TERYT administrative code prefix (2/4/6 digits or finer), comma-separated for several. Wins over location when both are given."New value: +"TERYT code prefix (2/4/6 digits or finer), comma-separated for several. Wins over location."list_price_spread_locations1 field changedInput schema / properties / search / descriptionPrevious value: -"Filter by city name (diacritic-insensitive substring, min 2 chars). E.g. 'gda' → Gdańsk. Omit to list the full catalog."New value: +"City name filter (diacritic-insensitive substring, min 2 chars), e.g. 'gda' → Gdańsk. Omit for the full catalog."list_rental_yield_locations1 field changedInput schema / properties / search / descriptionPrevious value: -"Filter by city name (diacritic-insensitive substring, min 2 chars). E.g. 'gda' → Gdańsk. Omit to list the full catalog."New value: +"City name filter (diacritic-insensitive substring, min 2 chars), e.g. 'gda' → Gdańsk. Omit for the full catalog."resolve_parcel4 fields changedInput schema / properties / lat / descriptionPrevious value: -"Latitude WGS84. Must be paired with lng. Mutually exclusive with q and parcelId."New value: +"Latitude WGS84; pair with lng. Exclusive with q and parcelId."Input schema / properties / lng / descriptionPrevious value: -"Longitude WGS84. Must be paired with lat. Mutually exclusive with q and parcelId."New value: +"Longitude WGS84; pair with lat. Exclusive with q and parcelId."Input schema / properties / parcelId / descriptionPrevious value: -"Full cadastral id (slash or dash form) or internal UUID. Mutually exclusive with q and lat/lng."New value: +"Full cadastral id (slash or dash form) or internal UUID. Exclusive with q and lat/lng."Input schema / properties / q / descriptionPrevious value: -"Full cadastral id, a UUID, or 'locality name + parcel number' (e.g. 'Sabnie 342/5') — the name may be a gmina or a cadastral precinct (obręb). NOT a street address: for a street + building number use list_parcels_in_area instead. Mutually exclusive with parcelId and lat/lng."New value: +"Full cadastral id, UUID, or 'locality name + parcel number' (e.g. 'Sabnie 342/5'); not a street address. Exclusive with parcelId and lat/lng."search_by_area18 fields changedInput schema / properties / buildingStoreys / descriptionPrevious value: -"Number of above-ground storeys of the building. Multi-select buckets: exact non-negative integers (e.g. '1','2'), 'Nplus' e.g. '3plus' = 3 or more, 'unknown' = no storey count recorded (NULL). Recorded ONLY for single-building transactions, so 'unknown' covers BOTH a deed with several buildings (no single storey count exists) and a single building with missing data — never read it as 'a building with no storeys'. This is NOT the floor of a unit (see floor). Without 'unknown', rows with no storey count are excluded."New value: +"Above-ground storeys, multi-select: integers, 'Nplus' ('3plus' = 3+), 'unknown' (no count). Single-building deeds only, so 'unknown' also covers multi-building deeds. Not the unit floor; rows with no count drop out unless 'unknown' is listed."Input schema / properties / buildingType / descriptionPrevious 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."Input schema / properties / excludeFractionalShares / descriptionPrevious value: -"Set true to analyze clean land prices: excludes fractional ownership shares, whose price reflects the whole deed rather than the share and skews a per-m² comparison. Default false."New value: +"true = clean land prices: drops fractional ownership shares, whose price reflects the whole deed. Default false."Input schema / properties / floodRisk / descriptionPrevious value: -"Flood-hazard filter. high = most frequent flooding (~1-in-10-year), medium (~1-in-100-year), low = rarest (~1-in-500-year). Selects ONLY transactions whose land sits in a mapped flood zone; absence of a zone is never asserted as 'safe'. Multi-select; e.g. ['medium','high'] = at least medium risk."New value: +"Flood-hazard zone, multi-select: high ~1-in-10-year, medium ~1-in-100, low ~1-in-500. Mapped zones only; absence of a zone is never 'safe'."Input schema / properties / floor / descriptionPrevious 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."Input schema / properties / heritageStatus / descriptionPrevious value: -"Heritage-listing filter. listed = a protected monument on/at the property's land; zone = the land lies within a protected urban layout or the designated surroundings of a monument. Selects ONLY transactions where a listing was detected; absence of a detection is never asserted as 'not listed'. Multi-select; e.g. ['listed'] = individually listed properties only."New value: +"Heritage listing, multi-select: listed = protected monument on the land; zone = protected urban layout or monument surroundings. Detected listings only; absence of a detection is never 'not listed'."Input schema / properties / landUse / descriptionPrevious value: -"Recorded land-use category of the transaction's land. Multi-select from: gruntyZabudowaneIZurbanizowane (built-up and urbanised), gruntyRolne (agricultural), gruntyLesne (forest), terenyKomunikacyjne (transport), inne (other). 'unknown' = no category recorded for the land (NULL) — a legitimate bucket, never a claim that the land has no use. Values are case-sensitive. E.g. ['gruntyRolne'] for farmland, or ['gruntyZabudowaneIZurbanizowane','gruntyRolne'] to compare developed vs farmland."New value: +"Land-use category, multi-select, case-sensitive (gruntyZabudowaneIZurbanizowane = built-up, gruntyRolne = agricultural, gruntyLesne = forest, terenyKomunikacyjne = transport); 'unknown' = none recorded (NULL), not 'no use'."Input schema / properties / landslideRisk / descriptionPrevious value: -"Landslide-hazard filter, from official landslide-hazard maps (1:10,000 scale). 'landslide' = the land intersects a mapped landslide area; 'threatened' = an area threatened by mass movements. Selects ONLY transactions whose land intersects a mapped hazard area — an intersection means overlap with a mapped area, not that the parcel itself is a landslide; absence of a zone is never asserted as 'safe'. Multi-select; e.g. ['landslide','threatened'] = any mapped hazard."New value: +"Landslide hazard, multi-select: landslide = mapped landslide area; threatened = area threatened by mass movements. Mapped areas only; absence of a zone is never 'safe'."Input schema / properties / marketType / descriptionPrevious value: -"Market type: primary (developer) or secondary (resale). ~55% of records have unknown market type and will be excluded when this filter is used."New value: +"primary (developer) or secondary (resale); the ~55% of records with no market type drop out when this is set."Input schema / properties / maxFootprintArea / descriptionPrevious value: -"Maximum building footprint (ground-plan) area in m², summed over all buildings of the transaction. Distinct from maxArea, which measures usable floor area (units) or land/parcel area. Set only where every linked building has footprint data, so this bound selects only measured rows — absence means 'not measured', not 'no building'."New value: +"Maximum building footprint in m², summed over the transaction's buildings; measured rows only (absence = 'not measured', not 'no building'). Not usable area."Input schema / properties / minArea / descriptionPrevious value: -"Minimum area in m² (usable_area_m2 for units, parcel_area for land)"New value: +"Minimum area in m² (usable area for units, parcel area for land)"Input schema / properties / minFootprintArea / descriptionPrevious value: -"Minimum building footprint (ground-plan) area in m², summed over all buildings of the transaction. Distinct from minArea, which measures usable floor area (units) or land/parcel area. Set only where every linked building has footprint data, so this bound selects only measured rows — absence means 'not measured', not 'no building'."New value: +"Minimum building footprint in m², summed over the transaction's buildings; measured rows only (absence = 'not measured', not 'no building'). Not usable area."Input schema / properties / mpzpDesignation / descriptionPrevious value: -"MPZP zoning designation filter, exact token match (not prefix). Comma-separated = OR, e.g. 'MN,MW'. Use 'unknown' for rows with no designation recorded (NULL); distinct from the registry code 'brakMPZPLubWZ' (= 'no plan/WZ' recorded as data). Known codes: budownictwoMieszkanioweJednorodzinne, brakMPZPLubWZ, terenRolniczy, innyNiewymieniony, terenZabudowyUslugowej, terenDrogWewnetrznych, terenDrogPublicznych, terenZabudowyZagrodowejGospodarstwRolnych, budownictwoMieszkanioweWielorodzinne, las, terenObiektowProdukcyjnychSkladowIMagazynow, terenSportuIRekreacji, decyzjaWarunkiZabudowy, terenZieleniUrzadzonej, terenZieleniObjetyFormaOchronyPrzyrody, terenWodPowierzchniowychSrodladowych, obszarITerenGorniczy, terenObslugiProdukcjiWGospodarstwachRolnych, terenInfrastrukturyTechnicznej, terenOgrodowDzialkowych, terenRozmieszczeniaDuzcychObiektowHandlowych, cmentarz, terenKomunikacjiWodnejSzlakWodny, terenWodPowierzchniowychMorskich, MN, BP, KD, U, INN, MW, KDW, R, ZP, P, WZ, ZN, WS, UC, ZL, ZD, US, TIT. An unrecognised value is still sent but adds a warning to the reply."New value: +"MPZP zoning designation, exact token match; comma-separated = OR; 'unknown' = none recorded. Same codes as search_transactions mpzpDesignation."Input schema / properties / ownershipType / descriptionPrevious 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."Input schema / properties / radiusKm / descriptionPrevious value: -"Search radius in km (0.1-50, default 2). Use 0.5-1 for neighborhoods, 0.3-0.5 for streets."New value: +"Search radius in km (0.1-50, default 2)."Input schema / properties / rooms / descriptionPrevious 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."Input schema / properties / transactionType / descriptionPrevious 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."Input schema / properties / unitFunction / descriptionPrevious 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'."search_by_polygon14 fields changedInput schema / properties / buildingStoreys / descriptionPrevious value: -"Number of above-ground storeys of the building. Multi-select buckets: exact non-negative integers (e.g. '1','2'), 'Nplus' e.g. '3plus' = 3 or more, 'unknown' = no storey count recorded (NULL). Recorded ONLY for single-building transactions, so 'unknown' covers BOTH a deed with several buildings (no single storey count exists) and a single building with missing data — never read it as 'a building with no storeys'. This is NOT the floor of a unit (see floor). Without 'unknown', rows with no storey count are excluded."New value: +"Above-ground storeys, multi-select: integers, 'Nplus' ('3plus' = 3+), 'unknown' (no count). Single-building deeds only, so 'unknown' also covers multi-building deeds. Not the unit floor; rows with no count drop out unless 'unknown' is listed."Input schema / properties / buildingType / descriptionPrevious 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."Input schema / properties / excludeFractionalShares / descriptionPrevious value: -"Set true to analyze clean land prices: excludes fractional ownership shares, whose price reflects the whole deed rather than the share and skews a per-m² comparison. Default false."New value: +"true = clean land prices: drops fractional ownership shares, whose price reflects the whole deed. Default false."Input schema / properties / floor / descriptionPrevious 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."Input schema / properties / landUse / descriptionPrevious value: -"Recorded land-use category of the transaction's land. Multi-select from: gruntyZabudowaneIZurbanizowane (built-up and urbanised), gruntyRolne (agricultural), gruntyLesne (forest), terenyKomunikacyjne (transport), inne (other). 'unknown' = no category recorded for the land (NULL) — a legitimate bucket, never a claim that the land has no use. Values are case-sensitive. E.g. ['gruntyRolne'] for farmland, or ['gruntyZabudowaneIZurbanizowane','gruntyRolne'] to compare developed vs farmland."New value: +"Land-use category, multi-select, case-sensitive (gruntyZabudowaneIZurbanizowane = built-up, gruntyRolne = agricultural, gruntyLesne = forest, terenyKomunikacyjne = transport); 'unknown' = none recorded (NULL), not 'no use'."Input schema / properties / marketType / descriptionPrevious 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."Input schema / properties / maxFootprintArea / descriptionPrevious value: -"Maximum building footprint (ground-plan) area in m², summed over all buildings of the transaction. Distinct from maxArea, which measures usable floor area (units) or land/parcel area. Set only where every linked building has footprint data, so this bound selects only measured rows — absence means 'not measured', not 'no building'."New value: +"Maximum building footprint in m², summed over the transaction's buildings; measured rows only (absence = 'not measured', not 'no building'). Not usable area."Input schema / properties / minFootprintArea / descriptionPrevious value: -"Minimum building footprint (ground-plan) area in m², summed over all buildings of the transaction. Distinct from minArea, which measures usable floor area (units) or land/parcel area. Set only where every linked building has footprint data, so this bound selects only measured rows — absence means 'not measured', not 'no building'."New value: +"Minimum building footprint in m², summed over the transaction's buildings; measured rows only (absence = 'not measured', not 'no building'). Not usable area."Input schema / properties / mpzpDesignation / descriptionPrevious value: -"MPZP zoning designation filter, exact token match (not prefix). Comma-separated = OR, e.g. 'MN,MW'. Use 'unknown' for rows with no designation recorded (NULL); distinct from the registry code 'brakMPZPLubWZ' (= 'no plan/WZ' recorded as data). Known codes: budownictwoMieszkanioweJednorodzinne, brakMPZPLubWZ, terenRolniczy, innyNiewymieniony, terenZabudowyUslugowej, terenDrogWewnetrznych, terenDrogPublicznych, terenZabudowyZagrodowejGospodarstwRolnych, budownictwoMieszkanioweWielorodzinne, las, terenObiektowProdukcyjnychSkladowIMagazynow, terenSportuIRekreacji, decyzjaWarunkiZabudowy, terenZieleniUrzadzonej, terenZieleniObjetyFormaOchronyPrzyrody, terenWodPowierzchniowychSrodladowych, obszarITerenGorniczy, terenObslugiProdukcjiWGospodarstwachRolnych, terenInfrastrukturyTechnicznej, terenOgrodowDzialkowych, terenRozmieszczeniaDuzcychObiektowHandlowych, cmentarz, terenKomunikacjiWodnejSzlakWodny, terenWodPowierzchniowychMorskich, MN, BP, KD, U, INN, MW, KDW, R, ZP, P, WZ, ZN, WS, UC, ZL, ZD, US, TIT. An unrecognised value is still sent but adds a warning to the reply."New value: +"MPZP zoning designation, exact token match; comma-separated = OR; 'unknown' = none recorded. Same codes as search_transactions mpzpDesignation."Input schema / properties / ownershipType / descriptionPrevious 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."Input schema / properties / polygon / descriptionPrevious value: -"GeoJSON Polygon geometry. Coordinates: [longitude, latitude] pairs. First and last point must be identical. Max 500 vertices total."New value: +"GeoJSON Polygon: [longitude, latitude] pairs, first and last point identical, max 500 vertices total."Input schema / properties / rooms / descriptionPrevious 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."Input schema / properties / transactionType / descriptionPrevious 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."Input schema / properties / unitFunction / descriptionPrevious 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'."search_parcels1 field changedInput schema / properties / q / descriptionPrevious value: -"Parcel ID prefix to search for (min 3 chars). E.g. '146518_8.01'"New value: +"Parcel ID prefix (min 3 chars), e.g. '146518_8.01'"search_transactions21 fields changedInput schema / properties / buildingNumber / descriptionPrevious value: -"Building/house number (e.g. '30', '12A'). Requires location or street to be set."New value: +"Building/house number (e.g. '30', '12A'). Requires location or street."Input schema / properties / buildingStoreys / descriptionPrevious value: -"Number of above-ground storeys of the building. Multi-select buckets: exact non-negative integers (e.g. '1','2'), 'Nplus' e.g. '3plus' = 3 or more, 'unknown' = no storey count recorded (NULL). Recorded ONLY for single-building transactions, so 'unknown' covers BOTH a deed with several buildings (no single storey count exists) and a single building with missing data — never read it as 'a building with no storeys'. This is NOT the floor of a unit (see floor). Without 'unknown', rows with no storey count are excluded."New value: +"Above-ground storeys, multi-select: integers, 'Nplus' ('3plus' = 3+), 'unknown' (no count). Single-building deeds only, so 'unknown' also covers multi-building deeds. Not the unit floor; rows with no count drop out unless 'unknown' is listed."Input schema / properties / buildingType / descriptionPrevious 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."Input schema / properties / excludeFractionalShares / descriptionPrevious value: -"Set true to analyze clean land prices: excludes fractional ownership shares, whose price reflects the whole deed rather than the share and skews a per-m² comparison. Default false."New value: +"true = clean land prices: drops fractional ownership shares, whose price reflects the whole deed. Default false."Input schema / properties / floodRisk / descriptionPrevious value: -"Flood-hazard filter. high = most frequent flooding (~1-in-10-year), medium (~1-in-100-year), low = rarest (~1-in-500-year). Selects ONLY transactions whose land sits in a mapped flood zone; absence of a zone is never asserted as 'safe'. Multi-select; e.g. ['medium','high'] = at least medium risk."New value: +"Flood-hazard zone, multi-select: high ~1-in-10-year, medium ~1-in-100, low ~1-in-500. Mapped zones only; absence of a zone is never 'safe'."Input schema / properties / floor / descriptionPrevious 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."Input schema / properties / heritageStatus / descriptionPrevious value: -"Heritage-listing filter. listed = a protected monument on/at the property's land; zone = the land lies within a protected urban layout or the designated surroundings of a monument. Selects ONLY transactions where a listing was detected; absence of a detection is never asserted as 'not listed'. Multi-select; e.g. ['listed'] = individually listed properties only."New value: +"Heritage listing, multi-select: listed = protected monument on the land; zone = protected urban layout or monument surroundings. Detected listings only; absence of a detection is never 'not listed'."Input schema / properties / landUse / descriptionPrevious value: -"Recorded land-use category of the transaction's land. Multi-select from: gruntyZabudowaneIZurbanizowane (built-up and urbanised), gruntyRolne (agricultural), gruntyLesne (forest), terenyKomunikacyjne (transport), inne (other). 'unknown' = no category recorded for the land (NULL) — a legitimate bucket, never a claim that the land has no use. Values are case-sensitive. E.g. ['gruntyRolne'] for farmland, or ['gruntyZabudowaneIZurbanizowane','gruntyRolne'] to compare developed vs farmland."New value: +"Land-use category, multi-select, case-sensitive (gruntyZabudowaneIZurbanizowane = built-up, gruntyRolne = agricultural, gruntyLesne = forest, terenyKomunikacyjne = transport); 'unknown' = none recorded (NULL), not 'no use'."Input schema / properties / landslideRisk / descriptionPrevious value: -"Landslide-hazard filter, from official landslide-hazard maps (1:10,000 scale). 'landslide' = the land intersects a mapped landslide area; 'threatened' = an area threatened by mass movements. Selects ONLY transactions whose land intersects a mapped hazard area — an intersection means overlap with a mapped area, not that the parcel itself is a landslide; absence of a zone is never asserted as 'safe'. Multi-select; e.g. ['landslide','threatened'] = any mapped hazard."New value: +"Landslide hazard, multi-select: landslide = mapped landslide area; threatened = area threatened by mass movements. Mapped areas only; absence of a zone is never 'safe'."Input schema / properties / location / descriptionPrevious value: -"Location name - city (e.g. 'Warszawa', 'Kraków', 'Gdańsk') or district (e.g. 'Mokotów', 'Kraków-Podgórze'). 'Warszawa', 'Kraków', 'Łódź' auto-expand to all sub-districts. Prefer teryt= for exact matches; call list_locations(search=...) to confirm a name is valid here — it flags valid ones as rcn_district. A name with no match comes back with 'Did you mean' suggestions."New value: +"City (e.g. 'Warszawa') or RCN district (e.g. 'Mokotów', 'Kraków-Podgórze'); 'Warszawa', 'Kraków', 'Łódź' expand to all sub-districts. Prefer teryt=; confirm a name with list_locations(search=...) (valid ones are flagged rcn_district)."Input schema / properties / marketType / descriptionPrevious value: -"Market type: primary (developer) or secondary (resale). ~55% of records have unknown market type and will be excluded when this filter is used."New value: +"primary (developer) or secondary (resale); the ~55% of records with no market type drop out when this is set."Input schema / properties / maxFootprintArea / descriptionPrevious value: -"Maximum building footprint (ground-plan) area in m², summed over all buildings of the transaction. Distinct from maxArea, which measures usable floor area (units) or land/parcel area. Set only where every linked building has footprint data, so this bound selects only measured rows — absence means 'not measured', not 'no building'."New value: +"Maximum building footprint in m², summed over the transaction's buildings; measured rows only (absence = 'not measured', not 'no building'). Not usable area."Input schema / properties / minFootprintArea / descriptionPrevious value: -"Minimum building footprint (ground-plan) area in m², summed over all buildings of the transaction. Distinct from minArea, which measures usable floor area (units) or land/parcel area. Set only where every linked building has footprint data, so this bound selects only measured rows — absence means 'not measured', not 'no building'."New value: +"Minimum building footprint in m², summed over the transaction's buildings; measured rows only (absence = 'not measured', not 'no building'). Not usable area."Input schema / properties / mpzpDesignation / descriptionPrevious value: -"MPZP zoning designation filter, exact token match (not prefix). Comma-separated = OR, e.g. 'MN,MW'. Use 'unknown' for rows with no designation recorded (NULL); distinct from the registry code 'brakMPZPLubWZ' (= 'no plan/WZ' recorded as data). Known codes: budownictwoMieszkanioweJednorodzinne, brakMPZPLubWZ, terenRolniczy, innyNiewymieniony, terenZabudowyUslugowej, terenDrogWewnetrznych, terenDrogPublicznych, terenZabudowyZagrodowejGospodarstwRolnych, budownictwoMieszkanioweWielorodzinne, las, terenObiektowProdukcyjnychSkladowIMagazynow, terenSportuIRekreacji, decyzjaWarunkiZabudowy, terenZieleniUrzadzonej, terenZieleniObjetyFormaOchronyPrzyrody, terenWodPowierzchniowychSrodladowych, obszarITerenGorniczy, terenObslugiProdukcjiWGospodarstwachRolnych, terenInfrastrukturyTechnicznej, terenOgrodowDzialkowych, terenRozmieszczeniaDuzcychObiektowHandlowych, cmentarz, terenKomunikacjiWodnejSzlakWodny, terenWodPowierzchniowychMorskich, MN, BP, KD, U, INN, MW, KDW, R, ZP, P, WZ, ZN, WS, UC, ZL, ZD, US, TIT. An unrecognised value is still sent but adds a warning to the reply."New value: +"MPZP zoning designation, exact token match; comma-separated = OR (e.g. 'MN,MW'). 'unknown' = none recorded (NULL), distinct from the code 'brakMPZPLubWZ' (no plan/WZ). Known codes: budownictwoMieszkanioweJednorodzinne, brakMPZPLubWZ, terenRolniczy, innyNiewymieniony, terenZabudowyUslugowej, terenDrogWewnetrznych, terenDrogPublicznych, terenZabudowyZagrodowejGospodarstwRolnych, budownictwoMieszkanioweWielorodzinne, las, terenObiektowProdukcyjnychSkladowIMagazynow, terenSportuIRekreacji, decyzjaWarunkiZabudowy, terenZieleniUrzadzonej, terenZieleniObjetyFormaOchronyPrzyrody, terenWodPowierzchniowychSrodladowych, obszarITerenGorniczy, terenObslugiProdukcjiWGospodarstwachRolnych, terenInfrastrukturyTechnicznej, terenOgrodowDzialkowych, terenRozmieszczeniaDuzcychObiektowHandlowych, cmentarz, terenKomunikacjiWodnejSzlakWodny, terenWodPowierzchniowychMorskich, MN, BP, KD, U, INN, MW, KDW, R, ZP, P, WZ, ZN, WS, UC, ZL, ZD, US, TIT. An unrecognised value is still sent, with a warning."Input schema / properties / ownershipType / descriptionPrevious 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."Input schema / properties / parcelId / descriptionPrevious value: -"Exact parcel ID as returned in search results (e.g. '146518_8.0108.27'). Must match exactly - copy from a previous search result's parcel_id field."New value: +"Exact parcel ID, copied from a search result's parcel_id field (e.g. '146518_8.0108.27')."Input schema / properties / rooms / descriptionPrevious 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."Input schema / properties / street / descriptionPrevious value: -"Street name filter, matched anywhere inside the name (e.g. 'Puławska', 'Aleja Waszyngtona'). Give it in the NOMINATIVE and with its Polish diacritics — matching is literal, so 'Karmelickiej' does not find 'Karmelicka' and 'Marszalkowska' does not find 'Marszałkowska'. Either mistake answers with nothing, which reads exactly like 'no such transactions'."New value: +"Street name, matched anywhere inside the name. Give the NOMINATIVE with Polish diacritics - matching is literal ('Karmelickiej' does not find 'Karmelicka'); a miss looks exactly like 'no such transactions'."Input schema / properties / teryt / descriptionPrevious value: -"TERYT administrative code(s) for precise area filtering. Comma-separated, max 10. 2-digit (voivodeship), 4-digit (county), 6-digit (municipality), or full precinct code (e.g. '321705_2.0054'). Use list_locations to find codes. More precise than 'location' - avoids name ambiguity."New value: +"TERYT code(s), comma-separated, max 10: 2-digit (voivodeship), 4 (county), 6 (municipality) or a precinct code (e.g. '321705_2.0054'). Find codes with list_locations. Exact - avoids name ambiguity."Input schema / properties / transactionType / descriptionPrevious value: -"Transaction type filter. For market analysis, ALWAYS specify transactionType to exclude non-market transactions (subsidized, foreclosure, public purpose). ~2% of transactions have unknown type (NULL) and are excluded when this filter is used unless 'unknown' is included."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."Input schema / properties / unitFunction / descriptionPrevious 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'."
Add one secure layer between your agents and this server.