Skip to main content
Glama
cenogram-mcp-server

cenogram-mcp-server

Official

list_parcels_in_area

Read-only

List cadastral parcels (land plots) in a chosen area via TERYT, location, bbox, circle, or polygon; optionally return outlines. Find land plots, not transactions or prices.

Instructions

List cadastral parcels in an area - the land plots themselves, NOT transactions (for deeds and prices use search_by_area or search_by_polygon). For an id prefix use search_parcels; 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 name shared by several units is an error listing the candidates, never a guess); bbox; lat + lng + radiusKm (a circle; not together with a bbox); polygon (on its own).

Two answer shapes, priced differently: 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 polygon per parcel; 5 API tokens; max 100 parcels, 50 by default; no paging). An outline answer marked TRUNCATED 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 count as naming the area. minArea / maxArea (m²) = the registered parcel surface.

  • street: whole-word, case- and accent-insensitive ('Górna' does not find 'Podgórna'; a fragment finds nothing). Not inflected: 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 with the precinct name and 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 has two gaps. (1) The cadastral data we hold is near-complete but not live (measured per county; fresh splits, merges or renumbering may be missing), for EVERY entrance: a short list or no truncation marker never means you have every parcel. Each answer has a corpus_coverage block (figures for teryt/location, null for bbox/circle/polygon). (2) bbox, circle and polygon miss the few held parcels whose outline is in 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. Limits: an area over 500 km², a radius over 12.6 km or a polygon over 500 vertices is refused.

Input Schema

NameRequiredDescriptionDefault
latNoCircle centre latitude (WGS84). Needs lng and radiusKm.
lngNoCircle centre longitude (WGS84). Needs lat and radiusKm.
bboxNoBounding box "minLng,minLat,maxLng,maxLat" (WGS84), at most 500 km². Required for includeGeometry=true.
limitNoMax parcels. Light list: up to 1000, default 250. Outlines: up to 100, default 50.
terytNoTERYT code prefix (2/4/6 digits or finer), comma-separated for several. Wins over location.
cursorNoOpaque cursor from the previous light-list answer, for the next page; pass it back unchanged. Not available on outline calls.
streetNoStreet 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.
maxAreaNoMaximum parcel surface in m². Same scope requirement as minArea.
minAreaNoMinimum parcel surface in m². Needs a narrow scope; not with includeGeometry or a polygon.
polygonNoGeoJSON Polygon: [longitude, latitude] pairs, first and last point identical, max 500 vertices. Always returns outlines. Pass it instead of the other area parameters.
locationNoCounty, 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).
radiusKmNoCircle radius in km (max 12.6, the radius covering 500 km²). Needs lat and lng.
buildingNumberNoBuilding number, exact; needs street, same scope requirement. If nothing is found, drop the number and read the numbers off the street's rows.
includeGeometryNoReturn full outlines instead of the light row (5 tokens instead of 2). Requires a bbox; with a polygon outlines come back anyway.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed13 schema fields changedv0.18.0
    • changedInput schema / properties / bbox / description
      Previous 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."
    • changedInput schema / properties / buildingNumber / description
      Previous 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."
    • changedInput schema / properties / cursor / description
      Previous 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."
    • changedInput schema / properties / includeGeometry / description
      Previous 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."
    • changedInput schema / properties / lat / description
      Previous value: -"Latitude of the circle centre (WGS84). Requires lng and radiusKm."New value: +"Circle centre latitude (WGS84). Needs lng and radiusKm."
    • changedInput schema / properties / limit / description
      Previous 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."
    • changedInput schema / properties / lng / description
      Previous value: -"Longitude of the circle centre (WGS84). Requires lat and radiusKm."New value: +"Circle centre longitude (WGS84). Needs lat and radiusKm."
    • changedInput schema / properties / location / description
      Previous value: -"County, city, 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. An ambiguous name is an error listing the candidates."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)."
    • changedInput schema / properties / minArea / description
      Previous 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."
    • changedInput schema / properties / polygon / description
      Previous 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."
    • changedInput schema / properties / radiusKm / description
      Previous 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."
    • changedInput schema / properties / street / description
      Previous 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."
    • changedInput schema / properties / teryt / description
      Previous 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."
  2. Addedv0.12.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare a safe read; the description goes far beyond them with token pricing (2 vs 5 API tokens), cursor paging only on light lists, the 500 km² / 12.6 km / 500-vertex refusal limits, free empty pages, TRUNCATED outlines being an arbitrary subset, and two explicitly enumerated coverage gaps. It also discloses an account-dependent behavior (parcel_id only for token/OAuth and paid/trial callers), which no annotation covers.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

It is front-loaded and well-sectioned: purpose and sibling routing first, then entrance, then answer shapes, then filter rules, then coverage and limits. It is nonetheless very dense and some clauses duplicate the schema, so trimming would help, but almost every sentence carries decision-relevant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema and 14 loosely typed parameters, yet the description names both answer shapes and their fields, explains truncation, paging, token cost, coverage caveats and hard limits. An agent has everything it needs to call this correctly and to interpret a short or empty result without false conclusions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so the baseline is 3; the description still adds real semantics the schema lacks — street must be nominative and whole-word, buildingNumber must be exact and compound numbers ('84/92') will not match '84', empty pages carry close-name suggestions, and minArea/maxArea mean the registered parcel surface. Some content (radius max, teryt precedence, limit defaults) merely restates the schema, keeping it below a 5.

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

Purpose5/5

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

The first sentence states a concrete verb and resource ('List cadastral parcels') and immediately disambiguates from transactions. It then names four sibling tools (search_parcels, resolve_parcel, search_by_area/search_by_polygon, get_parcel_report) with the condition that selects each, so an agent can route without opening any schema.

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

Usage Guidelines5/5

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

Explicit when-to-use and when-not-to-use guidance is given for the sibling tools, for the entrance (street address vs precinct + number vs id prefix), and for the output mode (light list vs outlines). It also states exclusions directly, e.g. 'not together with a bbox', 'not on outline calls', and 'outside towns use resolve_parcel'.

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