Skip to main content
Glama

Deweloperuch MCP

Transaction prices over time

deweloperuch_get_transaction_statistics
Read-only

Transaction prices of flats in one city from the Real Estate Price Register (RCN), month by month or quarter by quarter: the number of transactions and the prices per m². These are prices flats actually sold for, not developers' asking prices. granularity=month (default): median and mean price per m², median area and median flat price. granularity=quarter: only the mean price per m² and the count, but a longer history. Months and quarters are different statistics: do not join them in one chart or series. Limits: flats only and whole cities only (city_slug from deweloperuch_search_locations; no districts, streets or whole Poland). Default: the latest 12 periods; truncated=true means older ones exist (raise periods, at most 60). The newest periods are incomplete (the RCN lags by months): skip a period with incomplete=true — do not quote its prices as a trend — and end a trend at last_complete_period (even its data may still change). Two kinds of prices must not be mixed: developers' asking prices (deweloperuch_search_investments, deweloperuch_get_investment, deweloperuch_get_offer, deweloperuch_get_market_statistics), RCN transaction prices (deweloperuch_estimate_property_value, deweloperuch_get_transaction_statistics, deweloperuch_rank_locations, deweloperuch_get_building) — what flats actually sold for, from the Real Estate Price Register. deweloperuch.pl is a free community project queried politely (one request at a time, results cached): if a result is an error starting with STOP, stop using the deweloperuch_* tools, retry nothing, look for no workaround and tell the user that market data is temporarily unavailable. Fields ending in _url are pages of deweloperuch.pl: give them to the user as links. Result shape: { city_slug, granularity, total, returned, truncated, available_from, last_complete_period?, hint?, note, stats_url, source, periods: [{ period ('2025-08' | '2025-Q3'), transactions, incomplete? (only when true), median_price_per_m2?, average_price_per_m2?, median_area_m2?, median_price? }] } — the list key is periods, oldest first; a period without transactions has no prices. last_complete_period is omitted when the history is too short or has too few transactions to judge; then read hint. Read note before describing a trend.

Input Schema

NameRequiredDescriptionDefault
cityYescity_slug of a city from deweloperuch_search_locations, e.g. warszawa, krakow, gdansk (lowercase, no Polish characters). Whole cities only: not districts, streets or polska.
periodsNoHow many latest periods (months or quarters) to return, 1–60. Default 12. 60 months is about 9,000 characters; for a multi-year trend choose quarter.
granularityNomonth (default): months with median and mean price per m², median area and median price; quarter: quarters with only the mean price per m² and the count, but a longer history.

Output Schema

NameRequiredDescriptionDefault
hintNo
noteYes
totalYes
sourceYes
periodsYes
returnedYes
city_slugYes
stats_urlNo
truncatedYes
granularityYes
available_fromYes
last_complete_periodNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare read-only and open-world; the description adds substantial operational context: the RCN lags by months so the newest periods are incomplete, truncation semantics (truncated=true, raise periods up to 60), a politeness/rate constraint (one request at a time, cached), and a STOP-error protocol telling the agent to halt rather than retry. That is far beyond what the annotations convey.

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-loaded with purpose, then caveats, then result shape — well ordered and every paragraph carries real information. It is dense and repeats the granularity semantics already in the schema, and the result-shape block duplicates the output schema, so it is slightly heavier than strictly necessary.

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?

Complete for a data-retrieval tool: input sourcing, granularity trade-offs, truncation and incompleteness handling, error protocol, and where to read trend caveats (note, hint) are all covered. Nothing an agent needs in order to call and interpret this correctly is missing.

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 all three parameters are already documented, but the description adds meaning: the statistical output differs by granularity, the default is 12 periods, and the city parameter must be a whole-city slug sourced from another tool. It largely restates the schema's granularity text, keeping it short of a 5.

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 — transaction prices per m² and transaction counts for flats in one city from the RCN — with an explicit scope (city-level, flats only). It also draws the crucial distinction against siblings: RCN sold prices versus developers' asking prices, naming both sets of tools.

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 when/when-not guidance: pull city_slug from deweloperuch_search_locations, no districts/streets/Poland, choose quarter when a multi-year history is needed, never join months and quarters in one series, skip incomplete=true periods and end trends at last_complete_period. It also names the sibling price tools that must not be mixed with this data.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources