Beach Valencia holiday apartments (Valencia, Spain): availability, pricing, cancellation policy.
Scored across 5 tools
Each tool has a clearly distinct role: search_availability handles broad date/pax searches, get_property_details enriches a chosen category, get_quote prices one fixed category/date range, get_policies answers policy questions, and create_booking_request starts checkout. The only mild overlap is pricing data appearing in both search_availability and get_quote, but the WHEN guidance makes the intended split explicit.
All names use snake_case with a predictable verb_noun structure: search_availability, get_property_details, get_quote, get_policies, create_booking_request. The pattern is consistent enough that an agent can infer action and resource from every name.
Five tools is well-scoped for a pre-booking vacation-rental assistant: discovery, detail, pricing, policy, and booking creation. No tool feels redundant, and the set stays small enough to avoid decision overhead.
The core pre-booking lifecycle is covered: search, inspect, quote, understand policies, and create a held booking request with a Stripe checkout URL. However, there is no tool to retrieve an existing booking status or handle cancellation/modification, which are natural lifecycle gaps for a booking domain.
WHEN: use it only after the traveller has (1) picked ONE category and dates, (2) given name, email and phone, and (3) EXPLICITLY accepted the cancellation policy — never set accepted_terms: true on your own. WHAT IT RETURNS: booking_id, checkout_url (a page on beachvalencia.com that shows the breakdown and asks the guest to tick the cancellation policy BEFORE jumping to Stripe), expires_at (ISO 8601, ~30 min in the future), hold_minutes: 30, total/nightly EUR, nights, guests, property, deposit, cancellation summary, terms_url, idempotent (true if a prior request with the same category+dates+pax+email was replayed), and a message ready to show to the guest. PAYMENT: always on Stripe, hosted at beachvalencia.com. The agent NEVER charges the guest itself. If the hold expires without payment, the unit is released automatically and a new request is needed. The price is the public rate (no member discount, no coupon codes — if the guest has a code, they apply it on the web). IDEMPOTENCY: a replay with the same category, dates, pax and email returns the same booking. EXAMPLE: {"id":"G4","check_in":"2027-05-22","check_out":"2027-05-27","adults":4,"guest_name":"Ada Lovelace","guest_email":"ada@example.com","guest_phone":"+34612345678","language":"en","accepted_terms":true}.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Property/type ID (G1..G6 or G4B). | |
| adults | Yes | Number of adults. | |
| check_in | Yes | Arrival date YYYY-MM-DD (Europe/Madrid). | |
| children | No | Optional list of children ages. Only the count is used to size the property. | |
| language | Yes | Language for the confirmation email and error messages. | |
| check_out | Yes | Departure date YYYY-MM-DD (Europe/Madrid); strictly after check_in. | |
| guest_name | Yes | Guest's full name. | |
| guest_email | Yes | Guest's email — receives the payment link and confirmation. | |
| guest_phone | Yes | Guest's phone number, including country code. | |
| accepted_terms | Yes | Must be true. The agent confirms the traveller accepted the cancellation policy and the terms and conditions. |
| Name | Required | Description |
|---|---|---|
| guests | Yes | |
| nights | Yes | |
| deposit | Yes | |
| message | Yes | |
| currency | Yes | |
| property | Yes | |
| breakdown | No | |
| terms_url | Yes | |
| booking_id | Yes | |
| expires_at | Yes | |
| idempotent | Yes | |
| cancellation | Yes | |
| checkout_url | Yes | |
| hold_minutes | Yes | |
| nightly_avg_eur | No | |
| total_price_eur | Yes | |
| cancellation_details_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past annotations: payment is always on Stripe, the agent never charges, the 30-minute hold auto-releases the unit, price is the public rate with no coupons, and idempotency keys on category+dates+pax+email. These add real behavioral context even though idempotentHint/destructiveHint already flag the safety profile.
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?
Front-loaded with WHEN, then returns, payment, idempotency, and a worked example — a well-ordered structure. Minor waste: the 30-minute hold is stated twice ('~30 min' and 'hold_minutes: 30'), and the return-field list partly duplicates the existing output schema.
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?
For a 10-parameter mutation with real consent and payment consequences, nothing an agent needs is missing: preconditions, consent rule, hold expiry behavior, pricing rules, idempotency, and a concrete example are all present. The output schema covers return shape, so the description's field enumeration is surplus rather than a gap.
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 earns above that by defining the idempotency tuple that actually determines replay behavior and by making the accepted_terms semantics a consent rule rather than a plain boolean. It stops short of 5 because per-parameter formats remain the schema's job.
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?
A specific verb+resource ('create booking request') whose WHEN clause makes the position in the booking flow unambiguous relative to search_availability and get_quote. An agent knows exactly what is being produced (a booking_id plus a hosted checkout_url).
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 WHEN block lays out three hard preconditions (category+dates chosen, contact details gathered, explicit policy acceptance) and an explicit prohibition ('never set accepted_terms: true on your own'). This is a genuine when/when-not rule rather than an implied flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WHEN: use it whenever the traveller asks about cancellation, deposit, check-in/out times, or Spanish traveller registration ("what time can I arrive?", "is there a deposit?", "what if I cancel 10 days before?"). WHAT IT RETURNS: check_in (from 16:00 Europe/Madrid), check_out (by 11:00), cancellation.summary (free up to 14 calendar days before arrival) + cancellation.details_url, deposit (50 € refundable in pool/garage units), online_check_in (SES.Hospedajes link by email), and contact (reservas@beachvalencia.com). EXAMPLE: {"language":"en"}.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Response language. Defaults to en. |
| Name | Required | Description |
|---|---|---|
| contact | Yes | |
| deposit | Yes | |
| check_in | Yes | |
| check_out | Yes | |
| cancellation | Yes | |
| online_check_in | Yes |
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. The description adds beyond them by enumerating the returned policy domains and noting the language switch, though it does not say whether policy values are static or property-specific, which matters if the catalogue has multiple units.
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?
Front-loaded with WHEN, then WHAT IT RETURNS, then EXAMPLE — a scannable structure with no filler sentences. The one weakness is that it inlines hardcoded policy values (16:00 check-in, 11:00 checkout, 14-day window, 50 € deposit) that duplicate the output schema and will silently go stale if policy changes.
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?
An output schema exists, yet the description still names the key fields an agent will need to quote. With a single optional enum parameter and full annotation coverage, nothing required to call or interpret this tool is missing.
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 enum is documented, so the schema does the heavy lifting and the baseline of 3 applies. The trailing example {"language":"en"} restates the same information without adding format or fallback semantics beyond the schema's 'Defaults to en.'
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 resource (cancellation/deposit/check-in policies) and anchors it to concrete traveller questions, so an agent knows exactly what it retrieves. It does not name or contrast itself with get_property_details or get_quote, so the boundary with siblings is only implicit.
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 'WHEN' clause gives explicit trigger phrasings ('what time can I arrive?', 'is there a deposit?', 'what if I cancel 10 days before?') that map cleanly to invocation. There are no exclusions or named alternatives, so an agent must infer that pricing goes to get_quote rather than being told.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WHEN: use it after search_availability when the traveller wants to compare or see more detail about one specific category, or asks "tell me more about G4". WHAT IT RETURNS: description, max_guests, bedrooms (text + count), size_sqm, zone, generic location ("La Patacona, Alboraya — 30 m from the sea" / "Valencia city, close to the centre"), location_summary (how long to the old town, tram, airport…), highlights (terrace, sea views, pool, parking, m²), amenities (parking, pool_seasonal), up to 3 photos, trust (same block as search_availability), a booking_url_base to open the listing with no dates, and the Priority note. DO NOT ask here for the exact street address or access codes: they are only sent to the guest by email after a booking is confirmed. EXAMPLE: {"id":"G4","language":"en"}.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Property/type ID (G1..G6 or G4B). | |
| language | No | Response language. Defaults to en. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| name | Yes | |
| zone | Yes | |
| trust | Yes | |
| photos | Yes | |
| bedrooms | Yes | |
| location | Yes | |
| size_sqm | Yes | |
| amenities | Yes | |
| highlights | Yes | |
| max_guests | Yes | |
| description | Yes | |
| priority_url | Yes | |
| priority_note | Yes | |
| bedrooms_count | Yes | |
| booking_url_base | Yes | |
| location_summary | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare read-only, idempotent, closed-world, and non-destructive behavior. The description adds useful behavioral context beyond those annotations: it explains the return content, the privacy boundary around address/access codes, the booking URL base, and the trust/Priority notes.
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 description is front-loaded with WHEN, then returns, exclusions, and an example, which makes it easy to scan. It is somewhat lengthy because it enumerates many return fields even though an output schema exists, but the structure keeps the extra detail useful rather than noisy.
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?
Given the read-only annotations, full schema coverage, and existing output schema, the description is complete enough for reliable selection and invocation. It covers when to call it, what it returns, what not to ask for, and a concrete example.
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 both `id` and `language` are already well documented in the schema. The description adds an example invocation with `id: G4` and `language: en`, but this is only marginal additional semantic guidance, so the baseline of 3 is appropriate.
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 states a specific retrieval action for one property/category ID and clearly distinguishes it from its predecessor `search_availability`. It also enumerates the kinds of details returned, so the agent can understand the tool’s scope without opening the output schema.
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 gives explicit WHEN guidance: use it after `search_availability` when the traveller wants to compare or see more detail about one specific category. It also gives an explicit DO NOT: do not ask here for exact street address or access codes, which are sent post-booking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WHEN: use it when the traveller fixes ONE category and wants the exact total for a given date range ("how much is G4 from 8 to 15 June for 6?"). WHAT IT RETURNS: available boolean, total_price_eur, nightly_avg_eur, nights, guests, deposit, cancellation summary, cancellation_details_url, booking_url. When not available, available: false and the booking_url falls back to the search page (plus hint to call search_availability). The price is the public rate charged at checkout to a non-member with no discount code — if the traveller has a code, they enter it themselves on beachvalencia.com. EXAMPLE: {"id":"G4","check_in":"2027-06-08","check_out":"2027-06-15","adults":6}.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Property/type ID (G1..G6 or G4B). | |
| adults | Yes | ||
| check_in | Yes | Arrival date YYYY-MM-DD. | |
| children | No | ||
| language | No | ||
| check_out | Yes | Departure date YYYY-MM-DD. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| hint | No | |
| name | Yes | |
| guests | Yes | |
| nights | Yes | |
| deposit | Yes | |
| check_in | Yes | |
| currency | Yes | |
| available | Yes | |
| check_out | Yes | |
| booking_url | Yes | |
| cancellation | Yes | |
| discount_note | No | |
| min_stay_nights | No | |
| nightly_avg_eur | No | |
| total_price_eur | No | |
| public_price_eur | No | |
| cancellation_details_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent safety, yet the description adds substantive behavior: the price is the public checkout rate for a non-member with no discount code, and on unavailability `available` is false with `booking_url` falling back to the search page plus a hint. That is exactly the kind of context annotations cannot carry.
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?
Front-loaded WHEN / WHAT IT RETURNS / EXAMPLE structure, every sentence bearing information an agent needs. No restatement of the tool title or filler.
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?
Covers trigger, return payload, unavailability path, pricing semantics and a concrete call example — the whole decision loop for invoking this tool. The optional `children`/`language` gap is the only soft spot.
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 50%, so the description must compensate — and it does for the four required fields via the worked example and the date-range framing. `children` and `language` remain unmentioned in both description and schema, which keeps it below a 5.
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 (get an exact quote/total price) with the precise scenario: one fixed category plus a date range and guest count. The example question "how much is G4 from 8 to 15 June for 6?" makes the purpose unmistakable and separates it from search_availability.
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 WHEN block gives a clear trigger condition (traveller has fixed ONE category and wants the exact total), and the fallback hint routes the agent to search_availability when the result is unavailable. It stops short of an explicit 'do not use this for browsing multiple categories' exclusion, but the routing is effectively covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WHEN: use it whenever the traveller asks "what do you have from X to Y for N people" or shows date flexibility. WHAT IT RETURNS: matches[] with one entry per available category (G1..G6, G4B) ordered by total price, including name, zone (beach/city), bedrooms, m², highlights, location summary, photos, total/nightly EUR price (public rate, no discount code) and a booking_url with dates+pax prefilled. Also alternatives[] (up to 6, each with reason like "same dates, other category" or "2 days earlier, same category") when matches are empty or flexible_days > 0, minimum_stay_only[] for categories that would be available with a longer stay, no_results_reason when nothing applies, and trust (rating 9.4/10, 320+ Booking reviews, cheaper than Booking.com, Stripe payment, 14-day free cancellation, languages supported). Direct prices are BELOW Booking.com for the same dates. FLEXIBLE PARAMETERS: flexible_days (0–3, default 0) shifts the check-in by ±N days to broaden alternatives; budget_eur filters matches and alternatives by TOTAL EUR; zone ("beach" | "city" | "any", default "any"); min_bedrooms (default 1 — a sofa bed does not count). EXAMPLE: {"check_in":"2027-05-22","check_out":"2027-05-27","adults":4,"flexible_days":2,"budget_eur":900,"zone":"beach","min_bedrooms":2}.
| Name | Required | Description | Default |
|---|---|---|---|
| zone | No | Filter by zone: beach = La Patacona (G1..G5, G4B); city = Valencia city (G6); any = both (default). | |
| adults | Yes | Number of adults. | |
| check_in | Yes | Arrival date (YYYY-MM-DD, Europe/Madrid). | |
| children | No | Optional list of children ages. Only the count is used to size the property. | |
| language | No | Response language. Defaults to en if omitted or unsupported. | |
| check_out | Yes | Departure date (YYYY-MM-DD, Europe/Madrid); must be strictly after check_in. | |
| budget_eur | No | Max TOTAL price in EUR for the whole stay. Filters both matches and alternatives. | |
| min_bedrooms | No | Minimum number of bedrooms (1 by default — a sofa bed does not count). | |
| flexible_days | No | Shift the check-in by ±N days (0..3) to find alternatives if the exact dates are not available. Default 0. |
| Name | Required | Description |
|---|---|---|
| trust | Yes | |
| guests | Yes | |
| nights | Yes | |
| matches | Yes | |
| check_in | Yes | |
| currency | Yes | |
| check_out | Yes | |
| alternatives | Yes | Up to 6 alternatives (other dates ±flexible_days or other categories) when matches are empty or the agent asked for flexibility. |
| priority_url | Yes | |
| priority_note | Yes | |
| minimum_stay_only | Yes | Properties that would be available if the stay met the minimum-nights rule. |
| no_results_reason | No | Human-readable reason when both matches and alternatives are empty (e.g. all over minimum_stay or over budget). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the bar is lower. The description still adds real behavior: alternatives[] appears when matches are empty or flexible_days > 0, minimum_stay_only[] flags longer-stay-only categories, and the price is stated to be below Booking.com — though much of the returns prose repeats what the output schema already supplies.
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?
It is front-loaded with WHEN and WHAT IT RETURNS labels, which is good structure. However, the long returns block enumerates matches[] fields that the output schema already documents, so a meaningful share of the text does not earn its place for an agent that can read the schema.
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 an output schema present, annotations covering safety hints, and 100% parameter coverage, the description only needs to add trigger conditions and behavioral expectations — which it does, including empty-result handling, price positioning, and trust signals.
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 baseline is 3; the description goes modestly beyond by clarifying that budget_eur filters on TOTAL stay price (not nightly) across both matches and alternatives, and by giving a fully worked parameter example with realistic values. The per-parameter definitions themselves are mostly duplicated from 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?
The description states a concrete verb and resource and frames the exact user question it answers ("what do you have from X to Y for N people"). It also implicitly differentiates from the get_quote sibling via "public rate, no discount code," so an agent can tell the two apart.
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 "WHEN" clause gives an explicit trigger, including date flexibility, and the FLEXIBLE PARAMETERS block explains when to widen a search with flexible_days. It stops short of naming when NOT to call it (e.g., when the traveller is ready for a firm price and get_quote is the right sibling).
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.
create_booking_requestget_property_details5 fields changedOutput schema / properties / bedrooms_countAdded value: +{
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+}Output schema / properties / location_summaryAdded value: +{
+ "type": "string"
+}Output schema / properties / trustAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "cancellation_note": {
+ "type": "string"
+ },
+ "languages_spoken": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "parity_note": {
+ "type": "string"
+ },
+ "payment_note": {
+ "type": "string"
+ },
+ "rating_best": {
+ "type": "number"
+ },
+ "rating_count": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "rating_source": {
+ "const": "Booking.com",
+ "type": "string"
+ },
+ "rating_value": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "rating_value",
+ "rating_best",
+ "rating_count",
+ "rating_source",
+ "parity_note",
+ "cancellation_note",
+ "payment_note",
+ "languages_spoken"
+ ],
+ "type": "object"
+}Output schema / properties / zoneAdded value: +{
+ "enum": [
+ "beach",
+ "city"
+ ],
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "id",
- "name",
- "max_guests",
- "bedrooms",
- "size_sqm",
- "location",
- "highlights",
- "description",
- "amenities",
- "photos",
- "booking_url_base",
- "priority_note",
- "priority_url"
-]New value: +[
+ "id",
+ "name",
+ "zone",
+ "max_guests",
+ "bedrooms",
+ "bedrooms_count",
+ "size_sqm",
+ "location",
+ "location_summary",
+ "highlights",
+ "description",
+ "amenities",
+ "photos",
+ "booking_url_base",
+ "trust",
+ "priority_note",
+ "priority_url"
+]search_availability12 fields changedInput schema / properties / budget_eurAdded value: +{
+ "description": "Max TOTAL price in EUR for the whole stay. Filters both matches and alternatives.",
+ "exclusiveMinimum": 0,
+ "maximum": 100000,
+ "type": "number"
+}Input schema / properties / flexible_daysAdded value: +{
+ "description": "Shift the check-in by ±N days (0..3) to find alternatives if the exact dates are not available. Default 0.",
+ "maximum": 3,
+ "minimum": 0,
+ "type": "integer"
+}Input schema / properties / min_bedroomsAdded value: +{
+ "description": "Minimum number of bedrooms (1 by default — a sofa bed does not count).",
+ "maximum": 5,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / zoneAdded value: +{
+ "description": "Filter by zone: beach = La Patacona (G1..G5, G4B); city = Valencia city (G6); any = both (default).",
+ "enum": [
+ "beach",
+ "city",
+ "any"
+ ],
+ "type": "string"
+}Output schema / properties / alternativesAdded value: +{
+ "description": "Up to 6 alternatives (other dates ±flexible_days or other categories) when matches are empty or the agent asked for flexibility.",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "booking_url": {
+ "type": "string"
+ },
+ "check_in": {
+ "type": "string"
+ },
+ "check_out": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "nights": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "reason_code": {
+ "enum": [
+ "same_dates_other_category",
+ "other_dates_same_category",
+ "other_dates_other_category"
+ ],
+ "type": "string"
+ },
+ "total_price_eur": {
+ "type": "number"
+ },
+ "zone": {
+ "enum": [
+ "beach",
+ "city"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "zone",
+ "check_in",
+ "check_out",
+ "nights",
+ "total_price_eur",
+ "reason",
+ "reason_code",
+ "booking_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / matches / items / properties / bedrooms_countAdded value: +{
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+}Output schema / properties / matches / items / properties / location_summaryAdded value: +{
+ "type": "string"
+}Output schema / properties / matches / items / properties / zoneAdded value: +{
+ "enum": [
+ "beach",
+ "city"
+ ],
+ "type": "string"
+}Output schema / properties / matches / items / requiredPrevious value: -[
- "id",
- "name",
- "max_guests",
- "bedrooms",
- "location",
- "highlights",
- "total_price_eur",
- "nightly_avg_eur",
- "nights",
- "photos",
- "booking_url"
-]New value: +[
+ "id",
+ "name",
+ "zone",
+ "max_guests",
+ "bedrooms",
+ "bedrooms_count",
+ "location",
+ "location_summary",
+ "highlights",
+ "total_price_eur",
+ "nightly_avg_eur",
+ "nights",
+ "photos",
+ "booking_url"
+]Output schema / properties / no_results_reasonAdded value: +{
+ "description": "Human-readable reason when both matches and alternatives are empty (e.g. all over minimum_stay or over budget).",
+ "type": "string"
+}Output schema / properties / trustAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "cancellation_note": {
+ "type": "string"
+ },
+ "languages_spoken": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "parity_note": {
+ "type": "string"
+ },
+ "payment_note": {
+ "type": "string"
+ },
+ "rating_best": {
+ "type": "number"
+ },
+ "rating_count": {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ "rating_source": {
+ "const": "Booking.com",
+ "type": "string"
+ },
+ "rating_value": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "rating_value",
+ "rating_best",
+ "rating_count",
+ "rating_source",
+ "parity_note",
+ "cancellation_note",
+ "payment_note",
+ "languages_spoken"
+ ],
+ "type": "object"
+}Output schema / requiredPrevious value: -[
- "currency",
- "check_in",
- "check_out",
- "nights",
- "guests",
- "matches",
- "minimum_stay_only",
- "priority_note",
- "priority_url"
-]New value: +[
+ "currency",
+ "check_in",
+ "check_out",
+ "nights",
+ "guests",
+ "matches",
+ "minimum_stay_only",
+ "alternatives",
+ "trust",
+ "priority_note",
+ "priority_url"
+]get_policiesget_property_detailsget_quotesearch_availabilityHoliday rentals booked direct with the host: availability, prices, checkout links. No auth.
Search vacation rentals in La Palma, Canary Islands with real-time availability and pricing.
Mar Egeu holiday rentals and travel info via AI agents
Search 18,000+ privately owned holiday homes on Ferienhausmiete.de: exact stay prices, availability
Add one secure layer between your agents and this server.
