Skip to main content
Glama
cenogram-mcp-server

cenogram-mcp-server

Official

get_demographics

Read-only

Fetch local GUS BDL statistics for Polish locations by name or TERYT code, covering demographics, economy, housing, infrastructure and more, with optional year or time-series filters.

Instructions

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 (city, county or gmina name; a city or county resolves to county level) OR teryt (codes from list_locations). Neighborhoods/osiedla are NOT addressable. Returns the requested level PLUS all parent levels. Optional year, or yearFrom+yearTo for a time series, and category. Cost: 1 token.

Input Schema

NameRequiredDescriptionDefault
yearNoSingle year (2003-present); exclusive with yearFrom/yearTo. Omit for the latest year per indicator.
terytNoTERYT: 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.
yearToNoEnd year for a time series (max current year + 1).
categoryNoCategories to return; omit for all.
locationNoCity, 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.
yearFromNoStart year for a time series (min 2003).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.18.0
    • changedInput schema / properties / category / description
      Previous value: -"Filter to these categories. Omit to return all available."New value: +"Categories to return; omit for all."
    • changedInput schema / properties / location / description
      Previous value: -"City, county, or district name (e.g. 'Warszawa', 'Kraków'). A city/county name resolves to county/powiat level; 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. Use this OR teryt. For gmina-level data on other units pass a 6/7-digit teryt instead."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."
    • changedInput schema / properties / teryt / description
      Previous 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."
    • changedInput schema / properties / year / description
      Previous 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."
  2. Changed2 schema fields changedv0.12.0
    • changedInput schema / properties / location / description
      Previous value: -"City/county name, resolves to county/powiat level (e.g. 'Warszawa', 'Kraków'). Use this OR teryt. For gmina-level data pass a 6/7-digit teryt instead."New value: +"City, county, or district name (e.g. 'Warszawa', 'Kraków'). A city/county name resolves to county/powiat level; 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. Use this OR teryt. For gmina-level data on other units pass a 6/7-digit teryt instead."
    • changedInput schema / properties / teryt / description
      Previous value: -"TERYT code: 2-digit (voivodeship, e.g. 14), 4-digit (county, e.g. 1465), 6 or 7-digit (gmina, e.g. 1465011). Wins over location. Use list_locations to find codes."New 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."
  3. First observedv0.5.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations cover safety (readOnly, non-destructive), but the description adds real behavioral context: the return includes the requested level PLUS all parent levels, time-series vs. single-year semantics, the data source (GUS BDL), and an explicit cost of 1 token. This is precisely the kind of non-schema information an agent needs before calling.

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

Conciseness5/5

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

Front-loaded with what it returns and the coverage, then addressing rules, then return shape, then cost. No filler sentences; each adds a distinct, actionable fact.

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?

With no output schema, the description still explains the return shape (requested level plus parents), and all six optional parameters are covered by a fully documented schema. Nothing material is missing for correct invocation, including the budget cost.

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 explaining the location→level resolution rule and the neighborhood exclusion, which the schema only partially implies. However, precedence (teryt wins over location) and year vs. yearFrom/yearTo exclusivity are largely restated from the schema rather than adding new meaning.

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?

States a concrete verb+resource (local GUS BDL statistics for a Polish location) with scope quantified (~50 indicators, 11 named categories). The domain, source, and granularity make it unmistakable against siblings such as get_market_overview or the get_transaction_* tools, which cover market/transaction data rather than official local statistics.

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

Usage Guidelines4/5

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

Gives clear addressing rules: location by name OR teryt sourced from list_locations, with an explicit exclusion ('Neighborhoods/osiedla are NOT addressable') and resolution behavior (city/county → county level). It does not name an alternative sibling for cases where the agent wants market prices instead, so it stops short of the 5-level bar.

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