Skip to main content
Glama
kamilkaczmareksolutions

Polish MCP Servers

by kamilkaczmareksolutions
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Poland Apartment Prices API – Developer Price Lists dane.gov.pl

polish-developer-apartment-prices
Read-onlyIdempotent

Query new-build apartment and house offers and price changes from Polish developer price lists on dane.gov.pl, filtered by city, developer, voivodeship, type, availability, and publication date.

Instructions

Returns new-build apartment and house offers from the developer price lists published on dane.gov.pl under the price transparency rules (jawność cen): one record per unit with price, price per m² and location, or, in priceChanges mode, only the differences from the developer's previous list. Filter by publication window (lastDays, or a date range of at most 14 days), voivodeship, city, developer, property type and availability. Use it for primary-market housing prices from developers; no sibling tool covers real estate. Read-only: it only queries the public source and never writes to the registry; onlyNew merely keeps a stateKey memory in your own Apify account. Each call needs the APIFY_TOKEN env var and starts one paid run of the Apify Actor enterprising_hamster/polish-developer-apartment-prices on your Apify account, billed pay-per-event per delivered record (price changes cost more) plus any Apify platform usage; the server waits up to 300 s for the run and returns JSON {items, truncated} with at most maxItems (max 100) items and 256 KiB.

Input Schema

NameRequiredDescriptionDefault
modeNoOffers returns each unit of the newest price list of every developer dataset published in the period. Price changes compares that list with the developer's previous one and returns only differences.offers
citiesNoKeep units whose city (miejscowość) or municipality (gmina) is one of these, e.g. Warszawa, Kraków. Case and Polish letters do not matter.
dateToNoLast publication date, inclusive, YYYY-MM-DD, Polish time.
onlyNewNoSkip price lists this Actor already delivered in an earlier run with the same state key. Use with a daily schedule.
dateFromNoFirst publication date, YYYY-MM-DD, Polish time. At most 14 days with dateTo.
lastDaysNoPrice lists published on dane.gov.pl in the last N×24 hours. Ignored when a date is set below. Developers republish lists daily, so 1 day already covers most active investments.
maxItemsNoStop after this many records. Each record is one charged event.
stateKeyNoSeparate memory for onlyNew, e.g. one key per schedule. Letters, digits, _ and -.
developersNoKeep units whose developer name, price-list title or investment name contains one of these fragments, e.g. Dom Development, Murapol.
voivodeshipsNoKeep units in these voivodeships (województwa). Units whose list gives no voivodeship are dropped by this filter.
maxPriceListsNoRead at most this many developer price lists, newest first. 0 means all.
onlyAvailableNoDrop units marked sold or reserved. Most lists do not state availability; those units are kept.
propertyTypesNoParking spaces, storage and commercial units are never returned as units; they appear as add-ons of a unit. Units whose type the list does not state are kept.
maxConcurrencyNoPrice lists read at the same time.
maxRequestsPerSecondNoPoliteness limit for file downloads. The dane.gov.pl API itself is always queried at 2 requests per second.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses the required APIFY_TOKEN env var, that each call starts one paid Apify Actor run billed pay-per-event (price changes cost more), the 300 s wait cap, and the {items, truncated} return with 100-item / 256 KiB limits. It also clarifies that onlyNew only writes a stateKey memory in the caller's own account, consistent with readOnlyHint/idempotentHint rather than contradicting them.

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?

Front-loads what is returned and the mode distinction, then packs filters, cost, auth and output contract into a dense block. It is a single long paragraph, which makes the billing/auth details harder to scan, but nearly every clause carries information an agent needs.

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 15-parameter tool with no output schema, the description supplies the missing contract ({items, truncated}, size and item caps) plus cost, auth and rate/timeout expectations. Nothing material an agent needs to call it safely is absent.

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, but the description adds real meaning beyond it: the 14-day maximum date window, the lastDays default covers most active investments, maxItems capped at 100, and the voivodeship/availability filter drop behavior. It stops short of explaining mode interaction with the filters in depth.

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 specific verb and resource (returns new-build apartment/house offers from developer price lists on dane.gov.pl), names the two modes, and explicitly positions itself against siblings with 'no sibling tool covers real estate'. An agent can distinguish it from every listed sibling without opening the schema.

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 concrete usage context: primary-market developer prices, priceChanges mode for deltas versus previous lists, and onlyNew tied to a daily schedule. It lacks an explicit 'do not use this for X' exclusion (e.g. secondary-market or rental data), so it stops short of full when-not guidance.

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

Deploy Server

Other Tools