Luxury crewed catamaran charter in the BVI: availability, published-rate quotes and hold requests.
Scored across 7 tools
Most tools target clearly distinct actions (facts lookup, quote, hold, fallback). The main overlap is check_availability vs find_open_windows, both about open dates, and ask_owner vs request_hold, both routing to the owner. Descriptions disambiguate these well (specific dates vs flexible ranges; question vs formal hold), so confusion is limited.
All tools follow a consistent verb_noun snake_case pattern: ask_owner, check_availability, find_open_windows, get_dream_on_facts, get_quote, request_hold, suggest_other_yachts. get_dream_on_facts is slightly longer but still fits the convention.
Seven tools is well-scoped for a charter concierge: discovery, availability, pricing, hold, escalation, and fallback are each single-purpose. No redundant or trivial tools inflate the set.
The surface covers the full guest-facing lifecycle from facts to availability, quote, hold request, owner escalation, and a fallback to sister yachts. Minor gaps exist around post-hold actions (modifying/cancelling a hold, confirming booking), but the core pre-booking workflow is complete.
Pass a question or request to the owner when the fact sheet doesn't cover it (holiday pricing, discounts, contract/payment/cancellation terms, longer or shorter stays, special services, anything else). The guest's email is on file and used automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | crew_question when the guest wants to ask Captain Rob or Chef Julia something (menus, diets, diving, itinerary ideas) — the owner forwards it to the crew; referral_lead for groups over 8 or 5-cabin/10-passenger requests | |
| name | No | Guest's name | |
| No | Guest's email for the owner's reply (defaults to the email the guest gave at the start) | ||
| context | No | Dates, party size and anything else relevant from the conversation | |
| question | Yes | The guest's question or request, in full | |
| requester | No | Optional: who this request is for, so the owner can follow up personally. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-read-only, non-destructive, non-idempotent, so the safety profile is covered. The description adds that the guest email is on file and applied automatically, which is useful, but it says nothing about what happens after the handoff (owner reply channel, latency, whether the agent sees a confirmation) or that repeated calls create separate messages.
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 tight sentences, front-loaded with the when-to-use condition before the parenthetical examples. No filler and nothing that restates 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?
Covers the escalation intent and the auto-filled email for a 6-parameter tool with a nested requester object. Since there is no output schema, it could say more about the expected response or turnaround, but for a fire-and-forget handoff tool it is largely sufficient.
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% and the 'kind' enum is fully documented with routing rules, including the crew_question and referral_lead thresholds. The description's example list parallels that content without adding syntax or format guidance for name/context/requester, so the schema does the heavy lifting.
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 ('Pass a question or request to the owner') and scopes it precisely to cases the fact sheet doesn't cover. This distinguishes it from get_dream_on_facts and the other lookup/booking siblings, which all operate on structured inventory rather than human escalation.
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 the triggering condition explicitly ('when the fact sheet doesn't cover it') plus a concrete enumeration of qualifying cases (holiday pricing, discounts, contract/payment/cancellation terms, longer/shorter stays, special services). The fact-sheet qualifier doubles as a when-not rule, so the agent knows to try the facts tool first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether specific dates are open (48-hour turnaround applied). If not open, returns suggested_open_windows nearby — always offer those to the guest.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | Disembarkation date (YYYY-MM-DD) | |
| start | Yes | Embarkation date (YYYY-MM-DD) | |
| nights | No | Use instead of end | |
| requester | No | Optional: who this request is for, so the owner can follow up personally. |
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 genuine behavioral context beyond that: the 48-hour turnaround constraint and the fact that a negative result yields suggested_open_windows. It doesn't clarify pagination or what 'open' precisely means, so not a 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?
Two front-loaded sentences with no filler; the core check comes first and the fallback behavior second. The closing imperative is slightly operational rather than descriptive, but it earns its place by preventing a mishandled response.
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 partially compensates by describing the suggested_open_windows return on failure. It leaves open what an 'open' result looks like and omits follow-up paths like request_hold, but is otherwise sufficient for a read-only availability check.
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 start/end/nights/requester are all documented in the schema itself. The description adds no parameter meaning (e.g., no relationship between nights and end, no note on the nested requester object), so baseline 3 applies.
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 ('Check whether specific dates are open') and scopes it with the 48-hour turnaround rule. An agent can distinguish this from siblings like find_open_windows or request_hold without opening a 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 clear context for the failure path ('If not open, returns suggested_open_windows nearby — always offer those to the guest'), which is actionable usage guidance. It stops short of explicitly contrasting when to call this versus find_open_windows or request_hold, so no explicit alternative routing or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List open windows between two dates (e.g. a whole month or season) for charters of at least min_nights. Use when the guest is flexible or asks what's open.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Search to (YYYY-MM-DD) | |
| from | Yes | Search from (YYYY-MM-DD) | |
| requester | No | Optional: who this request is for, so the owner can follow up personally. | |
| min_nights | No | Minimum nights (5–7 typical) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and scope are covered by structured data. The description usefully adds that this is a range/season-scale query filtered by a minimum-nights threshold, but says nothing about result shape, granularity of returned windows, or how the requester block is used.
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 short sentences, zero filler, with the core capability front-loaded and the usage cue second. Nothing could be removed without losing 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?
With no output schema, the description still gives an adequate picture of the query (date range plus minimum nights) and when to reach for it. The nested requester object's follow-up purpose is left entirely to the schema, which is a minor gap rather than a blocking one.
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 from/to formats, the requester object, and min_nights are already documented in the schema. The description reinforces min_nights as a filter and characterizes the range scale ('a whole month or season'), which is mild added value over the schema but not beyond the baseline.
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 ('List open windows between two dates') plus a qualifying constraint ('for charters of at least min_nights'). It is distinguishable from a point-in-time availability check, though it never names the sibling check_availability to sharpen the contrast.
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 situational context: 'Use when the guest is flexible or asks what's open.' That tells the agent the query shape this tool is for, but offers no exclusions or explicit routing versus check_availability or suggest_other_yachts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return Dream On's published fact sheet: the yacht, cabins, toys, amenities, crew, what's included, rates rules, booking process, sample itinerary and FAQ. This is the ONLY source of truth for answers.
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | Optional section: vessel, crew, inclusions, rates, booking, sample_itinerary, faq, contact. Omit for everything. | |
| requester | No | Optional: who this request is for, so the owner can follow up personally. |
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 usefully adds that the content is a canonical published fact sheet, but with no output schema it stops short of describing the response shape (flat sections vs. nested), and says nothing about the requester/owner-follow-up behavior embedded in the 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?
Two sentences, front-loaded with the verb and resource, and the exclusivity claim lands at the end where it has the most routing impact. The long middle enumeration is dense but each item is a real section the caller may request, so it earns its space.
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, zero-required-parameter reference tool with no output schema, the description covers what is returned, how to narrow it (sections), and why it should be preferred for factual answers. An agent has everything needed to call it 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 100%, so the schema already documents both the `section` enum values and the `requester` object/occasion fields. The description's section list roughly mirrors the schema enum but adds no syntax or behavioral detail beyond it, so the baseline 3 applies.
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 ('Return') and resource ('Dream On's published fact sheet') and then enumerates the exact sections covered (vessel, crew, inclusions, rates, booking, itinerary, FAQ). It further positions itself against the transactional siblings by declaring itself 'the ONLY source of truth for answers', so an agent can tell what this returns versus ask_owner/get_quote.
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?
'This is the ONLY source of truth for answers' gives a clear directive that this is the reference tool for factual questions, implicitly steering the agent away from ask_owner or get_quote for that purpose. It does not, however, explicitly state when to prefer ask_owner or other siblings, nor any exclusion or prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate the all-inclusive charter fee from the published rate rules. If priced=false and refer_to_owner=true, do not invent a price — offer to pass the question to the owner with ask_owner.
| Name | Required | Description | Default |
|---|---|---|---|
| start | Yes | Embarkation date (YYYY-MM-DD) | |
| guests | Yes | Number of guests (max 8) | |
| nights | Yes | Number of nights | |
| requester | No | Optional: who this request is for, so the owner can follow up personally. |
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 new behavioral context: the tool can return an indeterminate result and the agent must not fabricate a price, plus the scope of the quote ('all-inclusive charter fee'). It does not mention permissions or whether the returned estimate is binding.
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, no filler, with the core action first and the fallback rule second. Every clause carries actionable content.
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?
There is no output schema, so the description is the only source of return-value information; it references the fields priced and refer_to_owner without describing the rest of the quote payload (fee breakdown, validity, currency). Given a nested-object input and unbounded output, more disclosure about the response shape would help.
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%, including the optional nested requester object, so the schema carries the parameter burden. The description adds no additional meaning about guests, nights, start, or how requester fields influence pricing, which is the expected baseline when the schema is complete.
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?
Names a specific verb and resource ('Estimate the all-inclusive charter fee from the published rate rules'), which tells the agent exactly what is computed and from what source. It also distinguishes itself from the sibling ask_owner by naming the condition that routes there instead.
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 states a when-not case (priced=false and refer_to_owner=true) and the correct alternative (offer to pass the question to the owner with ask_owner). It does not address other siblings like check_availability or suggest_other_yachts, but the primary routing decision is covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pass a complimentary 48-hour HOLD REQUEST to the owner, who arranges it with Paradise Yacht Clearing (our clearing house). This does NOT confirm anything: Paradise checks the calendar, places the hold and sends the charter contract. Only call after the guest has given their name, email, dates and party size and asked you to request the hold.
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | Disembarkation date (YYYY-MM-DD) | |
| name | Yes | Guest's full name | |
| No | Guest's email (defaults to the email the guest gave at the start) | ||
| notes | No | Occasion, preferences or questions for Paradise (optional) | |
| phone | No | Guest's phone (optional) | |
| start | Yes | Embarkation date (YYYY-MM-DD) | |
| broker | No | Name of the broker or travel advisor they work with, if any | |
| guests | Yes | Number of guests | |
| requester | No | Optional: who this request is for, so the owner can follow up personally. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), and the description adds real behavioral context beyond them: the request is complimentary, it is routed to the owner who works with Paradise Yacht Clearing, and the downstream sequence is calendar check then hold then charter contract. It does not say what happens if the request is submitted twice or how long before the hold lapses, but the non-confirmation semantics are unusually well disclosed.
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 short sentences, zero filler. The action is front-loaded, the non-confirmation caveat follows immediately, and the invocation precondition closes it out. Every sentence 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?
For a mutation tool with no output schema, the description adequately explains that there is no immediate result other than a request being passed along, and that the contract comes later from Paradise. The nested requester object and optional fields are left entirely to the schema, which is reasonable at 100% coverage, though a note on duplicate submissions would round it out.
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 schema already documents all nine parameters, including the nested requester object. The description reinforces the required set (name, email, dates, party size) but adds no format, default, or constraint detail beyond what the schema states. Baseline 3 applies when the schema does the heavy lifting.
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 verb and resource (pass a 48-hour hold request to the owner) and immediately scopes what it is not: 'This does NOT confirm anything.' That distinguishes it cleanly from check_availability and get_quote, which are inquiry tools, without the agent needing to open any 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 an explicit precondition for invocation: only call after the guest has supplied name, email, dates and party size and has asked for the hold. The 'does NOT confirm anything' line also tells the agent not to treat it as a booking. It stops short of naming a sibling tool to use instead when the precondition isn't met, so it is clear context rather than full when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Only after Dream On's own options don't work — the group is larger than 8, or none of Dream On's open dates suit the guest — return a link to Islands & Sails, Dream On's sister concierge (run by Dream On's owner), pre-filled with the guest's dates and party size, where they can explore other hand-picked BVI crewed yachts.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Short note on what they want (occasion, style), optional | |
| start | No | Preferred start date — always include it when the guest has named dates or a period (e.g. 'the last week of May 2027' → 2027-05-22 with nights 7) (YYYY-MM-DD) | |
| guests | No | Party size, if known | |
| nights | No | Number of nights, if known | |
| requester | No | Optional: who this request is for, so the owner can follow up personally. |
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 real context beyond that: the link is pre-filled with the guest's dates and party size, the destination is owner-operated (trust-relevant), and this is a fallback rather than a primary path. It does not describe failure modes or whether the referral is logged.
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 sentence, but efficiently structured with the precondition front-loaded ahead of the action and payload. Every clause carries information (trigger, destination, ownership, pre-fill), though the parenthetical aside about the owner makes it slightly denser than necessary.
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 zero required parameters, full schema coverage and no output schema, the description covers the essential contract: when to call it and what it returns (a pre-filled referral link). It could still say whether any confirmation or follow-up is generated, but nothing critical for correct invocation 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 100%, so the schema already explains start, guests, nights, note and the nested requester object. The description only echoes that dates and party size are used to pre-fill the link — modest added value over the schema. Baseline 3 applies.
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 verb ('return a link') and resource (Islands & Sails referral link from Dream On's sister concierge), plus what the link is pre-filled with. It is unmistakably distinct from siblings like check_availability, find_open_windows or get_quote, which all operate on Dream On itself.
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 an explicit precondition ('Only after Dream On's own options don't work') and enumerates the two triggering conditions (group larger than 8, or no suitable open dates). This is exactly the when-to-use/when-not guidance an agent needs to route correctly.
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_owner1 field changedInput schema / properties / kind / descriptionPrevious value: -"crew_question when the guest wants to ask Captain Rob or Chef Julia something (menus, diets, diving, itinerary ideas) — the owner forwards it and the crew may reply directly; referral_lead for groups over 8 or 5-cabin/10-passenger requests"New value: +"crew_question when the guest wants to ask Captain Rob or Chef Julia something (menus, diets, diving, itinerary ideas) — the owner forwards it to the crew; referral_lead for groups over 8 or 5-cabin/10-passenger requests"ask_owner2 fields changedInput schema / properties / kind / descriptionPrevious value: -"referral_lead for groups over 8 or 5-cabin/10-passenger requests that the owner can refer to another yacht"New value: +"crew_question when the guest wants to ask Captain Rob or Chef Julia something (menus, diets, diving, itinerary ideas) — the owner forwards it and the crew may reply directly; referral_lead for groups over 8 or 5-cabin/10-passenger requests"Input schema / properties / kind / enumPrevious value: -[
- "question",
- "referral_lead"
-]New value: +[
+ "question",
+ "referral_lead",
+ "crew_question"
+]suggest_other_yachtsask_ownercheck_availabilityfind_open_windowsget_dream_on_factsget_quoterequest_holdSearch hand-picked BVI crewed charter yachts by budget, size, activities and travel style.
Live prices, free weeks and deals on 9,000+ charter yachts from 800+ operators in 50 countries.
Search 14,000+ charter boats with live prices, plus marinas, anchorages, routes and itineraries.
Live discounted yacht charters in 11 destinations: search, price checks, trip cost, routes.
Add one secure layer between your agents and this server.
