deweloperuch-mcp

Szukaj inwestycji

search_investments

Read-only

Search Polish new-build investment projects by city, developer, or name to compare average price per m² and active offer counts.

Instructions

Wyszukuje inwestycje (projekty deweloperskie, rynek pierwotny). Dwa tryby: city (pełne dane) albo samo name (cała Polska; tylko investment_slug, name i offers_active, w kolejności serwisu). Użyj, gdy pytanie dotyczy projektów, a nie pojedynczych mieszkań: np. najtańsze za m² w mieście, inwestycje jednego dewelopera, slug inwestycji po nazwie.

Z city zwraca inwestycje, które serwis pokazuje na mapie miasta (z aktywnymi ofertami; bez nich mogą nie być na liście): investment_slug, name, city_slug, ulica, status, offers_active, offers_total, średnie (avg_price, avg_area_m2, avg_price_per_m2; tylko aktywne oferty, wg serwisu), developer_slug, developer_name, investment_url i developer_url. name i developer_slug zawężają listę, sort ją porządkuje (domyślnie najwięcej aktywnych ofert); pozycje bez średniej są na końcu. Oferty i szczegóły inwestycji daje get_investment (investment_slug). Linki podawaj użytkownikowi.

Ograniczenia: najwyżej limit pozycji; total, returned, truncated i hint mówią, ile pominięto i co zawęzić. Nie filtruje po cenie ani metrażu (do tego search_offers); city=polska nie działa.

Input Schema

TableJSON Schema

Name	Required	Description
`city`	No	city_slug miasta z search_locations, np. warszawa, sopot (nie polska).
`name`	No	Fragment nazwy inwestycji, 2–100 znaków, np. Kolibki. Z city wielkość liter i polskie znaki nie mają znaczenia; bez city szuka serwis w całej Polsce.
`sort`	No	Tylko z city. active_offers: najwięcej aktywnych ofert (domyślnie); price_per_m2_asc, price_per_m2_desc: średnia cena za m²; price_asc, price_desc: średnia cena; name: alfabetycznie. Bez średniej na końcu.
`limit`	No	Najwięcej inwestycji w wyniku, 1–30, domyślnie 10. Pozycja z city to ok. 550–750 znaków wyniku (z linkami), więc 30 daje najwyżej ok. 23 tys.; zwykle wystarcza 10.
`developer_slug`	No	developer_slug z search_developers (po nazwie) albo z pól developer_slug w search_offers, get_investment, get_offer, np. atal. Tylko z city.

Output Schema

TableJSON Schema

Name	Required	Description
`hint`	No
`items`	Yes
`total`	Yes	Wszystkie pasujące; null, gdy serwis nie podaje (szukanie po nazwie).
`returned`	Yes
`truncated`	Yes	true: pasujących jest więcej, niż pokazano; co zawęzić, mówi hint.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.3Oct 16, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint, so the description carries the real behavioral load: it discloses that city mode returns only investments the site shows on the city map (those without active offers may be absent), that averages cover active offers only, that items without an average sort last, and that total/returned/truncated/hint report what was cut. It even flags that links should be surfaced to the user.

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 and the two modes, then grouped into return fields and limits. Dense and mostly waste-free, though the enumerated return-field list partially duplicates what the output schema already provides and could be trimmed.

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 five-parameter search tool with an output schema, annotations, and eleven siblings, nothing an agent needs is missing: mode selection, field availability per mode, sorting behavior, filtering exclusions, and truncation reporting are all covered.

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 description coverage is 100%, so the baseline is 3, but the description adds cross-parameter semantics the schema does not: which parameters only work together with city (sort, developer_slug), how name alone switches to nationwide site-ordered search, and a practical sizing rule for limit (roughly 550–750 output characters per city item).

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 ('Wyszukuje inwestycje – projekty deweloperskie, rynek pierwotny') and immediately distinguishes the two operating modes (city = full data, name-only = whole Poland with a reduced field set). An agent can tell this apart from search_offers and get_investment without opening any 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?

Gives explicit when-to-use guidance with concrete examples (cheapest per m² in a city, one developer's projects, slug lookup by name) and names the boundary against siblings: price/area filtering goes to search_offers, offer and project details go to get_investment. It also states the negative case (city=polska does not work).

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

Deploy Server