Search and book verified independent vacation rentals directly from hosts, with no guest fees.
Scored across 10 tools
Most tools target distinct resources or actions, but ask_host and send_message both involve sending communication to the host, which could cause confusion. The descriptions hint at a distinction (ask_host for pre-booking property questions, send_message for booking-related messages), but an agent may still misselect when a question could fit either.
All tool names follow a consistent verb_noun snake_case pattern (e.g., get_booking, request_booking, cancel_booking). Retrieval tools uniformly use get_*, and the naming is predictable and easy to parse.
With 10 tools, the set is well-scoped for a vacation rental booking assistant. Each tool covers a distinct step in the search-to-booking workflow, and there is no obvious redundancy or missing critical operation.
The surface covers the core booking lifecycle: search, property details, availability, quote, request, cancel, and messaging. Minor gaps exist, such as no tool to list a guest's existing bookings or modify a booking, but these may be outside the intended scope and can be worked around.
Send a question the property record and FAQ don't answer. The answer arrives later; tell the guest you'll follow up. Don't include the guest's contact details. Maps to POST /v1/properties/{id}/questions.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | ||
| property_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say this is a non-destructive, open-world write. The description adds genuinely new behavior: the reply is asynchronous ('the answer arrives later'), the agent must tell the guest it will follow up, and guest contact details must be excluded from the payload. These are operational facts the agent cannot get from the annotations or schema.
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?
Three tight sentences: purpose first, then the async/follow-up behavior, then the privacy constraint, with the endpoint mapping last. Nothing is redundant and every clause carries information.
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 two-parameter async write with annotations covering the safety profile and no output schema, the description covers the essentials: when to use it, that no answer comes back immediately, and what not to send. It could still say more about the required property_id and the length limit, but nothing critical to calling it correctly 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 description coverage is 0%, so the description must carry parameter meaning. It only implicitly indicates the 'question' content (a question, no contact details) and says nothing about property_id semantics, the 500-character cap, or expected formats. Two undocumented parameters leave real gaps.
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 (send) and resource (a question to the host) and frames it as an escalation path: only for questions the property record and FAQ don't answer. That scope clause also distinguishes it from the sibling send_message tool, which handles ordinary guest messaging.
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?
Gives a clear when-to-use condition ('questions the property record and FAQ don't answer') and a privacy caveat about contact details. It stops short of naming the sibling it replaces (send_message) or stating when-not to escalate to the host, so an agent must infer that boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Two-step. First call with confirm=false to see what the guest gets back if they cancel now (nothing changes). Tell the guest that refund and get their go-ahead, then call again with confirm=true and expected_refund_cents set to the refund amount from the first call. If the refund changed in between, the call fails with refund_changed instead of cancelling. Refunds go to the guest's card automatically. Pass guest_email (the email the booking was made with) unless you connect with an agent token.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | Yes | ||
| booking_id | Yes | ||
| guest_email | No | ||
| expected_refund_cents | No | Required when confirm is true: refund.amount from the confirm=false call. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructive/openWorld/idempotent, but the description adds critical context: the confirm=false call is non-mutating ('nothing changes'), refunds auto-post to the guest's card, and a mid-flight refund change fails with 'refund_changed' instead of cancelling. That failure-mode and side-effect disclosure is exactly what annotations alone don't convey.
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 'Two-step' and then walks the workflow in tight sentences with no filler. It is slightly dense/long for a single tool but every clause carries operational weight.
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?
No output schema exists, so the description carries the return burden and does — it explains what the confirm=false call returns (the refund the guest gets back). Combined with the failure mode and auth note, an agent has everything needed to call both steps correctly.
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 only 25% schema coverage the description must compensate, and it does: it defines the confirm flag semantics, ties expected_refund_cents to the value from the first call, and explains guest_email as 'the email the booking was made with' with the agent-token exception. Only booking_id is left to obvious inference.
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 ('cancel a booking') and immediately adds a distinctive two-step workflow that no sibling (all read/get/send tools) shares. An agent can tell this apart from get_booking or request_booking without opening the 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?
Gives explicit sequencing: call with confirm=false first, get guest go-ahead, then confirm=true with expected_refund_cents. It also states an auth exception ('unless you connect with an agent token'). It stops short of naming sibling alternatives, so it lands just below the top.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Day-by-day availability and indicative nightly prices for up to 180 days. Cached; use get_quote to confirm. Useful when the guest's dates are flexible. Maps to GET /v1/properties/{id}/availability.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Exclusive | |
| from | Yes | ||
| property_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations give readOnlyHint=true and openWorldHint=false, so safety is covered. The description goes further by disclosing that results are cached and that prices are indicative, not final, plus the 180-day horizon. It omits pagination/truncation behavior, but the freshness caveat is exactly the kind of extra behavioral context this dimension rewards.
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?
Four short sentences, each earning its place: what it returns, freshness caveat, cross-reference, and scope hint. Front-loaded with the payload description.
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 read-only, no-output-schema tool, the description covers return shape (daily rows + indicative prices), freshness, range limit, and the sibling to use for firm pricing. Slightly short on the cache TTL and whether long ranges are truncated, but complete enough to call correctly.
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 only 33% (only 'to' is documented as exclusive). The description compensates by establishing the 180-day range horizon and the day-by-day granularity, which explains how from/to are interpreted. property_id remains undocumented, but the added range semantics go meaningfully beyond the thin 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, resource and granularity: day-by-day availability plus indicative prices over a bounded 180-day window, and even names the underlying HTTP endpoint. An agent can distinguish this from get_quote and get_property without inspecting the 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?
Explicitly routes the agent: use this for flexible dates, use get_quote to confirm prices. Names the alternative and the condition that selects it, so the choice between browsing and quoting is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Status, amounts, refund schedule, guest ID verification link, and when arrival details will be sent. Maps to GET /v1/bookings/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| booking_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=false, so safety is covered. With no output schema, the description carries real weight by disclosing the response contents (refund schedule, verification link, arrival-detail timing), which is genuinely useful behavioral context beyond the annotations.
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?
A single dense fragment listing return fields followed by the endpoint mapping — front-loaded with the payload contents an agent cares about, with no filler. It reads as a noun list rather than a sentence, but nothing is wasted.
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 simple one-parameter read tool, the return-content listing compensates for the missing output schema and the annotations cover safety. What is missing is any usage context (when this beats get_quote/get_property) and error behavior for an invalid or unknown booking_id.
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?
One required parameter with 0% schema description coverage, so the schema alone does not explain booking_id's origin or format. The endpoint mapping implies booking_id is the booking identifier, partially compensating, but no format or source guidance is given.
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 the resource (booking) and enumerates the specific fields returned — status, amounts, refund schedule, guest ID verification link, arrival-details timing — and anchors it to GET /v1/bookings/{id}. An agent can tell this is the booking-detail reader, though it never contrasts itself with siblings like get_quote or get_property.
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 guidance, no prerequisites, and no named alternative. The only routing hint is the REST endpoint mapping, which an agent must infer means 'call this when you already have a booking_id'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The conversation between the guest and the host about a booking, oldest first (including the guest's note with the request and the host's note when accepting or declining). Use it to relay the host's replies. Pass guest_email (the email the booking was made with) unless you connect with an agent token.
| Name | Required | Description | Default |
|---|---|---|---|
| booking_id | Yes | ||
| guest_email | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuine context beyond them: result ordering (oldest first), what the thread contains (request note, accept/decline note), and an auth fork between guest_email and an agent token.
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?
Three sentences, front-loaded with the resource and its ordering, then usage, then parameter guidance. The parenthetical is slightly long but each clause carries information; nothing is redundant with the schema or annotations.
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?
No output schema exists, and the description compensates by describing what the thread returns and in what order. With only two params and read-only annotations, the remaining gap is minor detail like pagination or thread length limits.
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 0%, so the description must carry the load, and it does for guest_email ('the email the booking was made with') plus the agent-token carve-out. booking_id is left unexplained as the obvious identifier, a minor gap but not a blocking one.
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: reads the guest-host conversation about a booking. It also names the scope and ordering ('oldest first, including the guest's note and the host's note'), which distinguishes it from siblings like send_message or ask_host that write to the same thread.
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?
Gives a concrete use case ('Use it to relay the host's replies') and a conditional rule for the credential param ('Pass guest_email ... unless you connect with an agent token'). It does not explicitly name alternative tools, so it stops short of the when-not/alternatives bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full record for one property: beds by room, amenities with details, access and stairs, rules, host FAQ, policies, and verification status. Maps to GET /v1/properties/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| property_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful context by spelling out what the response contains (amenities with details, verification status), but says nothing about failure behavior for an unknown id, permissions, or rate limits.
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, with the content enumeration front-loaded and the API mapping trailing as supporting metadata. Every clause earns its place.
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, this description usefully enumerates the returned record's sections, which is what an agent needs to know before calling. It is close to complete for a simple read-only fetch; only error/not-found behavior and parameter provenance are 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?
There is one parameter with 0% schema description coverage, so the schema contributes nothing. The description implies property_id identifies 'one property' but gives no format, sourcing, or constraint guidance; correct usage relies on the parameter name being self-explanatory.
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 ('Full record for one property') and enumerates the record's contents (beds by room, amenities, access/stairs, rules, host FAQ, policies, verification status). This scope clearly separates it from bulk-listing siblings like search_stays, and the GET endpoint mapping anchors the resource 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?
Usage is only implied: the tool returns details for a single known property, so an agent can infer it is used after a search or when a property_id is already in hand. There is no explicit when-to-use/when-not-to-use statement and no named alternative (e.g., search_stays for discovery).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Itemized, binding price for exact dates and party, after re-checking the host's live calendars. Valid 10 minutes. Returns house rules and an exact refund schedule to show the guest. Does not reserve the dates. Maps to POST /v1/properties/{id}/quotes.
| Name | Required | Description | Default |
|---|---|---|---|
| pets | No | ||
| adults | Yes | ||
| infants | No | ||
| check_in | Yes | ||
| children | No | ||
| check_out | Yes | ||
| property_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint=false). The description adds real value beyond them: it re-checks live host calendars, expires after 10 minutes, returns house rules and a refund schedule, and does not hold inventory. It does not state auth or rate-limit behavior, so 4 rather than 5.
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?
Four dense sentences, each earning its place, with the core purpose and validity constraint front-loaded. No filler or repetition of the 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 and no annotation-level return info, the description usefully declares what comes back (itemized price, house rules, refund schedule). Combined with the no-reservation and expiry notes, an agent has enough to call it correctly, though parameter-level detail is still thin.
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 0% for 7 parameters, so the description must carry the load. 'Exact dates and party' only loosely gestures at check_in/check_out and the guest-count fields, and says nothing about pets, infants, children, or property_id formatting. Most parameters remain undocumented anywhere.
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 with scope: an itemized, binding price for exact dates and party. Clearly differentiated from check_availability (availability only) and request_booking (which reserves), so an agent can route correctly.
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?
Explicitly says 'Does not reserve the dates', which implies the sibling to use when a reservation is wanted, and the 10-minute validity window implies the quote must be acted on promptly. No named alternative is given, so it stops 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.
Request a stay from a quote. Set house_rules_accepted only after the guest has seen and agreed to the quote's house_rules. If the quote's payment.collected_by is "threshold", the booking starts as awaiting_payment and the response includes payment_url (and agent_payment when you can pay with a shared payment token instead): the guest must open payment_url and add a card within 60 minutes, after which the host gets the request (status pending_host_confirmation). Otherwise the request goes to the host immediately and the host arranges payment after accepting. Returns the booking and a status link to give the guest; poll get_booking for changes.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | |||
| phone | No | ||
| quote_id | Yes | ||
| last_name | Yes | ||
| first_name | Yes | ||
| special_requests | No | ||
| house_rules_accepted | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the generic safety profile (not read-only, non-destructive, open-world); the description adds the real behavioral detail: the awaiting_payment branch, the 60-minute card window, the payment_url/agent_payment return, the pending_host_confirmation transition, and immediate host routing otherwise. This is rich context well beyond structured fields.
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-loads the core action in the first sentence, then layers the conditional payment behavior and return/poll guidance. Dense and occasionally run-on, but nearly every clause carries operational value with no 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?
With no output schema, the description carries the return-value burden and does so by naming the booking, status link, payment_url, and agent_payment, plus the get_booking polling path. Missing only prerequisites like auth or quote expiry for full completeness.
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 0% across 7 parameters, so the description must compensate. It clarifies the semantics of house_rules_accepted (a consent gate tied to the quote's rules) and implies quote_id comes from a quote, but says nothing about email, phone, name fields, or special_requests constraints.
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 ('Request a stay from a quote') and names the input that anchors it (quote_id). It is clearly distinguishable from siblings like get_quote, get_booking, and cancel_booking.
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?
Gives explicit conditional guidance: set house_rules_accepted only after the guest has seen and agreed to the rules, and spells out what happens depending on payment.collected_by. It routes the agent to get_booking for polling but does not name other alternative tools or preconditions such as auth.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find verified independent vacation rentals. Filters are strict: every listed amenity must be present. With dates, results include a cached availability signal and an indicative all-in total (no guest service fee). Maps to GET /v1/search.
| Name | Required | Description | Default |
|---|---|---|---|
| pets | No | ||
| limit | No | ||
| place | No | Town and state/country, e.g. 'Asheville, NC'. Use near_lat/near_lng instead when you have coordinates. | |
| adults | No | ||
| infants | No | ||
| check_in | No | ||
| children | No | ||
| near_lat | No | ||
| near_lng | No | ||
| amenities | No | Amenity codes, e.g. hot_tub, wifi, ev_charger, dedicated_workspace, pool, fireplace_wood. | |
| check_out | No | ||
| radius_km | No | ||
| instant_only | No | ||
| min_bedrooms | No | ||
| max_total_usd | No | Maximum all-in total in dollars. Requires dates. | |
| min_wifi_mbps | No | ||
| step_free_entrance | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely useful behavior: strict AND semantics on amenities, a cached (not live) availability signal, an indicative total excluding guest service fees, and the underlying GET /v1/search mapping. It stops short of describing pagination across the 20-item limit.
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?
Three tight, front-loaded sentences with no filler; the strict-filter warning is placed immediately after the purpose. The trailing endpoint mapping is low-value for an agent but costs little.
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 17-parameter, zero-required search tool with no output schema and thin schema descriptions, the definition covers the critical filter semantics but leaves much of the input surface undocumented and does not characterize the result set beyond the availability/total fields.
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 only 18% across 17 parameters, so the description must compensate. It clarifies the most consequential filter semantics ('every listed amenity must be present') and that totals require dates, but leaves pets, infants, instant_only, min_wifi_mbps, step_free_entrance and radius behavior undocumented.
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 ('Find verified independent vacation rentals'), which is clearly distinct from the booking/messaging siblings. It doesn't explicitly name an alternative search route, but the purpose is unambiguous on its own.
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?
No when-to-use or when-not-to-use guidance is given, and no sibling is named as an alternative. The mention that dates yield an availability signal implicitly relates to check_availability, but the relationship is left for the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a message to the host on the guest's behalf, e.g. a question about check-in or a late arrival. Only send what the guest asked you to say. The host is emailed and replies appear in get_messages. Open from the request until two weeks after check-out.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | ||
| booking_id | Yes | ||
| guest_email | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds meaningful behavior beyond the annotations: the message is emailed to the host, replies surface in get_messages, and the tool is only available in a defined window after checkout. Annotations already declare the write/non-destructive/open-world profile, so this description usefully fills in side effects and follow-up location.
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?
Four short sentences, front-loaded with the core purpose, and the examples and window constraint each add real information. No wasted filler, though the sentences are not maximally compressed.
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?
No output schema exists, so the description appropriately explains that replies appear in get_messages and states the availability window. But for a three-parameter write tool it omits essential argument semantics (booking_id, guest_email), leaving the agent to guess.
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 0%, so the description must carry parameter meaning, and it does not. It never explains booking_id or guest_email, and only loosely implies that body should contain the guest's own wording. Two of three parameters are wholly undocumented.
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 ('Send a message to the host on the guest's behalf') and gives concrete examples of the kind of content. However, it never distinguishes itself from the sibling tool ask_host, leaving ambiguity about which messaging tool applies.
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?
Gives clear usage context (questions about check-in, late arrival) and a hard temporal constraint ('Open from the request until two weeks after check-out') plus the constraint 'Only send what the guest asked you to say.' It stops short of naming an alternative or exclusion such as ask_host, so it is clear context without routing guidance.
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.
ask_hostcancel_bookingcheck_availabilityget_bookingget_messagesget_propertyget_quoterequest_bookingsearch_stayssend_messageNatural-language search of 70,000+ vacation rentals, with the host's direct booking link.
Book vacation rentals direct: search homes, check live availability, get a real total.
Search verified Greek vacation rentals with live availability, prices, policies, and booking links.
Search hotels & rentals: live prices & reviews across Booking.com, Airbnb, Vrbo & Google Hotels.
Add one secure layer between your agents and this server.
