How do I use rcs-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@rcs-mcp Pokaż statystyki cen w Zakopanem dla lokali mieszkalnych." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

rcs-mcp

by lakafior

Overview Schema Related Servers Score Discussions

Python

Remote

rcs-mcp

Serwer MCP dla Rejestru Cen Nieruchomości z geoportal.gov.pl. Udostępnia Claude Desktop narzędzia do wyszukiwania obszarów w Polsce i sprawdzania rzeczywistych transakcji nieruchomościowych z aktów notarialnych.

Co udostępnia

znajdz_obszar(nazwa, poziom) - znajduje bbox dla województwa, powiatu, gminy, miasta albo wsi.
wyszukaj_transakcje(...) - zwraca listę transakcji dla bboxa.
statystyki_cen(...) - liczy medianę, średnią, kwartyle i zakres ceny za m2 na próbie transakcji, plus medianę w rozbiciu na lata.

Typowy przepływ:

znajdz_obszar("Zakopane", "miasto")
Weź bbox z wyniku.
statystyki_cen(bbox=...) albo wyszukaj_transakcje(bbox=...)

Related MCP server: Property Price Search MCP Server

Jakość danych

Surowe rekordy RCN dają bardzo mylące ceny za m2 - te same dane potrafią pokazać i 65 zl/m2, i 71 tys. zl/m2 w jednym mieście. Dlatego domyślnie:

Cena bierze się z nieruchomości, nie z aktu notarialnego. tran_cena_brutto to cena całego aktu, który często obejmuje kilka lokali (16% rekordów w próbce z Sopotu) - dzielona przez powierzchnię jednego lokalu zawyżała cenę nawet dwukrotnie.
Powierzchnia gruntu nie zastępuje powierzchni lokalu. Fallback na nier_pow_gruntu (grunt pod całym budynkiem) działa już tylko dla działek.
tylko_rynkowe=True odsiewa sprzedaż udziałów ułamkowych (cena za ułamek, powierzchnia całości - np. 9 zl/m2 za udział w hali garażowej) i transakcje spoza wolnego rynku (komunalne z bonifikatą, bezprzetargowe).
tylko_mieszkalne=True odsiewa garaże, komórki lokatorskie i lokale usługowe.
Wartości skrajne odrzuca reguła Tukeya (3 x IQR na logarytmie ceny), więc zwracane min/max to krańce oczyszczonej próbki. Liczbę odrzuconych widać w odrzucone_odstajace.

Każdy z tych filtrów można wyłączyć parametrem, żeby zobaczyć surowe dane.

Osobna sprawa to czas: RCN nie filtruje po dacie po stronie serwera, więc próbka potrafi objąć 20+ lat i wtedy jedna mediana miesza epoki cenowe (dla Łodzi bez filtra: 3,7 tys. zl/m2, a dla samego 2025-2026: 8,3 tys.). Dlatego wynik zawsze zawiera zakres_dat i mediana_wg_roku, a przy szerokiej próbce - ostrzeżenie. Do wyceny podawaj data_od.

Obsługiwane typy nieruchomości:

lokale
budynki
dzialki

Uruchomienie

Projekt działa przez Docker Compose. Lokalny venv nie jest potrzebny.

docker compose up -d

Przy zmianach w kodzie przebuduj obraz:

docker compose up -d --build

Zatrzymanie:

docker compose down

Cache granic administracyjnych jest trzymany w wolumenie Dockera rcs-mcp-cache, więc kolejne uruchomienia korzystają z zapisanych danych.

Zbudowanie cache'u od zera trwa dłużej niż limit czasu pojedynczego wywołania narzędzia MCP (ok. 30 s dla powiat, ok. 60 s dla gmina), dlatego kontener po starcie rozgrzewa w tle brakujące poziomy. Postęp widać w logach:

docker compose logs -f rcs-mcp

Jeśli mimo to trafisz na jeszcze niezbudowany poziom, znajdz_obszar nie zawiesi się do timeoutu — zwróci informację, że cache buduje się w tle. Pobieranie leci dalej, więc wystarczy powtórzyć to samo wywołanie za kilkadziesiąt sekund.

Claude Desktop

Wpis w claude_desktop_config.json:

{
  "mcpServers": {
    "rcs-mcp": {
      "command": "/usr/local/bin/docker",
      "args": [
        "compose",
        "-f",
        "/Volumes/wew/Git/rcs-mcp/docker-compose.yml",
        "exec",
        "-T",
        "rcs-mcp",
        "rcs-mcp"
      ]
    }
  }
}

Po zmianie konfiguracji zrestartuj Claude Desktop.

Źródła danych

RCN: https://mapy.geoportal.gov.pl/wss/service/rcn?language=pol
PRG, granice administracyjne: https://mapy.geoportal.gov.pl/wss/service/PZGIK/PRG/WFS/AdministrativeBoundaries
PRNG, nazwy miejscowości: https://mapy.geoportal.gov.pl/wss/service/PZGiK/PRNG/WFS/GeographicalNames

Geoportal zwraca dane jako WFS/GML. Serwer pobiera je przez httpx i parsuje lokalnie.

Ograniczenia

Filtrowanie serwerowe CQL_FILTER w usługach Geoportalu jest ignorowane, więc projekt filtruje dane po stronie klienta.
Realnie użyteczny filtr przestrzenny to BBOX.
Pierwsze wyszukanie obszaru może pobrać większą warstwę PRG/PRNG i zbudować cache.
Dane RCN bywają zaszumione, np. udziałami, garażami, komórkami lub błędnymi powierzchniami. Dla statystyk zwykle bardziej sensowna jest mediana niż średnia.
Parametr tylko_mieszkalne=True domyślnie odrzuca część rekordów niemieszkalnych dla lokali i budynków.

Struktura

rcs_mcp/server.py - definicje narzędzi MCP.
rcs_mcp/wfs_client.py - pobieranie i parsowanie transakcji RCN.
rcs_mcp/granice.py - wyszukiwanie obszarów i cache PRG/PRNG.
Dockerfile - obraz aplikacji.
docker-compose.yml - uruchomienie kontenera dla Claude Desktop.

Available Tools

3 tools

statystyki_cenA

Liczy statystyki ceny za m² na podstawie próby rzeczywistych transakcji w danym obszarze.

Wartości odstające są odrzucane (reguła Tukeya na logarytmie ceny), więc zwracane min/max to krańce oczyszczonej próbki, a nie artefakty danych RCN. Pole odrzucone_odstajace mówi, ilu rekordów to dotyczyło — jeśli jest ich dużo w stosunku do liczba_w_probce, potraktuj wynik ostrożnie.

Args: bbox: Ramka (south, west, north, east) w EPSG:4326, np. z znajdz_obszar. typ: Rodzaj nieruchomości: "lokale" (mieszkania), "budynki" lub "dzialki". rodzaj_rynku: Opcjonalny filtr rynku: "pierwotny" lub "wtorny". data_od: Tylko transakcje od tej daty aktu notarialnego, "RRRR-MM-DD" (włącznie). data_do: Tylko transakcje do tej daty aktu notarialnego, "RRRR-MM-DD" (włącznie). tylko_mieszkalne: Dla "lokale"/"budynki" (domyślnie True) odsiewa garaże, komórki lokatorskie i lokale usługowe/biurowe — bez tego silnie zaniżają/zawyżają cenę za m². Ustaw na False, żeby liczyć z surowych danych. tylko_rynkowe: (domyślnie True) odsiewa sprzedaż udziałów ułamkowych i transakcje spoza wolnego rynku (bonifikaty komunalne itd.). liczba_prob: Maksymalna liczba transakcji branych do próby (domyślnie 300).

ParametersJSON Schema

