Skip to main content
Glama

Deweloperuch MCP

Building with transactions

deweloperuch_get_building
Read-only

A building of the Real Estate Price Register (RCN): address, coordinates, the site's average prices and the flats sold in it with the date, price, price per m², market, kind and parties of each transaction. These are the prices the flats sold for, not developers' asking prices. building_slug is the last part of the address of the building's page with transaction prices on deweloperuch.pl, e.g. 23-marca-79c-sopot — comparables of deweloperuch_estimate_property_value carry one in building_slug; when you have none, ask the user for the link of that page. building_url is that page. Order: the unit with the newest transaction first, each unit's transactions oldest first. Do not average transactions whose classification is not 'regular' (share, enforcement, discount…) with regular sales: they are not ordinary sales at a market price; non_regular_transactions counts them. Limits: buildings with flats only, not houses. Returns at most limit units (default 10); truncated and units_omitted say whether and how many were left out, units_total and transactions_total count the whole building. The newest months are often incomplete (the register lags). include_trend=true adds the mean price per m² of transactions around the building (radius radius_km) in the latest 12 quarters — one more request. Buyers and sellers appear only as a type, never by name. 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: { building_slug, name? (the address as the register writes it; absent when it gives none — the place is then in city), building_url, city, city_slug, street?, lat, lng, avg_price?, avg_area_m2?, avg_price_per_m2? (the site's averages; a value of 0 or less is omitted), first_transaction_date, last_transaction_date, units_total, transactions_total, non_regular_transactions? (e.g. { share: 1 }), units: [{ floor?, rooms?, area_m2, transactions: [{ date, price, price_per_m2, currency? (absent = PLN), market ('primary' | 'secondary'), classification ('regular' | 'share' | 'bulk' | 'government' | 'enforcement' | 'discount' | 'anomaly_low' | 'anomaly_high'), buyer, seller ('natural_person' | 'legal_person'), share? (only when a share was sold) }] }], units_returned, units_omitted, truncated, hint?, neighbourhood_trend?: { radius_km?, total, returned, truncated, quarters: [{ period, avg_price_per_m2?, transactions? }] }, source } — the list key is units.

Input Schema

NameRequiredDescriptionDefault
limitNoMost units in the result (those with the newest transactions), default 10, at most 50; 0 = only the building summary. About 200 characters per transaction.
building_slugYesBuilding slug, e.g. 23-marca-79c-sopot: lowercase letters without Polish characters, digits and hyphens, from the building's page address or from comparables in deweloperuch_estimate_property_value.
include_trendNotrue: add the mean price per m² of transactions around the building in the latest 12 quarters (one more request). Default false.

Output Schema

NameRequiredDescriptionDefault
latNo
lngNo
cityYes
hintNo
nameNo
unitsYes
sourceYes
streetNo
avg_priceNo
city_slugYes
truncatedYes
avg_area_m2No
units_totalYes
building_urlNo
building_slugYes
units_omittedYes
units_returnedYes
avg_price_per_m2No
transactions_totalYes
neighbourhood_trendNo
last_transaction_dateNo
first_transaction_dateNo
non_regular_transactionsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

With readOnlyHint and openWorldHint already set, the description adds substantial context: ordering rules, non-regular transaction exclusions, truncation behavior, incomplete register months, the extra request for include_trend, and STOP error handling. It also discloses that parties appear only as types, never names.

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

Conciseness3/5

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

The purpose and key warnings are front-loaded, but the description is very long and repeats the entire result shape even though an output schema exists. Much of the price-taxonomy and return-field detail could be shortened without losing invocation guidance.

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 complex, open-world read tool with an output schema, the definition covers limits, ordering, truncation, error handling, data caveats, and result interpretation. The remaining return-value details are also available in the output schema, so the description is operationally complete.

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 coverage is 100%, so the input fields are already fully documented. The description adds provenance for building_slug and truncation behavior for limit, but it also refers to a radius_km value that is not an input parameter in the schema, which may confuse an agent about how to set include_trend.

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 first sentence states the exact resource and contents: an RCN building with address, coordinates, averages, and individual flat transactions. It also clearly separates this tool from sibling groups by naming which tools expose asking prices versus RCN transaction prices.

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?

The description clearly separates developers' asking-price tools from RCN transaction tools and explains how to obtain building_slug, including asking the user when none is available. However, it does not spell out how to choose between get_building and the other RCN transaction siblings such as get_transaction_statistics or estimate_property_value.

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