Discover Lake Michigan charter captains & boats, check availability, get quotes, and book.
Scored across 10 tools
Most tools target clearly distinct resources and actions (search_boats vs search_captains, get_boat vs get_captain, create_booking vs create_boat_rental). The main possible confusion is between check_availability and get_quote, which both operate per captain/boat and both feed the booking flow with durationId, but their descriptions (slots vs. price) do distinguish them.
All tools follow a consistent snake_case verb_noun pattern (check_availability, create_booking, get_quote, list_harbors, search_boats, search_captains). The lone exception, ping, is a conventional health-check name rather than a real inconsistency.
Ten tools is well within the healthy range and each maps to a distinct step in the discovery → availability → quote → booking lifecycle. Nothing appears redundant or padded.
Discovery, availability, quoting, and both booking paths are covered, but the lifecycle dead-ends after creation: there is no get_booking, cancel_booking, or booking-status/cancel operation, so agents cannot manage or recover an existing reservation. Reviews and payment completion are delegated to Stripe/email, which mitigates but does not remove the gap.
Check a captain's or boat's availability. Provide exactly one of captainSlug or boatId. Omit date to get available dates for the next 90 days; provide both date (YYYY-MM-DD) and durationHours to get bookable time slots for that date. Only departures that have not yet left (Chicago time) are listed, so a past date has no slots. Each slot lists its offeredDurations, and every entry carries the durationId to pass to get_quote, create_booking, or create_boat_rental (null means that length is offered but not bookable through the API). A captain trip that lists harborIds departs only from those harbors (ids as in get_captain's harbors): create_booking refuses any other harbor for that trip. Without harborIds, drive time rules out none of the captain's active harbors.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| boatId | No | ||
| captainSlug | No | ||
| durationHours | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish this is a safe read, so the description wisely spends its budget elsewhere: it discloses the 90-day horizon, the Chicago-time 'already departed' cutoff, that null durationId means offered-but-not-bookable, and the harborIds departure restriction. These are behavioral traits the agent could not infer from readOnlyHint/destructiveHint.
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 the core contract and no filler sentences; every clause carries a rule. The later sentences are long and clause-dense (harbor rules), which costs some scannability, but nothing is redundant.
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 4-parameter read tool with no output schema, the description covers inputs, both response modes, the shape of each mode (dates, slots with offeredDurations), sentinel values, and the coupling to booking tools. Nothing an agent needs in order to call 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 all four parameters — and it largely does: mutual exclusivity of captainSlug/boatId, the YYYY-MM-DD date format, and the date+durationHours pairing are all spelled out. It falls short only on the origin/format of boatId and captainSlug (both presumably from sibling lookups, which are not named here).
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 a captain's or boat's availability') and immediately distinguishes the two lookup modes (date list vs. time slots). It also names the downstream siblings that consume its output (get_quote, create_booking, create_boat_rental), so an agent can place it in the workflow without opening 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?
Gives explicit input rules — 'Provide exactly one of captainSlug or boatId', omit date for the 90-day list, supply date plus durationHours for slots — and explains the failure case (past dates have no slots) and the harbor constraint that later blocks create_booking. That is genuinely when-to-use/when-not guidance with alternatives named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Book a bareboat boat rental. A boat with Instant Book on returns a Stripe Checkout link (payment.kind checkout_link) for the charterer to complete payment. For a boat whose owner reviews every request first (get_quote's instantBook: false), a request is sent instead: nothing is charged, the result is a request with the estimated total and deposit, and if the owner accepts, the charterer is emailed a link to pay. Requires captainChoiceRightAcknowledged: true (the charterer affirms their right to choose their own captain). Optionally attach a partner/affiliate code; partnerCode can't be used on a request (PARTNER_CODE_NOT_AVAILABLE_FOR_REQUESTS).
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| Yes | |||
| phone | Yes | ||
| boatId | Yes | ||
| lastName | Yes | ||
| firstName | Yes | ||
| partySize | Yes | ||
| startTime | Yes | ||
| durationId | Yes | ||
| partnerCode | No | ||
| pricingTierId | Yes | ||
| specialRequests | No | ||
| captainChoiceRightAcknowledged | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: discloses that Instant Book returns a Stripe Checkout link (payment.kind checkout_link), that the request path charges nothing and produces an estimated total plus deposit, that the charterer is emailed a payment link on owner acceptance, and it names a concrete server error (PARTNER_CODE_NOT_AVAILABLE_FOR_REQUESTS). None of this contradicts readOnlyHint=false / destructiveHint=false.
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 purpose, then branches into Instant Book versus request-and-review, then the acknowledgement requirement and partner code caveat. Dense but each clause carries information; the parenthetical '(get_quote's instantBook: false)' is slightly convoluted.
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?
Return behavior for both paths is described, which is valuable given no output schema, and the key boolean requirement is explained. But for an 11-required-parameter mutation with zero schema descriptions, the meaning of the pricing/duration identifiers and guest data fields remains unaddressed, leaving a real 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?
With 0% schema description coverage across 13 parameters, the description only adds meaning for captainChoiceRightAcknowledged (the captain-choice affirmation) and partnerCode (request-path restriction). Required identifiers like durationId, pricingTierId, and boatId, plus date/startTime formats, partySize's 13 cap, and specialRequests, are left entirely to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Book a bareboat boat rental.' The 'bareboat' qualifier and the Instant Book vs. owner-review distinction make the operation recognizable, though it never contrasts itself with the sibling create_booking tool.
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?
Explains the two outcome paths clearly and ties the choice to a condition the agent can check (get_quote's instantBook flag), which is genuine routing guidance. It does not state when to prefer this over create_booking or what prerequisites (availability check, quote) must precede it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Book a charter with a captain. A captain with Instant Book on returns a Stripe Checkout link (payment.kind checkout_link) for the charterer to complete payment. A captain who reviews every request first (get_quote's instantBook: false) is sent a request instead: nothing is charged, the result is a request with the estimated total and deposit, and if the captain accepts, the charterer is emailed a link to pay. Optionally attach a partner/affiliate code to credit a referrer; partnerCode can't be used on a request (PARTNER_CODE_NOT_AVAILABLE_FOR_REQUESTS). harborId must be a harbor this captain departs from: one of get_captain's harbors, or any list_harbors harbor when get_captain lists none. create_booking refuses any other harbor with HARBOR_NOT_OFFERED, and that error's harbors field lists the ones the captain departs from.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| Yes | |||
| phone | Yes | ||
| harborId | Yes | ||
| lastName | Yes | ||
| firstName | Yes | ||
| partySize | Yes | ||
| startTime | Yes | ||
| durationId | Yes | ||
| captainSlug | Yes | ||
| partnerCode | No | ||
| pricingTierId | Yes | ||
| specialRequests | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the generic write profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false). The description goes well beyond that: it discloses that money is actually charged in the instant-book path, that the request path charges nothing and produces a pending request with estimated total and deposit, and it names two specific error codes (PARTNER_CODE_NOT_AVAILABLE_FOR_REQUESTS, HARBOR_NOT_OFFERED) plus the harbors field on the error. That is exactly the side-effect detail an agent needs before committing a payment flow.
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's a single dense paragraph but front-loaded with the core action and the two outcome branches before the constraint details. Nearly every sentence carries a distinct rule; the harbor-constraint material is stated twice (the rule and then restated via the error), which is mild redundancy but defensible as emphasis.
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 an 11-required-parameter mutation tool with no output schema, the description does unusually well on outcomes and errors, but leaves the sourcing of the identifier parameters unexplained, which is the main thing that will cause a failed call. Given the tool's complexity, one more sentence on where durationId/pricingTierId/captainSlug originate would make it complete.
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 13 parameters at 0% schema description coverage, the description carries the full burden and only explains two of them: harborId's provenance/constraint and partnerCode's restriction. It never says where durationId, pricingTierId, or captainSlug come from (presumably get_quote/get_captain), nor why partySize, specialRequests, or the contact fields matter. The two IDs are the highest-risk inputs and are entirely undefined.
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?
"Book a charter with a captain" gives a specific verb and resource, and the description immediately distinguishes the captain-charter flow from the sibling create_boat_rental by naming the captain/intermediary model. It also splits the operation into its two distinct outcomes (instant-book checkout vs. request), so an agent knows exactly what this call produces.
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 tells the agent to consult get_quote's instantBook flag and get_captain's harbors before calling, and states the condition under which partnerCode is invalid. What's missing is explicit routing against alternatives — it never says when to prefer create_boat_rental, or that availability should be checked first with check_availability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a boat's full profile by id, enriched with a rating summary and the most recent reviews.
| Name | Required | Description | Default |
|---|---|---|---|
| boatId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by disclosing what the response contains beyond the raw profile (rating summary and recent reviews), which matters since no output schema exists. However, it does not cover not-found behavior or how many reviews are included.
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 that front-loads the action and resource and appends the enrichment detail without waste. Every clause carries information the agent cannot get from the structured fields.
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 one-parameter read tool with annotations covering safety, the description is nearly complete: it says what is fetched, by what key, and what extra data comes back. The only shortfall is the absence of any note on error/not-found handling, which is minor at this complexity.
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 required parameter with 0% schema description coverage, so the schema only supplies the name and a non-empty constraint. The description compensates partially by stating lookup is 'by id', clarifying that boatId is an identifier rather than a name or slug. No format or example 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?
States a specific verb ('Get') and resource ('a boat's full profile') with the lookup key ('by id'), and the enrichment clause (rating summary, recent reviews) distinguishes it from a plain record fetch. It does not explicitly contrast with search_boats, but the 'by id' scoping makes the distinction inferable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this when you already have a boat id and want detail. There is no explicit guidance on when to prefer search_boats first, nor any mention of what to do when the id is unknown or invalid. Adequate but leaves the agent to infer the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a captain's full profile by tenant slug, enriched with a rating summary and the most recent reviews.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description usefully adds that the response is enriched with a rating summary and recent reviews, but leaves undefined how many reviews are returned and what a missing captain yields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action and resource, with the enrichment detail trailing where it belongs. Nothing is redundant or padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of describing returns, and it does so at a reasonable level (profile, rating summary, recent reviews). Minor gaps remain on review count and not-found behavior, but the tool is simple and annotations cover the safety side.
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 0% for the single `slug` parameter, so the description must carry the meaning, and it partially does by calling it a "tenant slug." That phrasing adds context but introduces ambiguity about whether the slug identifies the captain or a tenant, which the schema does not resolve.
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 ("Get a captain's full profile") plus the lookup key (slug), which clearly separates it from search_captains. It stops short of naming the sibling it replaces, so the differentiation is implied rather than explicit.
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: an agent can infer this is the direct-lookup tool to use when a slug is already known, versus search_captains for discovery. The description never says when not to use it, what happens with an invalid slug, or names the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a non-binding price quote (in cents) for a charter or rental. Provide exactly one of captainSlug or boatId, plus durationId and partySize. Pass date (YYYY-MM-DD) whenever you know it: the rate then comes from the operator's rate card for that day — weekday vs weekend vs holiday, including any per-date price the operator set — so the quote matches what checkout charges. Without a date, pass pricingTierId instead; the quote then reflects that tier and may differ from checkout for the actual day. Optionally pass a partnerCode to preview a discount. Returns currency, totalCents, depositCents, balanceCents, pricingModel, instantBook, and (when a code is given) a discountPreview. instantBook says what booking does: true → create_booking / create_boat_rental return a Stripe Checkout link; false → the operator reviews every request first, so booking sends them a request instead (nothing is charged until they accept, and partnerCode can't be used — the quote then prices no discount and its discountPreview says PARTNER_CODE_NOT_AVAILABLE_FOR_REQUESTS).
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| boatId | No | ||
| partySize | Yes | ||
| durationId | Yes | ||
| captainSlug | No | ||
| partnerCode | No | ||
| pricingTierId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare read-only/non-destructive/closed-world; the description adds substantially more: the quote is non-binding and may diverge from checkout when no date is given, per-date rate-card resolution (weekday/weekend/holiday/operator override), and the discountPreview error code for request-only operators. It also discloses what booking does under each instantBook value, including that nothing is charged until operator acceptance.
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 purpose and every sentence carries information; the date-versus-tier and instantBook explanations genuinely earn their space. It is delivered as one dense paragraph without internal structure, which makes the embedded conditional rules harder to scan than they need to be.
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 enumerating return fields (currency, totalCents, depositCents, balanceCents, pricingModel, instantBook, discountPreview) and explaining instantBook's meaning. For a 7-parameter pricing tool this is complete enough to call correctly and interpret the result.
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 0% schema description coverage the description carries the full burden, and it explains the date format and the date-vs-pricingTierId tradeoff plus the captainSlug/boatId exclusivity. It does not clarify what durationId represents (a duration option id?) or the semantics of partySize (guest count, capacity validation), leaving two required parameters thinly specified.
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?
Opens with a specific verb and resource plus scope: "Get a non-binding price quote (in cents) for a charter or rental." The non-binding qualifier and the charter/rental scope distinguish it immediately from create_booking and check_availability without opening 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?
Gives explicit selection rules: exactly one of captainSlug or boatId, date when known otherwise pricingTierId, partnerCode optional. It also routes downstream behavior (instantBook true → create_booking / create_boat_rental) and states the exclusion that partnerCode cannot be used on request-style operators.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List active harbors, each with a count of active captains and listed boats operating there.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds value beyond that by disclosing the returned shape — each harbor with aggregate counts of active captains and listed boats — which is not encoded anywhere 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?
A single sentence that front-loads the action and resource and then delivers the payload detail, with no redundant restatement of the title or name. Nothing is padded and nothing is left dangling.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining return values, and it does so at a high level (per-harbor captain and boat counts). For a zero-parameter, read-only list tool this is nearly complete; ordering and any result-size limits are unstated but minor.
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?
The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool is 4. The description correctly avoids inventing filters that do not exist in the empty input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List active harbors') and clarifies the scope with 'active', which tells the agent inactive harbors are excluded. It does not explicitly name the neighboring tools (search_boats, search_captains), but none of them overlap in function, so the risk of confusion is low.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use guidance, no prerequisites, and no mention of alternatives or follow-up tools. Usage is only inferable from the tool's unique role among the siblings, which is implicit rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Health check
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered without the description. The description adds nothing beyond that — it does not state what a successful call returns (e.g., a status payload or empty response) or whether it requires connectivity/auth, which matters with no output schema to fill the gap.
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 words are as tight as possible and cannot be accused of padding, but this is under-specification rather than conciseness. There is no structure or front-loaded statement of what the call actually confirms.
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 zero-parameter read-only probe with no output schema, the description carries the burden of saying what the result means and when to invoke it. It does neither, and the presence of the near-synonymous sibling check_availability makes the omission consequential.
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?
The tool takes zero parameters, so there is no parameter semantics for the description to explain. Baseline 4 applies; nothing is missing on this dimension.
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?
"Health check" does convey more than the bare name "ping" — it tells the agent this is a liveness/status probe rather than a network ping. But it is a noun phrase with no verb and no scope, and it gives no basis for distinguishing it from the sibling check_availability, which an agent could easily confuse it with.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no when-to-use guidance, no prerequisites, and no exclusions. In particular it never says how this differs from check_availability, leaving the agent to guess between two plausibly overlapping probes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search listed boats, optionally filtered by harbor, type, minimum capacity, and max hourly price, with sorting and pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| sort | No | name | |
| type | No | ||
| limit | No | ||
| harbor | No | ||
| maxPrice | No | ||
| minCapacity | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered by structured data. The description adds that results are sortable and paginated, but says nothing about default page size (20), the hard cap (50), total-count metadata, or whether filtering is exact-match or substring for harbor.
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 front-loaded sentence that names the action first and then the optional dimensions; nothing is redundant or padded. Every clause corresponds to a real capability of the tool.
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 search tool with seven parameters and no output schema, the definition is adequate but leaves the agent guessing about the return shape (array of boats, totals, pagination envelope) and about pagination mechanics. Since no output schema exists to explain results, the description should have done more than state that pagination exists.
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 map onto all seven inputs by naming harbor, type, capacity, price, sorting, and pagination. However it adds no semantics beyond the property names: no default limit of 20, no max of 50, no listing of the sort enum values, and no clarification that the filters combine as AND conditions.
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 gives a specific verb and resource ('Search listed boats') and enumerates the filter dimensions, so the agent immediately knows this is a filtered collection query rather than a single-record fetch like get_boat. It stops short of explicitly contrasting itself with sibling search tools such as search_captains, but the resource noun already disambiguates.
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: 'search listed boats' suggests use for discovery versus get_boat for a known ID, but no when-to-use or when-not-to-use guidance is stated. There is no mention of alternatives like check_availability or get_quote when the user actually wants pricing or availability rather than a boat list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search bookable charter captains, optionally filtered by harbor, with sorting and pagination. Returns a paginated list with starting price and rating.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| sort | No | rating | |
| limit | No | ||
| harbor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. Beyond that, the description adds that results are paginated and include starting price and rating — useful return-shape context given there is no output schema — though it omits ordering of results, whether matches are fuzzy, and any rate-limit or result-cap behavior.
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 tightly written sentences with the capability front-loaded and return shape second. There is slight redundancy between 'with sorting and pagination' and 'Returns a paginated list', but 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 four parameters, 0% schema coverage, no output schema, and a non-trivial domain (bookable charters), the description is only minimally sufficient. It covers the filter dimension and hints at returned fields, but leaves sort semantics, pagination limits, and the distinction from get_captain/search_boats for 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 compensate for four undocumented parameters. It does name the harbor filter, sorting, and pagination conceptually, but adds no detail on sort options (rating, price_asc, price_desc, name), defaults (page=1, limit=20), or the limit cap of 50 that the schema enforces — so meaning beyond the schema is thin.
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 ('Search bookable charter captains') plus scope qualifiers (harbor filter, sorting, pagination), which clearly separates it from siblings like search_boats and get_captain by resource type. It stops short of explicitly naming those siblings, so differentiation relies on the agent inferring from the noun.
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 phrase 'optionally filtered by harbor' implies the intended browsing use case and that no filter is required, but there is no explicit when-to-use/when-not guidance and no mention of alternatives such as get_captain for retrieving a single captain. Usage is inferable rather than stated.
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.
check_availability1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"create_boat_rental6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / properties / email / maxLengthAdded value: +254Input schema / properties / email / patternPrevious value: -"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"New value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"Input schema / properties / firstName / maxLengthAdded value: +100Input schema / properties / lastName / maxLengthAdded value: +100Input schema / properties / phone / maxLengthAdded value: +40create_booking6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / properties / email / maxLengthAdded value: +254Input schema / properties / email / patternPrevious value: -"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"New value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"Input schema / properties / firstName / maxLengthAdded value: +100Input schema / properties / lastName / maxLengthAdded value: +100Input schema / properties / phone / maxLengthAdded value: +40get_boat1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"get_captain1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"get_quote1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"list_harbors1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"ping1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"search_boats1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"search_captains1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"create_boat_rental1 field changedInput schema / properties / partySize / maximumPrevious value: -9007199254740991New value: +13create_booking1 field changedInput schema / properties / partySize / maximumPrevious value: -9007199254740991New value: +13search_boats1 field changedInput schema / properties / type / enumPrevious value: -[
- "SAILBOAT",
- "POWERBOAT",
- "PONTOON",
- "JETSKI",
- "KAYAK",
- "CANOE",
- "YACHT",
- "OTHER"
-]New value: +[
+ "SAILBOAT",
+ "POWERBOAT",
+ "PONTOON",
+ "JETSKI",
+ "KAYAK",
+ "CANOE",
+ "YACHT",
+ "OTHER",
+ "FISHING"
+]get_quote2 fields changedInput schema / properties / dateAdded value: +{
+ "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "durationId",
- "pricingTierId",
- "partySize"
-]New value: +[
+ "durationId",
+ "partySize"
+]check_availabilitycreate_boat_rentalcreate_bookingget_boatget_captainget_quotelist_harborspingsearch_boatssearch_captainsSearch, quote and book boat rentals and captained charters on BoatWakr.
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.