Name	Required	Default
`typ`	No	lokale
`bbox`	Yes
`data_do`	No
`data_od`	No
`liczba_prob`	No
`rodzaj_rynku`	No
`tylko_rynkowe`	No
`tylko_mieszkalne`	No

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description fully discloses key behaviors: outlier rejection via Tukey's rule on log price, the meaning of cleaned min/max, the 'odrzucone_odstajace' field, and a caution for high outlier counts. It also explains the impact of 'tylko_mieszkalne' and 'tylko_rynkowe' filters on data quality, providing a solid safety profile.

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

Conciseness5/5

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

The description is well-structured: a clear one-sentence purpose, a brief behavioral note, then a systematic Args list. Every sentence contributes value, and key information is front-loaded. It is appropriately sized for an 8-parameter tool without redundancy.

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?

Given 8 params, no output schema, and no annotations, the description covers every input parameter, explains the outlier-cleaning behavior, and provides interpretation guidance via 'odrzucone_odstajace'. It also integrates with sibling 'znajdz_obszar' for bbox, making it complete for selection and correct invocation.

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

Parameters5/5

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

Schema description coverage is 0%, but the description compensates by explaining all 8 parameters in the Args section. It gives order and coordinate system for bbox, enum values for typ, date format and inclusivity for data_od/data_do, and the behavioral rationale for boolean filters. This far exceeds the schema's basic titles and types.

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 description opens with a specific verb and resource: 'Liczy statystyki ceny za m²' (computes per-m² price statistics) from real transactions in an area. This clearly distinguishes it from siblings like 'znajdz_obszar' (find area) and 'wyszukaj_transakcje' (search transactions), making its purpose unambiguous.

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?

The description implies its usage context (for area-based market statistics) and references 'znajdz_obszar' for bbox input, but it never explicitly states when to prefer this tool over siblings or when not to use it. No exclusions or alternative comparisons are provided, so guidance is only implied.

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

wyszukaj_transakcjeA

Zwraca rzeczywiste transakcje nieruchomościami (z aktów notarialnych) w danym obszarze.

Obszar (bbox: south, west, north, east w WGS84/EPSG:4326) najłatwiej uzyskać przez wcześniejsze wywołanie znajdz_obszar.

Args: bbox: Ramka (south, west, north, east) w EPSG:4326, np. z znajdz_obszar. typ: Rodzaj nieruchomości: "lokale" (mieszkania), "budynki" lub "dzialki". rodzaj_rynku: Opcjonalny filtr rynku: "pierwotny" lub "wtorny". data_od: Tylko transakcje od tej daty aktu notarialnego, "RRRR-MM-DD" (włącznie). data_do: Tylko transakcje do tej daty aktu notarialnego, "RRRR-MM-DD" (włącznie). tylko_mieszkalne: Dla "lokale"/"budynki" (domyślnie True) odsiewa garaże, komórki lokatorskie i lokale usługowe/biurowe sprzedawane jako odrębne pozycje — bez tego silnie zaniżają/zawyżają cenę za m². Ustaw na False, żeby zobaczyć wszystkie rekordy bez tego filtra. tylko_rynkowe: (domyślnie True) odsiewa transakcje nieporównywalne cenowo: sprzedaż udziału ułamkowego (cena za ułamek, powierzchnia całości) i sprzedaż poza wolnym rynkiem (komunalna z bonifikatą, bezprzetargowa). limit: Maksymalna liczba transakcji do zwrócenia (domyślnie 50).

ParametersJSON Schema

Name	Required	Default
`typ`	No	lokale
`bbox`	Yes
`limit`	No
`data_do`	No
`data_od`	No
`rodzaj_rynku`	No
`tylko_rynkowe`	No
`tylko_mieszkalne`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior4/5

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

No annotations exist, so the description carries the burden. It discloses that transactions come from notarial deeds, uses WGS84 with bbox order (south, west, north, east), and gives detailed rationale for the filtering flags (e.g., without only_mieszkalne, garages and storage units distort price per m²). It does not mention rate limits, response sorting, or error behavior, but is fairly transparent for a read-only search.

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

Conciseness5/5

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

Front-loaded with a one-sentence summary, followed by a practical hint about finding bbox, then a well-structured Args list. Each parameter description is concise yet informative, with no filler or unnecessary repetition of schema defaults.

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?

