Skip to main content
Glama
Sign In

Cenogram - Polish Real Estate Data

by pl.cenogram.mcp
OverviewDiscussionsAdmin

get_parcel_report

Read-only

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.

Input Schema

NameRequiredDescriptionDefault
presetNo"zoning": planning sections only (11 tokens).
parcelIdYesCadastral id ('142907_2.0014.342/5' or '-' form) or internal UUID.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / parcelId / description
      Previous 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."
  2. Changed1 schema field changed
    • addedInput schema / properties / preset
      Added value: +{
+  "description": "\"zoning\": planning sections only (11 tokens).",
+  "enum": [
+    "full",
+    "zoning"
+  ],
+  "type": "string"
+}
  3. Changed1 schema field changed
    • changedInput schema / properties / parcelId / description
      Previous 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."
  4. Added

TDQS

A4.8/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; 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.

Purpose5/5

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.

Usage Guidelines5/5

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.

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