Deweloperuch MCP

Rank cities and powiats

deweloperuch_rank_locations

Read-only

A ranking of localities (level=city) or powiats (level=powiat) in Poland by Real Estate Price Register (RCN) transactions: the number of transactions and the transaction price per m². Use it to compare many cities; for the trend of one city over time use deweloperuch_get_transaction_statistics. These are transaction prices, not asking prices. Limits: the site gives no period and does not say whether prices and areas are means or medians — present them as the values the site gives. Powiat transaction counts cover many years: they only order the list, are not the current volume and must not be compared with locality counts. Sorting by price leaves out places with fewer than 20 transactions by default (a price from a handful of sales is chance); min_transactions=0 shows all places, 50 gives steadier prices. 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: { level, sort, min_transactions (the threshold applied), total (places with at least that many transactions), returned, truncated, hint?, ranking_url? (city level), source, items: [{ name, city_slug? (city) | powiat_id? (informational: no tool takes it), transaction_count, price_per_m2?, area_m2?, price? }] } — the list key is items. A place without a price has no price fields and sorts last by price.

Input Schema

Name	Required	Description
`sort`	No	transactions_desc (default): most transactions; price_per_m2_desc: highest price per m²; price_per_m2_asc: lowest price per m². Places without a price come last.
`level`	No	city (default): localities — cities, small towns and villages; powiat: powiats (no ranking_url and no counterpart in deweloperuch_search_locations).
`limit`	No	How many top entries of the ranking to return, 1–100. Default 20 (about 120 characters each). To see more places narrow min_transactions rather than raising the limit.
`min_transactions`	No	Fewest transactions a place needs to be ranked. Omitted = the default threshold: 20 when sorting by price, 0 for transactions_desc. 0 = all places; e.g. 50 gives steadier prices.

Output Schema

Name	Required	Description	Default
`hint`	No
`sort`	Yes
`items`	Yes
`level`	Yes
`total`	Yes
`source`	Yes
`returned`	Yes
`truncated`	Yes
`ranking_url`	No
`min_transactions`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only cover readOnlyHint and openWorldHint; the description adds far more: no stated period, unknown mean/median, powiat counts spanning many years that only order the list, the default 20-transaction price threshold and why it exists, one-request-at-a-time caching, and a STOP error protocol that forbids retries. It also tells the agent to hand _url fields to the user as links.

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?

The scoping constraint and the alternative are front-loaded, and nearly every sentence carries operational content. It is dense to the point of being a wall of text with no paragraph breaks, and the long sibling enumeration in the 'two kinds of prices' passage could be tightened.

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?

All four parameters, the result semantics, the failure mode and the linking convention are covered. Restating the result shape is somewhat redundant given the output schema, but it adds interpretation (price-less places sort last, `items` is the list key) rather than just repeating field names.

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 enum values and limits are already documented. The description adds interpretive meaning beyond that: the rationale for the 20-transaction threshold ('a price from a handful of sales is chance') and the warning that powiat counts must not be compared with locality counts, which no parameter description conveys.

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 opening sentence names the exact resource (localities or powiats in Poland), the source (RCN transactions) and the two metrics returned (transaction count and price per m²). It also immediately distinguishes the tool from deweloperuch_get_transaction_statistics, so an agent can route without opening either schema.

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?

Explicit routing: 'Use it to compare many cities; for the trend of one city over time use deweloperuch_get_transaction_statistics.' It also names the sibling group whose prices must not be mixed with these and states when to raise or lower min_transactions, which is exactly the decision an agent faces.

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

All Deweloperuch MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?