With 8 parameters and no annotations, the description addresses all parameters, defaults, and filter semantics, and includes a cross-reference to znajdz_obszar as a prerequisite. Since an output schema exists, the lack of return-value details is acceptable. The description is sufficiently complete for a complex tool.

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

Parameters5/5

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

Schema has 0% description coverage, so the description fully compensates: every parameter (bbox, typ, rodzaj_rynku, data_od, data_do, tylko_mieszkalne, tylko_rynkowe, limit) is explained with values, defaults, and intent. For example, typ enums are expanded into 'lokale (mieszkania), budynki, dzialki' and date inclusivity is specified ('włącznie').

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 description states 'Zwraca rzeczywiste transakcje nieruchomościami (z aktów notarialnych) w danym obszarze' – a specific verb (returns), resource (transactions), and scope (area). It clearly distinguishes from siblings like znajdz_obszar and statystyki_cen by focusing on raw transaction data from notarial deeds.

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 explicit workflow guidance: bbox is best obtained via 'znajdz_obszar', positioning this tool in a pipeline. It also clarifies when to set only_mieszkalne=False and only_rynkowe=False to include all records. However, it does not mention alternatives or when to use statystyki_cen instead, so it lacks explicit exclusions.

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

znajdz_obszarA

Wyszukuje województwo/powiat/gminę/miasto/wieś po nazwie i zwraca jej bbox.

Użyj wyniku (bbox) jako argumentu bbox w wyszukaj_transakcje/statystyki_cen. Może zwrócić więcej niż jedno dopasowanie (różne miejsca o tej samej nazwie w różnych regionach) — rozróżnij je po polach powiat/wojewodztwo.

Args: nazwa: Szukana nazwa, np. "Warszawa", "Zakopane", "Zalipie". poziom: "wojewodztwo", "powiat", "gmina", "miasto" (domyślnie) lub "wies". Pierwsze wyszukanie na danym poziomie buduje lokalny cache z danych GUGIK (PRG/PRNG). Zwykle cache jest już rozgrzany po starcie serwera, ale jeśli nie — narzędzie zwróci komunikat, że budowa trwa w tle; wtedy po prostu powtórz to samo wywołanie za kilkadziesiąt sekund.

ParametersJSON Schema

Name	Required	Description	Default
`nazwa`	Yes
`poziom`	No		miasto

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

No annotations are provided, so the description carries the full burden. It discloses key behaviors: possible multiple matches ("Może zwrócić więcej niż jedno dopasowanie"), cache building on first use per level ("Pierwsze wyszukanie na danym poziomie buduje lokalny cache z danych GUGIK"), and the retry mechanism when cache isn't ready ("po prostu powtórz to samo wywołanie za kilkadziesiąt sekund"). This goes well beyond the schema.

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

Conciseness5/5

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

The description is well-structured: purpose, usage link, disambiguation note, then a concise Args list. Every sentence provides necessary information—no fluff. It's appropriately sized for a tool with 2 parameters and includes operational details without being verbose.

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?

Given the tool has an output schema and is a search/geocoding utility, the description covers all essentials: purpose, parameter semantics, output usage, ambiguity handling, and cache behavior. It's self-contained for an agent to invoke correctly and handle edge cases.

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

Parameters5/5

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

Schema description coverage is 0%, but the description's Args section fully explains both parameters: `nazwa` with examples ("Warszawa", "Zakopane", "Zalipie") and `poziom` with enum values, default, and cache behavior. This adds substantial meaning beyond the raw schema, making parameter usage clear.

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 description clearly states the tool's function: "Wyszukuje województwo/powiat/gminę/miasto/wieś po nazwie i zwraca jej bbox." It specifies the verb (wyszukuje), resource (administrative units), and output (bbox). It also distinguishes from siblings by explicitly tying its result to `wyszukaj_transakcje`/`statystyki_cen`, making the purpose unique.

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 provides clear usage context: "Użyj wyniku (`bbox`) jako argumentu `bbox` w `wyszukaj_transakcje`/`statystyki_cen`." It explains the tool is a prerequisite for those tools and warns about multiple matches with disambiguation guidance. It doesn't explicitly state when not to use it, but the intended use case is clear.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

