Skip to main content
Glama
Sign In

Noclegi MCP

by ai.wondel
OverviewDiscussionsAdmin

Get one noclegi.pl property

noclegi_object

Full details of one place to stay on noclegi.pl: description, address and coordinates, guest rating and recent reviews, check-in/check-out times, amenities, photos, and every room type with its size, beds, amenities and — for given dates and guests — its rate plans (price for the stay, board, cancellation terms, prepayment). With checkin/checkout it also returns the total price of the cheapest room combination for the guests and the booking link; without dates, price_from is the site's best 1-night price in the next ~90 days and the night it applies to. When the dates cannot be booked (sold out, minimum stay) price is null and the note carries the site's reason. noclegi.pl does not publish the property's own phone or email — bookings go through the site. Fetched live from noclegi.pl (typically ~1 s via direct fetch; up to ~20 s when it falls back to an unblocker). Result: { source, fetchedAt, query, page_url, object: { id, slug, url, name, type, stars, description, address, geo, rating, rating_count, checkin_time, checkout_time, breadcrumbs, amenities, photos, reviews, stay, price, price_before_discount, discount_percent, currency, price_for, prepayment, selected_rooms, price_from, availability_note, booking_url, rooms: [{ id, name, available_rooms, max_guests, area_m2, beds, amenities, rates: [{ price, price_before_discount, discount_percent, board, price_for, cancellation, prepayment, bookable }] }] }, note? }. Prices in PLN incl. taxes and fees.

Input Schema

NameRequiredDescriptionDefault
adultsNoAdults. Default 2.
objectYesThe property: its `slug` from noclegi_search (e.g. 'apartamenty-apartart-zakopane'), its https://noclegi.pl/<slug> link, or its name (looked up through the site's search).
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.
children_agesNoEach child's age in years (0–17), e.g. [4, 9] for two children — prices depend on ages. Default none.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

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 carries the full burden and does so: it discloses latency (~1s direct, up to ~20s via unblocker), null prices with an availability_note when dates are unbookable, cache behavior via no_cache, and the site limitation that no phone/email is published. Prices are stated as PLN inclusive of taxes and fees.

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?

Purpose and the dated/undated distinction are front-loaded, and the long result-shape block is justified given there is no output schema. The opening sentence is overloaded with a long enumeration, which costs some readability, but no sentence is truly wasted.

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?

A six-parameter tool with no output schema and no annotations needs exactly this: return shape, failure semantics, pricing conventions, latency, and freshness controls. All are present, so an agent can call it and interpret the response without guessing.

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 baseline is 3, but the description adds real meaning beyond the schema: it explains what dates unlock (total price of cheapest combination, booking link), what price_from means when dates are omitted, and that rates are per room type for the given guests. The interaction between date params and refunded fields is not spelled out further, keeping it just above baseline.

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 — 'Full details of one place to stay on noclegi.pl' — and enumerates the content returned (description, address, reviews, rooms, rates). This clearly distinguishes it from noclegi_search, which returns a list rather than a single property.

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?

Explicitly explains the dated vs undated modes ('With checkin/checkout it also returns... without dates, `price_from` is...') and the sold-out failure mode. It stops short of explicitly naming noclegi_search as the way to obtain the slug, leaving that routing implicit rather than stated as an alternative.

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

All Noclegi MCP toolsInspect
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