Skip to main content
Glama

Cenogram - Polish Real Estate Data

by pl.cenogram.mcp
OverviewDiscussionsAdmin

list_locations

Read-only

Browse locations in two modes:

  1. TERYT hierarchy (parent param): Navigate voivodeship → county → municipality → precinct. Returns TERYT codes for use in search_transactions(teryt=...).

    • No parent: 16 voivodeships (2-digit codes)

    • 2-digit: counties (4-digit), 4-digit: municipalities (6-digit), 6-digit: precincts

  2. Name search (search param): Look up a place by name across all levels (voivodeship, county, municipality, precinct). Each match comes with its TERYT code, its parent unit, and the exact follow-up calls to make — use teryt= for precise administrative filtering. Rows also flagged as RCN districts additionally accept the name in search_transactions(location=)/compare_locations. RCN district names that have no TERYT code are listed separately. If both provided, parent takes precedence. Returns administrative units — never streets. A street is not a level of this hierarchy and has no code of its own; to search for parcels on one, pass the name straight to list_parcels_in_area as street=. Use 'location' for quick city searches, 'teryt' for precise administrative filtering (avoids name ambiguity, e.g. 'Wałcz' is both a county and a municipality).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
parentNoTERYT parent code to browse children. 2-digit (voivodeship → counties), 4-digit (county → municipalities), 6-digit (municipality → precincts). Omit for all voivodeships.
searchNoLook 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / search / description
      Previous value: -"Filter locations by name (case-insensitive partial match, e.g. 'Krak' for Kraków districts). Ignored when parent is set."New 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."
  2. Changed3 schema fields changed
    • addedInput schema / properties / parent
      Added value: +{
+  "description": "TERYT parent code to browse children. 2-digit (voivodeship → counties), 4-digit (county → municipalities), 6-digit (municipality → precincts). Omit for all voivodeships.",
+  "minLength": 1,
+  "type": "string"
+}
    • changedInput schema / properties / search / description
      Previous value: -"Filter locations by name (case-insensitive partial match, e.g. 'Krak' for Kraków districts)"New value: +"Filter locations by name (case-insensitive partial match, e.g. 'Krak' for Kraków districts). Ignored when parent is set."
    • addedInput schema / properties / search / minLength
      Added value: +1
  3. Changed3 schema fields changed
    • removedInput schema / properties / parent
      Removed value: -{
-  "description": "TERYT parent code to browse children. 2-digit (voivodeship → counties), 4-digit (county → municipalities), 6-digit (municipality → precincts). Omit for all voivodeships.",
-  "minLength": 1,
-  "type": "string"
-}
    • changedInput schema / properties / search / description
      Previous value: -"Filter locations by name (case-insensitive partial match, e.g. 'Krak' for Kraków districts). Ignored when parent is set."New value: +"Filter locations by name (case-insensitive partial match, e.g. 'Krak' for Kraków districts)"
    • removedInput schema / properties / search / minLength
      Removed value: -1
  4. Changed3 schema fields changed
    • addedInput schema / properties / parent
      Added value: +{
+  "description": "TERYT parent code to browse children. 2-digit (voivodeship → counties), 4-digit (county → municipalities), 6-digit (municipality → precincts). Omit for all voivodeships.",
+  "minLength": 1,
+  "type": "string"
+}
    • changedInput schema / properties / search / description
      Previous value: -"Filter locations by name (case-insensitive partial match, e.g. 'Krak' for Kraków districts)"New value: +"Filter locations by name (case-insensitive partial match, e.g. 'Krak' for Kraków districts). Ignored when parent is set."
    • addedInput schema / properties / search / minLength
      Added value: +1
  5. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds behavioral details beyond annotations: two modes, precedence rules, that it returns administrative units only, RCN district handling, and the output (TERYT codes, parent unit, follow-up calls). It doesn't mention errors or rate limits, but for a read-only tool the added context is substantial.

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 longer than average but well-structured with numbered modes and clear separation. Every sentence adds value, such as the street clarification and the note on RCN districts. It front-loads the two modes and prioritizes key behavior. A slight trim could be made, but it remains efficient for the complexity.

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?

Given the tool's complexity (hierarchy, two modes, output usage), the description is complete. It explains what the tool returns (TERYT codes, parent, follow-up calls), what it does not (streets), and how results feed into other tools. With no output schema, the description covers return semantics adequately, leaving no critical gaps for an agent to call it correctly.

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% with detailed parameter descriptions (parent code lengths, search case-insensitivity). The description reinforces and extends this: explains precedence when both are provided, provides concrete examples (e.g., 'Wałcz'), and links parameters to usage outcomes. This adds value beyond the schema's literal definitions.

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 description clearly states the tool's purpose: browsing locations via TERYT hierarchy or name search, returning TERYT codes for use in other tools. It distinguishes itself from sibling location tools by focusing on administrative units and explicitly stating it never returns streets. The verb 'browse' and resource 'locations' are specific, and it differentiates from list_*_locations siblings by covering the general hierarchy.

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 provides explicit guidance on when to use each mode: 'Use location for quick city searches, teryt for precise administrative filtering' and explains parent precedence. It also names alternative tools and conditions, e.g., 'to search for parcels on a street, pass the name straight to list_parcels_in_area as street='. This leaves no ambiguity about selection.

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