3 tool updatesv0.1.0Aug 13, 2026
- First observedstatystyki_cen
- First observedwyszukaj_transakcje
- First observedznajdz_obszar

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.7/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: znajdz_obszar resolves a name to a bounding box, wyszukaj_transakcje returns raw transaction records, and statystyki_cen computes aggregated price statistics. There is no overlap in functionality, so an agent can easily select the right tool for the intended step.

Naming Consistency4/5

All names use lowercase snake_case and are concise Polish terms, but the pattern is not perfectly uniform: znajdz_obszar and wyszukaj_transakcje are verb_noun, while statystyki_cen is noun_noun. This is a minor deviation from a consistent verb-first convention and still readable.

Tool Count5/5

With only 3 tools, the server is tightly focused on querying real estate transactions. Each tool is essential and fills a distinct role in the workflow (geocoding, raw data, statistics), so the count is well-scoped and not too thin.

Completeness5/5

The toolset forms a complete pipeline for the domain: find an area by name, then use the returned bbox to either fetch raw transactions or compute price statistics. Since this is a read-only data service, there are no obvious missing lifecycle operations, and agents can accomplish the intended tasks without dead ends.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Cenogram - Polish Real Estate Prices & Parcel Data A
pl.cenogram
Polish real estate for AI: 8M+ deed transaction prices (RCN) + per-parcel context by cadastral ID
Real Estate Government Data Open Data
21
strajkpolski-mcp B
io.github.Hei33enberg
Verified Polish open data for AI agents: debt, budget, 460 MPs, votings, judiciary search, RAG.
Government Data Open Data RAG Systems
2
不動産情報サービス MCP A
io.github.n-3inc
国土交通省の不動産情報ライブラリから不動産価格データを取得するためのサービスです。
Real Estate Government Data Open Data
32
UK Planning Data MCP Server from MCPBundles A
com.mcpbundles
Search UK planning applications, entities, datasets, and conservation areas
Government Data Search Open Data
2

Related MCP Servers

MCP Rosreestr
Real Estate Government Data Location Services
yasg1988
A
license
Not graded
quality
C
maintenance
Enables retrieval of Russian real estate cadastral data including coordinates, property information, area, cadastral value, and GeoJSON geometry by cadastral number using Rosreestr API.
Updated 4 months ago (2026-05-13 18:13 UTC)
5
MIT
Property Price Search MCP
Real Estate Government Data Open Data
joemclo
A
license
A
quality
D
maintenance
Enables users to search UK property prices by postcode, street, or city using the HM Land Registry's SPARQL endpoint. It also provides tools for resolving postcodes and finding nearby locations through Ordnance Survey data.
Updated 7 months ago (2026-02-15 18:17 UTC)
2
2
MIT
cenogram-mcp-serverofficial
Government Data Real Estate
cenogram
A
license
A
quality
C
maintenance
7M+ real estate transactions from Poland's RCN registry. Search, compare, and analyze prices
Updated a month ago (2026-08-02 13:43 UTC)
23
87
1
MIT
vworld-mcp
Real Estate Location Services
jeon3709-dev
F
license
Not graded
quality
B
maintenance
Enables to query South Korean cadastral and land information (parcel boundaries, land use zones, official land prices) via VWorld Open API, supporting geocoding, reverse geocoding, and location search for real estate feasibility reviews.
Updated 2 months ago (2026-07-07 04:29 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/lakafior/rcs-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

rcs-mcp

Co udostępnia

Jakość danych

Uruchomienie

Claude Desktop

Źródła danych

Ograniczenia

Struktura

Available Tools

TDQS

Output Schema

TDQS

Output Schema

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

MCP Rosreestr

Property Price Search MCP

cenogram-mcp-serverofficial

vworld-mcp

Latest Blog Posts

MCP directory API