Skip to main content
Glama

Get one Slowhop place

slowhop_place

Full details of one slowhop.com place: type, summary, highlights and the host's description (Polish), address and coordinates, setting, rating and recent reviews, every unit (house/room/tent: capacity, area, rooms and beds, pets accepted), check-in/out times and quiet hours, house rules, pets policy (kinds accepted, limit, rules), who it suits, food and kitchen, amenities (comfort, kitchen, garden, wellness included, extra-paid extras with prices), internet, nearby activities/restaurants/shops/sights with distances, getting there, fees, discounts (last-/first-minute, long stay, children), payment and cancellation terms, the lowest upcoming price and photos. With date_from/date_to it also prices the stay for the party with Slowhop's own calculator: whether it is bookable (free, minimum stay met, the group and pets fit), the exact total and per-night price in the place's currency (PLN in Poland) with a breakdown, the units used and a booking link. Get the slug from slowhop_search. Fetched live from Slowhop's own JSON API (typically well under 1 s via direct fetch; more when it falls back to an unblocker). Result: { source, fetchedAt, place: { id, slug, name, url, type, currency, summary, highlights, description, texts, location, rating, reviews_count, recent_reviews, host, max_guests, min_age, units, rent_type, check_in, check_out, quiet_hours, flexible_check_in, pets, house_rules, for_whom, food, amenities, internet, nearby, getting_there, fees, discounts, payment, lowest_price, instant_booking, photos }, stay?: { date_from, date_to, nights, adults, children_ages, pets, available, price, price_per_night, currency, breakdown: { nightly_rates, last_minute_discount, first_minute_discount, children_discount, children_fee, cleaning_fee, pets_fee }, meal_plan, min_nights, units, booking_url, calculator_quote?, note? } }. stay.price is the total for the whole stay and party (nightly rates after discounts + children's, cleaning and pet fees); stay.available is true, false (a note says why and what to change) or null when Slowhop's availability calendar did not answer (priced, but the minimum stay is unverified). When available is false, price, price_per_night and breakdown are null and units empty — never quote such a stay; if Slowhop's calculator still priced it (it ignores minimum stays and pets a place refuses), its figures are in calculator_quote { price, price_per_night, breakdown, units, note } for reference only.

Input Schema

NameRequiredDescriptionDefault
petsNoThe animals coming along, one entry each: 'small_dog', 'medium_dog', 'big_dog', 'cat' (e.g. ['big_dog', 'cat']). Also limits results to places that accept them. Default none.
placeYesThe place's slug from slowhop_search (e.g. '6639-dom-na-mazurach-sasek-wielki'), its slowhop.com URL (…/pl/miejsca/<slug>.html), or its numeric id.
adultsNoAdults. Default 2.
date_toNoCheck-out date, YYYY-MM-DD, after date_from.
no_cacheNoForce a fresh fetch and bypass this server's result cache (5 min). Default false.
date_fromNoCheck-in date, YYYY-MM-DD — pass with date_to to price the stay.
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.5/5.0
Behavior5/5

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

No annotations exist, and the description carries the full burden well: live JSON API fetch with latency expectations and an unblocker fallback, plus the null/true/false semantics of `stay.available` including the unverified-minimum-stay case. It also warns that `price`/`breakdown` are null when unavailable, that such stays must never be quoted, and that `calculator_quote` is reference-only because Slowhop's calculator ignores minimum stays and refused pets.

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?

It is front-loaded with the purpose before the detail, but the body is a very dense, very long block, and the inline enumeration of the entire result object consumes a large share of it. Without an output schema that enumeration is defensible, yet it is heavy enough to slow an agent down compared with a tighter field list.

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?

There is no output schema, so the description correctly documents the full return shape including the optional `stay` branch, the breakdown sub-fields, and the degraded `calculator_quote` path. For a 7-parameter tool with conditional pricing behavior, an agent has everything needed to call it and to interpret an empty or refused result.

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; the description goes beyond it by explaining that date_from/date_to switch on Slowhop's own pricing calculator and that the result is computed for "the party" (adults, children ages, pets), which is behavioral meaning the schema does not convey. It does not restate individual parameter formats, but it doesn't need to.

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?

Opens with a specific verb and resource ("Full details of one slowhop.com place") and then enumerates the payload domains: units, house rules, pets policy, amenities, fees, discounts, cancellation, plus optional stay pricing. It is unambiguously distinguishable from slowhop_search, which it names as the source of the slug.

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?

It routes the agent explicitly ("Get the slug from slowhop_search") and explains the condition that activates the pricing path ("With date_from/date_to it also prices the stay for the party"). What's missing is an explicit statement of when not to use it, e.g. browsing many places should go to slowhop_search rather than repeated calls here.

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