Ferry and fast-boat schedules, seats and fares, boat and fishing charters across Indonesia.
Scored across 4 tools
The three search tools target distinct offerings: private yacht charters, fishing trips, and point-to-point ferry transport. The only soft spot is charter_search vs fishing_search, since fishing is described as a subcategory of the charter catalogue, but the extra fishing-specific filters (technique, target species) and the private-package framing keep them separable.
All tools use lowercase snake_case with a consistent resource_action structure: charter_search, fishing_search, sailing_search, locations_list. The three *_search tools match perfectly; locations_list deviates only in verb (list vs search), which is appropriate for its purpose, so it is a minor deviation.
Four tools is a reasonable, well-scoped surface for a search/discovery-oriented travel server, with each tool covering a distinct product line plus a location lookup. It leans slightly thin, but nothing feels redundant or padded.
The surface covers discovery well (three search tools plus a location enumerator that feeds the search filters), but there is no way to book, reserve, or fetch a single charter/departure by identifier. For a platform that sells charters and sea transport, the absence of any booking or detail-retrieval operation is a notable gap.
Searches private boat and yacht charter packages by departure area, date, guest count, vessel type and trip length, returning price, duration, capacity, inclusions and the operator.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Requested charter date, YYYY-MM-DD. | |
| limit | No | ||
| guests | No | ||
| location | No | Departure area, e.g. a city or harbor name. | |
| vessel_type | No | Vessel category filter, e.g. speedboat or yacht. | |
| charter_style | No | Trip style filter, e.g. reef or trolling. | |
| duration_type | No | Trip length, e.g. half_day, full_day, overnight. |
| Name | Required | Description |
|---|---|---|
| query | Yes | Parameters the search actually ran with, after resolution. |
| total | No | |
| results | Yes | |
| returned | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safe read-only nature, and the description adds useful behavioral context by listing the search dimensions and the return fields (price, duration, capacity, inclusions, operator). It does not contradict the annotations and adds context beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It clearly communicates the core purpose and key capabilities in a compact format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema and annotations, the description is sufficient for a search tool. It captures the main purpose, filters, and return information, but could more explicitly address limit behavior and differentiate from sibling search tools.
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 description adds natural-language meaning for parameters like 'guest count' (guests) and 'trip length' (duration_type), which are not fully described in the schema. Most parameters are referenced, though 'limit' and 'charter_style' are not explicitly mentioned.
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 uses a specific verb ('searches') and a clear resource ('private boat and yacht charter packages'), and explicitly lists the key filtering dimensions. It distinguishes from sibling tools like fishing_search and sailing_search by focusing on general private charters.
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 implies this tool is for finding boat/yacht charters, and the filters give context. However, it does not explicitly state when to use this tool versus alternatives like fishing_search or sailing_search, nor does it mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches fishing charter trips by departure area, date, angler count and technique, returning price, duration, capacity, target species and the operator. Fishing trips are a category of the charter catalogue, so charter filters apply here too.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Requested trip date, YYYY-MM-DD. | |
| limit | No | ||
| anglers | No | ||
| location | No | Departure area, e.g. a city or harbor name. | |
| charter_style | No | Fishing style filter, e.g. reef or trolling. | |
| duration_type | No | Trip length, e.g. half_day, full_day, overnight. |
| Name | Required | Description |
|---|---|---|
| query | Yes | Parameters the search actually ran with, after resolution. |
| total | No | |
| results | Yes | |
| returned | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds meaningful context beyond annotations by detailing the return fields (price, duration, capacity, target species, operator) and stating that charter filters apply here too, which informs the agent about inherited filtering 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?
The description is two sentences, front-loaded with the primary action and key filters/returns in the first sentence, and the second sentence clarifies the catalog relationship. Every word earns its place, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's straightforward search nature, the presence of annotations, and an output schema, the description covers the essential purpose, return fields, and category context. It could be more explicit about sibling differentiation, but overall it is sufficient for an agent to understand scope and expected results.
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 description maps several parameter concepts to schema properties ('departure area' to location, 'date' to date, 'angler count' to anglers, 'technique' to charter_style), but it does not mention the limit or duration_type parameters. With schema description coverage at 67%, the description partially compensates but leaves two parameters undocumented in both schema and description.
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 opens with a specific verb and resource ('Searches fishing charter trips'), then lists distinct filter dimensions (departure area, date, angler count, technique) and return fields (price, duration, capacity, target species, operator). It also distinguishes from siblings by explicitly noting fishing trips are a category of the charter catalogue, which clearly separates it from charter_search and sailing_search.
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 implies that this is a specialized search within the charter catalogue ('Fishing trips are a category of the charter catalogue'), but it does not explicitly state when to prefer this over charter_search or sailing_search, nor does it mention any exclusions or alternatives. The usage context is only implied by the name and the category note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the harbors and destination regions Sailtix sells sea transport between, each with the identifier the search tools accept. Optional free-text filter narrows the list by name or slug.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum entries to return. Defaults to 60. | |
| query | No | Optional free-text filter matched against name and slug. |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| returned | Yes | |
| locations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds that entries include identifiers and that the optional query filters by name/slug, but these largely repeat schema details and do not disclose additional behavioral traits like pagination or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the verb and purpose, and contains no filler or redundant 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 simple list tool with a rich output schema, thorough annotations, and full parameter documentation, the description adequately conveys its role as a provider of identifiers for the sibling search tools. No gaps remain for the agent to select and invoke the tool 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?
The input schema has 100% description coverage for both parameters, including the limit default and query matching semantics. The description restates the query behavior without adding new meaning, so it does not exceed the schema 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?
The description uses a specific verb 'lists', names the resource 'harbors and destination regions', and emphasizes that entries include identifiers the search tools accept. This clearly distinguishes it from sibling search tools (charter_search, fishing_search, sailing_search) which perform searches rather than list reference data.
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 clearly implies usage as a precursor to searches by stating identifiers are 'the search tools accept.' It provides clear context for when to invoke this tool but does not explicitly state exclusions or name alternative tools, which keeps it just 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.
Searches scheduled ferry and fast-boat departures between two places on a given date, returning departure and arrival times, operator, vessel, journey duration, remaining seats and fares. Fares are the total the guest pays Sailtix: no booking fee or card fee is added at checkout. Harbor and island levies aren't Sailtix fees. Where one applies, the operator either includes it in the fare or collects it at the harbor. Origin and destination accept a harbor name, a destination-region name, a slug, or an identifier from locations_list; at least one side must be given.
| Name | Required | Description | Default |
|---|---|---|---|
| adult | No | ||
| child | No | ||
| limit | No | ||
| infant | No | ||
| origin | No | Departure harbor or region — name, slug, or identifier. | |
| destination | No | Arrival harbor or region — name, slug, or identifier. | |
| nationality | No | Accepted and ignored: every nationality pays the same fare. | |
| return_date | No | Optional return date, YYYY-MM-DD. | |
| travel_date | No | Departure date, YYYY-MM-DD. |
| Name | Required | Description |
|---|---|---|
| query | Yes | Parameters the search actually ran with, after resolution. |
| total | No | |
| results | Yes | |
| returned | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare it read-only, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely useful non-obvious context: fares are the total the guest pays, no booking/card fees are added at checkout, and harbor/island levies are not Sailtix fees. It does not discuss pagination or rate limits, but this is solid added value on top of 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?
The definition is dense and front-loaded: capability and return fields come first, then fare policy, then argument formats. The fare/levy passage is somewhat long, but it conveys policy an agent would otherwise get wrong, so it largely 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 an output schema covering return values and annotations covering the safety profile, the description only needs to add constraints and semantics, which it largely does. Remaining gaps are the passenger-count parameters and the behavior of 'limit', which are left entirely to the schema.
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 only 56%, and the description compensates by explaining that origin/destination accept a harbor name, region name, slug, or an identifier from locations_list, plus the 'at least one side' requirement that is otherwise invisible with 0 required parameters. It adds nothing for adult/child/infant/limit, which remain undocumented beyond type and bounds.
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?
It names a specific verb and resource ('Searches scheduled ferry and fast-boat departures between two places on a given date') and enumerates the returned fields, which cleanly separates it from the charter_search and fishing_search siblings. An agent can identify the tool 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?
It gives a concrete precondition ('at least one side must be given') and describes the accepted identifier forms for origin/destination, which guides invocation. It never explicitly says when to prefer this over charter_search or fishing_search, so it falls short of a full when/when-not statement.
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.
sailing_search1 field changedInput schema / properties / nationality / descriptionPrevious value: -"Fare band. Indonesian residents are priced separately."New value: +"Accepted and ignored: every nationality pays the same fare."charter_searchfishing_searchlocations_listsailing_searchPlan and book southern Thailand trips: island tours, private boats, ferries, hotels, itineraries.
Search 14,000+ charter boats with live prices, plus marinas, anchorages, routes and itineraries.
Indonesian public data: regions, postal codes, holidays, prayer times, BMKG, schools, wages
Live hotel and flight prices compared across Booking.com, Agoda, Trip.com and Traveloka, in USD.
Add one secure layer between your agents and this server.
