Skip to main content
Glama

Search accommodation in Poland (noclegi.pl)

noclegi_search

Search places to stay in a Polish town or region on noclegi.pl — hotels, guest houses, pensions, apartments, cottages, private rooms, agritourism — with the price for the whole stay, board, guest rating, location and link. Filter by property type, board, minimum rating, free cancellation and total price; sort by price, rating or discount. One results page is up to 50 offers; pass a listing's slug to noclegi_object for rooms, rate plans, amenities and the description. Fetched live from noclegi.pl (typically ~1 s via direct fetch; up to ~20 s when it falls back to an unblocker). WITH checkin + checkout, each price is the total for the whole stay for the given guests in PLN, incl. taxes and fees (e.g. price_for '2 osoby, 2 noce'); sold-out offers stay listed with price null and available false. WITHOUT dates, price is only the site's indicative price for 1 night (price_for '2 osoby, 1 noc'), many offers have none, and the result carries a note saying so — pass dates to quote a stay. Result shape: { source, fetchedAt, query, search_url, place: { name, slug, kind, area }, heading, stay: { checkin, checkout, nights } | null, guests: { adults, children_ages }, total_count, page, total_pages, count, listings: [...], note? } — the list key is listings; total_count counts offers across all pages (use page for more). Each listing: { id, slug, url, name, type, stars, city, price, price_before_discount, discount_percent, currency, price_for, board, available, free_cancellation, rating, rating_count, rating_label, lat, lng, image, amenities, labels }. board is room_only | breakfast | half_board | full_board | …; rating is 0–10; free_cancellation is the site's deadline text (Polish) or null; url opens the property with the same stay. When a place has few offers the site widens to a radius (the note says so; check city). An empty match answers count: 0 with a note saying why and what to change — that is a successful result, not an error.

Input Schema

NameRequiredDescriptionDefault
pageNoResults page, 1-based (up to 50 offers per page). Default 1.
sortNoOrder: recommended (default — the site's own ranking, which may depend on commission), rating, price_asc / price_desc (by price per person per night), discount.
boardNoOnly offers with this board: room_only, breakfast, half_board, full_board, soft_all_inclusive, all_inclusive.
placeYesTown or region in Poland, Polish name preferred: 'Zakopane', 'Szklarska Poręba', 'Białka Tatrzańska', 'Mazury', 'Tatry', 'Polskie morze', 'Bieszczady'. Resolved through noclegi.pl's own place search (diacritics optional; a few English names such as 'Warsaw' or 'Baltic coast' are mapped). A https://noclegi.pl/<place> link also works.
typesNoOnly these property types (any of them): hotel, apartment, guest_house (dom gościnny), pension (pensjonat), villa (willa), private_room (kwatera prywatna), wooden_cottage (domek drewniany), year_round_cottage (domek całoroczny), resort (ośrodek wypoczynkowy), agritourism, inn (zajazd), hostel, student_house, sanatorium.
adultsNoAdults. Default 2.
checkinNoArrival date, YYYY-MM-DD (from today to about a year ahead). Pass together with checkout; omit both for undated results.
checkoutNoDeparture date, YYYY-MM-DD, after checkin — at most 30 nights (the site drops longer stays).
no_cacheNoForce a fresh fetch and bypass this server's result cache (5 min). Default false.
price_maxNoMaximum total price for the whole stay, whole PLN (needs checkin/checkout).
price_minNoMinimum total price for the whole stay, whole PLN (needs checkin/checkout).
min_ratingNoOnly guest ratings of at least 8, 9 or 9.5 (0–10 scale).
children_agesNoEach child's age in years (0–17), e.g. [4, 9] for two children — prices depend on ages. Default none.
free_cancellationNoOnly offers that can be cancelled free of charge.

Output Schema

NameRequiredDescriptionDefault
noteNo
pageYes
stayNo
countYes
placeYes
queryYes
guestsNo
sourceYes
headingNo
listingsYes
fetchedAtYes
search_urlYes
total_countNo
total_pagesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description fully carries the burden: it discloses live-fetch latency (~1 s, up to ~20 s on unblocker fallback), caching, sold-out offers returning price null/available false, radius widening when a place is thin, and why an empty match returns a note. That is exactly the operational context an agent needs before calling.

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?

Front-loaded with the purpose and filtering/sorting, but then spends a large block restating the full result object and per-listing fields, which duplicates the output schema. Useful content, but the payload is oversized and the return-shape enumeration does not earn its tokens.

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 14-parameter search tool with no annotations, the description covers price semantics, date constraints, pagination, fallback behavior, and edge-case results. Nothing an agent needs to call it correctly is missing, even if some of the return-shape detail overlaps the output schema.

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 baseline is 3, but the description adds the crucial cross-parameter semantics: prices are totals only when dates are supplied, otherwise indicative 1-night values; the `price_for` string and the `note` reflect which mode applies. It reinforces but does not go far beyond the schema's own per-param docs.

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 (search) plus resource (places to stay on noclegi.pl) and enumerates the covered property categories. It also distinguishes itself from the sibling noclegi_object by declaring that tool as the follow-up for rooms/rate plans/amenities.

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 this for discovery, then pass a listing's `slug` to noclegi_object. It also tells the agent when to supply checkin/checkout (to get a real stay quote), to use `page` for more results, and that a count:0 answer is a successful result rather than an error.

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