Skip to main content
Glama

Cenogram - Polish Real Estate Data

by pl.cenogram.mcp
OverviewDiscussionsAdmin

resolve_parcel

Read-only

Resolve a land parcel to its cadastral identity using exactly ONE of:

  • parcelId: a full cadastral id, either raw '/' form ('142907_2.0014.342/5') or URL-safe '-' form ('142907_2.0014.342-5'), or the internal UUID from search results.

  • q: a full cadastral id, a UUID, OR free-text 'locality name + parcel number' (e.g. 'Sabnie 342/5'). The name may be a gmina name or a cadastral precinct (obręb) name; matching is exact and case-insensitive, so an unusual spelling may miss. A precinct name is not unique nationwide, so an ambiguous name comes back as several candidates rather than a guess. This is NOT a street address: it is a locality name plus a PARCEL number, never a street name plus a building number. For a city address (street + building number) use list_parcels_in_area(street=, buildingNumber=) instead — resolve_parcel will not turn 'Marszałkowska 12' into a parcel.

  • lat & lng: a WGS84 point inside the parcel (returns the parcel(s) containing that point). Returns a list of matching parcels with district, area, and coordinates; 'truncated' when the name+number match was capped. When nothing matches, coverage is not_covered — and what that means depends on the mode. With a FULL cadastral id we confirm the parcel live and add it if it exists, so not_covered there really does mean we could not confirm one. With the DISCOVERY modes (locality name + number, or a coordinate) we only look at the register we hold — near-complete national coverage, though not the whole of it and not live — so not_covered means "not among the parcels we hold", which is a weaker statement, and a fresh change or an unusual spelling is a likelier cause than the parcel not existing. Never report it as "no such parcel". The corpus_coverage block in each answer says how much of the register was actually searched. When the lookup could not be completed at all — a live confirmation that failed, or a name carried by more precincts than one search covers and nothing found among them — coverage is not_computed instead: that is not a statement that the parcel does not exist. Matches found before such a search ran out are returned normally, with 'truncated'. Use this to turn an address point, a coordinate, or a locality+number into a concrete parcel id — then feed that id to search_transactions (parcelId) to see its sale history. Free: resolving a parcel costs no API tokens.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoFull 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.
latNoLatitude WGS84. Must be paired with lng. Mutually exclusive with q and parcelId.
lngNoLongitude WGS84. Must be paired with lat. Mutually exclusive with q and parcelId.
parcelIdNoFull cadastral id (slash or dash form) or internal UUID. Mutually exclusive with q and lat/lng.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / q / description
      Previous 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). Mutually exclusive with parcelId and lat/lng."New 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."
  2. Changed1 schema field changed
    • changedInput schema / properties / q / description
      Previous value: -"Full cadastral id, a UUID, or 'locality name + parcel number' (e.g. 'Sabnie 342/5'). Mutually exclusive with parcelId and lat/lng."New 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). Mutually exclusive with parcelId and lat/lng."
  3. Added

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already mark the tool read-only and non-destructive, and the description adds rich behavioral context beyond that: exact case-insensitive matching, ambiguous-name behavior, the not_covered vs not_computed distinction, truncation, corpus coverage, and the fact that it costs no tokens. This is exactly the kind of operational nuance an agent needs.

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?

The description is long, but the material is dense and genuinely relevant: matching semantics, coverage caveats, and mode differences. It is front-loaded with the core purpose and input modes. A little redundancy remains around the not_covered explanation and the street-address exclusion, so it is not maximally concise.

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?

Despite having no output schema, the description covers what a successful result looks like, truncated responses, coverage blocks, failure semantics, and how the tool fits into a larger workflow. For a tool with four optional parameters and no required ones, all essential selection and interpretation information is present.

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

Parameters5/5

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

Schema coverage is 100%, so the baseline is 3, but the description goes well beyond the schema: it explains the slash vs dash parcelId forms, that q accepts gmina or obręb names with exact case-insensitive matching, that lat/lng must be a point inside the parcel, and what each match mode returns. These are semantically important details not in the schema.

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 specific verb and resource: 'Resolve a land parcel to its cadastral identity', and the three input modes make the tool's job unambiguous. It also differentiates from siblings by explicitly routing street addresses to list_parcels_in_area and sale-history lookups to search_transactions.

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?

The description gives explicit when-to-use guidance ('Use this to turn an address point, a coordinate, or a locality+number into a concrete parcel id') and names the follow-up tool (search_transactions). It also states a clear exclusion: a city street address should go to list_parcels_in_area, not resolve_parcel.

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

All Cenogram - Polish Real Estate Data toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources