Search 18,000+ privately owned holiday homes on Ferienhausmiete.de: exact stay prices, availability
Scored across 4 tools
Each tool targets a clearly distinct operation: region autocomplete, accommodation search, single-accommodation detail, and per-day availability. The two get_* tools are separated by resource (static detail vs. time-based availability), so an agent can easily pick the right one.
Three tools follow a clean verb_noun snake_case pattern (get_accommodation, get_accommodation_availability, search_accommodations). autocomplete_regions deviates slightly by using a noun-verb-ish form rather than a get_/search_ verb, but it is still readable and consistent in casing.
Four tools is a reasonable, well-scoped read-only surface for a listing search domain: discover regions, search, inspect one listing, check availability. It is on the lean side but each tool earns its place.
The lifecycle of discovering regions, searching, viewing details, and checking availability is covered, including links and pricing. Gaps are minor (no reviews/ratings retrieval tool, no booking action), which agents can work around since booking happens on the returned URLs.
Suggest holiday regions by (partial) name, typo-tolerant. Names are matched in the response language, with German (the native names, e.g. "Seenplatte") always accepted as well. Returns region ids usable as regionId in search_accommodations, with accommodation counts.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | Restrict to one region hierarchy level (1..8); omit for any | |
| limit | No | Maximum suggestions | |
| query | Yes | Search text; honest 2-char minimum, no silent truncation | |
| locale | No | Language the user is writing in (de, en, fr, pl, it, es, nl, hr); defaults to de. Selects the language of names and texts in the response and the language region names are matched in — pass it on every call. | de |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds real behavior beyond that: typo tolerance, that names are matched in the response language, that German native names are always accepted, and that counts are returned with ids.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences, front-loaded with the core behavior and followed by language-matching and return-value details. No filler or repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does so (region ids, accommodation counts, usability as regionId). It is largely complete for a 4-parameter suggest tool, missing only note on empty/no-match results or how level interacts with suggestions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. The description adds semantics the schema does not state, notably that German native names (e.g. "Seenplatte") are always accepted regardless of locale and that matching language tracks the response language; limit and level are left to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Suggest holiday regions by (partial) name') plus the distinguishing trait (typo-tolerant), which separates it from the accommodation siblings. It also names the downstream consumer, search_accommodations, so an agent can place it precisely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the workflow explicit: returned region ids are usable as regionId in search_accommodations, which tells the agent when this tool is the right entry point. It lacks explicit when-not guidance or a stated alternative name-resolution path, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full localized detail of one accommodation: description, location with coordinates, capacity, rating, feature codes, image gallery, base price, and url (the listing page on the website of the locale).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Accommodation id (from search results) | |
| locale | No | Language the user is writing in (de, en, fr, pl, it, es, nl, hr); defaults to de. Selects the language of names and texts in the response and the language region names are matched in — pass it on every call. | de |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. Since no output schema exists, the description's enumeration of returned content (description, coordinates, capacity, rating, feature codes, gallery, base price, url) is genuinely load-bearing behavioral information the agent cannot get elsewhere.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with the core purpose stated first and the field list following. The enumeration is long but each item earns its place because there is no output schema to carry that information; no filler or restated title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates well by listing the response fields and the meaning of url and localization. Remaining gaps are modest: no note on behavior for an unknown/invalid id and no explicit relationship to get_accommodation_availability for date-specific data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 tying the locale parameter to concrete output effects — 'Full localized detail' and the url being 'the listing page on the website of the locale' — clarifying what localization actually changes beyond the schema's own wording.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource and scope ('Full localized detail of one accommodation') and enumerates exactly what a single-record fetch returns, which separates it from the plural search_accommodations and the availability sibling. It stops short of explicitly naming those siblings, so an agent must infer the routing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use, when-not-to-use, or alternative mentioned anywhere in the description. The only routing hint is indirect — the schema says the id comes 'from search results', implying this is a detail call made after a search, but the description itself provides no guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per-day availability for one accommodation: bookable days, arrival/departure flags, minimum stay, nightly price and discounts. Window defaults to today and is capped at 24 months.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Accommodation id (from search results) | |
| to | No | Window end (YYYY-MM-DD) | |
| from | No | Window start (YYYY-MM-DD), defaults to today |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so safety is covered. The description adds useful behavior beyond that: the window defaults to today and is capped at 24 months, and it discloses the shape of the returned per-day data. It stops short of noting rate limits, error cases, or how unbookable days are represented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler. The returned-field enumeration comes first and the window behavior second, so the most decision-relevant information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of describing the return value, and it does so by listing the per-day fields. Combined with the window default/cap rules and full schema coverage, an agent has enough to call it correctly; only edge-case behavior (empty windows, unavailable days) is unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents id, from, and to including formats. The description adds meaning not present in the schema, specifically the default window start (today) and the 24-month maximum span, which constrains how the from/to pair should be used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (per-day availability for one accommodation) and enumerates the returned fields (bookable days, arrival/departure flags, minimum stay, price, discounts), so the agent knows exactly what it retrieves. It does not explicitly contrast itself with siblings like get_accommodation or search_accommodations, though the resource scope makes the distinction inferable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the default window (today) and the 24-month cap, which is genuine operational guidance for calling it. However, it never says when to prefer this over get_accommodation or search_accommodations, nor any exclusions or prerequisites, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paginated holiday accommodation search over directly bookable/inquirable own inventory (externally managed listings are not exposed). Filter by region (regionId from autocomplete_regions), a radius around a point (lat/lng/radiusKm — use the coordinates of the place the user names; results then carry distanceKm and can be sorted by distance) or a map bounding box (neLat/neLng/swLat/swLng); these three are mutually exclusive. Travel dates (arrival/departure, both together; add bookableOnly to drop stays below the minimum stay), persons (a minimum: beds ≥ persons — add personsMax to exclude oversized houses; optional adults split for families — children can use extra-children slots), bedrooms, bathrooms, livingSpaceMin (m²), minReviews, price range per night, feature codes (e.g. swimming_pool, wifi, pets_allowed), accommodation types and offers. Sort: relevance (default), rating (best first; website formula, a single 5.0 review outranks many 4.8s — use minReviews), persons, bedrooms, living_area, distance (radius searches). Every result carries url (the listing page on the website of the locale) and, on dated searches, stayUrl with dates and guests pre-filled — give these to the user as the link. location.place is the actual town; location.region is the (marketing) region it is listed under. Dated searches include a stayPrice per result: the exact total for the stay incl. mandatory costs and discounts (kind "total"; "min_stay" when the stay is below the minimum), or "from"/"on_request" where only the static basePrice or no price is available. approximate: true means some nights were priced from the owner's base price; the website confirms the final total.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Search centre latitude | |
| lng | No | Search centre longitude | |
| page | No | ||
| sort | No | relevance | |
| neLat | No | Bounding box north-east latitude | |
| neLng | No | Bounding box north-east longitude | |
| query | No | Keyword search over names and descriptions in the response language and the German originals | |
| swLat | No | Bounding box south-west latitude | |
| swLng | No | Bounding box south-west longitude | |
| types | No | ||
| adults | No | Adults among persons; when below persons, objects may host the remainder as extra children (website guests widget parity) | |
| locale | No | Language the user is writing in (de, en, fr, pl, it, es, nl, hr); defaults to de. Selects the language of names and texts in the response and the language region names are matched in — pass it on every call. | de |
| offers | No | ||
| arrival | No | ||
| perPage | No | ||
| persons | No | Minimum sleeping places (beds ≥ persons); combine with personsMax to cap size | |
| bedrooms | No | ||
| features | No | ||
| priceMax | No | Omit for unbounded — no sentinel values | |
| priceMin | No | Per night with dates, base price without | |
| radiusKm | No | Radius around the centre in km (as the crow flies), max 300 | |
| regionId | No | Region to search in (from /regions/autocomplete); omit to search everywhere | |
| bathrooms | No | ||
| departure | No | ||
| minReviews | No | Only accommodations with at least this many visible reviews | |
| personsMax | No | Maximum sleeping places (beds ≤ personsMax); excludes oversized houses | |
| bookableOnly | No | Dated searches only: keep only stays that meet the minimum stay (drops stayPrice.kind "min_stay" results) | |
| livingSpaceMin | No | Minimum living space in m² |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safe read-only/idempotent profile, and the description layers on substantial behavioral detail beyond them: pagination, the url/stayUrl fields to hand to the user, the meaning of location.place vs location.region, and the full stayPrice semantics including kind 'total'/'min_stay'/'from'/'on_request' and the approximate flag.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded and nearly every clause carries information, but the entire body is one dense semicolon-chained paragraph that is hard to parse for a 28-parameter tool. It earns its length; it would benefit from clearer segmentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description explains the returned shape (url, stayUrl, location fields, stayPrice, approximate), covers the filter interactions, and gives sort behavior. An agent can call this correctly without further documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 28 params and only 64% schema description coverage, the description carries extra weight and delivers: mutual exclusivity of the geo filters, persons as a minimum with beds ≥ persons, personsMax to exclude oversized houses, adults/extra-children split, bookableOnly dropping min_stay stays, distance sorting only on radius searches, and per-night vs base price semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (paginated holiday accommodation search) and sharply bounds scope: only directly bookable/inquirable own inventory, with externally managed listings excluded. It does not name or distinguish against the sibling tools (get_accommodation, get_accommodation_availability), so it falls just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides strong operational context: it names the mutually exclusive geometry options (regionId vs lat/lng/radiusKm vs bounding box), tells the agent to use the coordinates of the place the user names, and points to autocomplete_regions as the source for regionId. However, it never says when to prefer this tool over the get_accommodation siblings, so no explicit alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
autocomplete_regionsget_accommodationget_accommodation_availabilitysearch_accommodationsHoliday rentals booked direct with the host: availability, prices, checkout links. No auth.
Book vacation rentals direct: search homes, check live availability, get a real total.
Find vacation rentals, explore photos and property details, and open direct host booking links.
Search and book verified independent vacation rentals directly from hosts, with no guest fees.
Add one secure layer between your agents and this server.