Skip to main content
Glama

Charter Boats

by boats.charter
OverviewDiscussionsAdmin

Compare a Boat With Similar Boats

compare_boat
Read-only

One boat against up to 10 closest published boats of the same type in the same country: specs and the all-in weekly price (in currency, EUR when omitted, at max guests, the figure search compares) for each of the next 52 weeks. Pass id (a boat), or boat_type and country (optionally region, city) to describe one. The specs take search_boats' names: without id they describe the boat to compare; with id they filter its peers as search_boats would. Only boats open at least one week are compared. similar_pct is how alike a peer is: the share of the specs it shares. With id, overlap_pct is the share of the boat's open weeks the peer is open too. With id, anchor.price is the boat's weekly figures, a peer's price is its figure minus the boat's (its own in the weeks listed in absolute_weeks), and a peer carries its region, city, same (the fields it shares with the boat) and only the specs that differ, as signed deltas; without id every peer carries its own specs and figures. null = not sellable that week; weeks gives each check-in date. Use when someone asks how a boat compares with others nearby on price, size or age — an operator benchmarking their own boat included. For what is better or worse about one boat, use get_boat_standouts.

Input Schema

NameRequiredDescriptionDefault
idNoBoat id from search_boats or get_boat_details — copy it verbatim. Omit to describe a boat by its specs.
cityNoWithout id, optional: city or town, e.g. Split.
lockNoWith id: keep only peers the same as the boat in these fields — the fields a peer's `same` lists.
berthsNoBerths: without id the number to match, with id the minimum.
cabinsNoCabins: without id the number to match; with id the minimum guest cabins, crew cabins not counted (as search_boats).
guestsNoGuests: without id the number to match, with id the minimum.
regionNoWithout id, optional: sailing region, e.g. Dalmatia.
countryNoWithout id: ISO country code, e.g. HR (required with boat_type).
toiletsNoToilets: without id the number to match, with id the minimum.
currencyNoOptional: the currency every amount in the answer is written in, and any price you send is read in. EUR when omitted.
year_maxNoMaximum build year.
year_minNoMinimum build year.
boat_typeNoWithout id: the boat type (required with country).
makemodelNoMake and/or model as the guest said it, e.g. "Lagoon 42", "Bali".
length_maxNoMaximum length in feet.
length_minNoMinimum length in feet.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / currency
      Added value: +{
+  "description": "Optional: the currency every amount in the answer is written in, and any price you send is read in. EUR when omitted.",
+  "enum": [
+    "EUR",
+    "USD"
+  ],
+  "type": "string"
+}
  2. Added

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish read-only/non-destructive, so the description's job is to add semantics and it does: only boats open at least one week are compared, prices are the max-guest all-in figure used by search, peer prices are shown as deltas against the anchor (absolute in `absolute_weeks`), null means not sellable that week, and `in` `id`-less mode peers carry their own specs. That is meaningfully more than the annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded correctly, but the body is a single ~180-word paragraph of stacked clauses ("a peer's `price` is its figure minus the boat's (its own in the weeks listed in `absolute_weeks`)") with no breaks, and it introduces output fields like `anchor` and `absolute_weeks` without definition. Information-dense but hard to parse on a single pass.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, and the description carries the full return-value burden: `similar_pct`, `overlap_pct`, `same`, signed spec deltas, price deltas vs absolute figures, and `weeks` check-in dates are all explained. An agent can call this and interpret the response without further documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 every parameter including the dual match-vs-minimum semantics of berths/cabins/guests. The description mostly restates this ("the specs take search_boats' names... with `id` they filter its peers as search_boats would") and never explains `lock`, `makemodel`, or the year/length range pairs. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a precise statement of what is compared: one boat versus up to 10 closest published boats of the same type and country, across 52 weeks of specs and all-in weekly prices. It explicitly routes the 'is this boat good?' question to get_boat_standouts, so an agent can separate it from siblings without reading schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

States directly when to use it ("how a boat compares with others nearby on price, size or age"), names the two invocation modes (by `id`, or by `boat_type`+`country`), and names the alternative for a different intent (get_boat_standouts). It even covers the operator-benchmarking-own-boat case.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Charter Boats toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources