deweloperuch-mcp

Budynek z transakcjami

get_building

Read-only

Fetches a building's actual sale transaction prices from Poland's RCN registry: address, units, dates, prices per m² and market type, plus an optional neighborhood price trend.

Instructions

Zwraca budynek z rejestru cen transakcyjnych (RCN): adres, miasto, współrzędne, średnie ceny podane przez serwis i lokale (mieszkania) z ich transakcjami: datą, ceną, ceną za m², rynkiem (pierwotny albo wtórny), rodzajem transakcji i stronami. To ceny, za które lokale sprzedano, a nie ceny ofertowe deweloperów. building_slug to ostatni człon adresu strony budynku z cenami transakcyjnymi na deweloperuch.pl, np. 23-marca-79c-sopot albo aleja-krakowska-279-warszawa; gdy go nie znasz, poproś użytkownika o link do tej strony. building_url to ta strona: podawaj ją użytkownikowi jako link. Kolejność: lokale od tego z najnowszą transakcją, transakcje każdego lokalu od najstarszej.

Ograniczenia: tylko budynki z mieszkaniami, nie domy. Zwraca najwyżej limit lokali (domyślnie 10); units_returned mówi, ile ich jest na liście, truncated i units_omitted, czy i ile pominięto, a units_total i transactions_total liczą cały budynek. Najnowsze miesiące bywają niepełne, bo rejestr spływa z opóźnieniem. include_trend=true dodaje średnią cenę za m² transakcji w okolicy budynku (promień radius_km) w ostatnich 12 kwartałach; to jedno zapytanie do serwisu więcej.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Najwięcej lokali w wyniku (tych z najnowszymi transakcjami), domyślnie 10, najwyżej 50; 0 = tylko podsumowanie budynku. Ile pominięto, mówi units_omitted. Wynik ma ok. 200 znaków na transakcję; lokal może mieć kilka transakcji, więc zwykle wystarcza domyślny limit.
`building_slug`	Yes	Slug budynku, np. 23-marca-79c-sopot, ze strony budynku albo z comparables w estimate_property_value.
`include_trend`	No	true: dołącz średnią cenę za m² transakcji w okolicy budynku w ostatnich 12 kwartałach (jedno zapytanie więcej).

Output Schema

TableJSON Schema

Name	Required	Description
`lat`	No	Współrzędne budynku (WGS84).
`lng`	No	Współrzędne budynku (WGS84).
`city`	Yes	Miasto budynku.
`name`	Yes	Adres budynku wg rejestru cen.
`units`	Yes	Lokale od tego z najnowszą transakcją.
`street`	No	Ulica, tylko gdy inna niż name.
`avg_price`	No	Średnia cena transakcyjna lokalu w PLN, podana przez serwis.
`city_slug`	Yes	city_slug jak w search_locations.
`truncated`	Yes	true: lista units jest niepełna (units_omitted > 0).
`avg_area_m2`	No	Średnia powierzchnia lokalu w m², podana przez serwis.
`units_total`	Yes	Wszystkie lokale budynku w rejestrze cen.
`building_url`	No	Strona budynku z cenami transakcyjnymi na deweloperuch.pl: podaj ją użytkownikowi jako link.
`building_slug`	Yes	Identyfikator do ponownego get_building.
`units_omitted`	Yes	Lokali pominiętych przez limit.
`units_returned`	Yes	Lokali na liście units.
`avg_price_per_m2`	No	Średnia cena za m² w PLN, podana przez serwis.
`transactions_total`	Yes	Wszystkie transakcje lokali budynku.
`neighbourhood_trend`	No	Średnia cena za m² transakcji w okolicy budynku w kolejnych kwartałach; tylko przy include_trend=true.
`last_transaction_date`	No	Data najnowszej transakcji w budynku.
`first_transaction_date`	No	Data najstarszej transakcji w budynku.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.3Oct 16, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations only declare readOnlyHint and openWorldHint, and the description adds real behavior beyond them: it restricts scope to apartments not houses, explains the pagination summary fields, warns that recent months may be incomplete due to registry lag, and notes include_trend costs an extra service query. Some of this describes return values already covered by the output schema, which slightly lowers the gain.

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 the returned data, then the slug explanation, ordering, and constraints; every sentence carries information. It is somewhat long and repeats the limit parameter details already present in the schema, costing it a point.

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 lookup tool with an output schema, the description covers what an agent needs: data scope, ordering rules, truncation semantics, data-freshness caveats, the cost of the optional trend, and how to interpret/present building_url. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all three parameters fully. The description adds the origin of building_slug (last segment of the deweloperuch.pl building URL, with examples) and reinforces that building_url should be shown to the user, but largely mirrors schema content. Baseline 3 applies when the schema does the heavy lifting.

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 ('Zwraca budynek z rejestru cen transakcyjnych (RCN)') and enumerates the returned fields (adres, miasto, współrzędne, lokale z transakcjami). It distinguishes the data source from siblings by clarifying these are sale prices, not developer offer prices.

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

Usage Guidelines3/5

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

It gives clear conditional guidance on obtaining the slug ('gdy go nie znasz, poproś użytkownika o link') and where to source it (estimate_property_value comparables), which is useful. However, it never explicitly says when to choose this tool over siblings like get_transaction_statistics or search_offers, leaving tool-level selection implied.

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

Deploy Server