Search about 20,000 yachts for sale, charter and sold, with where AIS last placed each one.
Scored across 3 tools
find_yachts and yachts_near both allow proximity-based search using AIS positions, which could cause some confusion, though yachts_near provides more detailed positional data and a default time window. yacht_facts is clearly distinct for single-yacht details. Overall, the tools are mostly distinct but with one overlapping pair.
Names are all snake_case, but grammatical patterns are mixed: find_yachts is verb_noun, while yacht_facts and yachts_near are noun phrases. This inconsistency means the set lacks a predictable verb_noun convention, though it remains readable.
Three tools appropriately cover the core use cases: searching the catalogue, retrieving a single yacht's facts, and finding nearby yachts. The count is well-scoped for the domain.
The surface covers search, detail retrieval, and proximity discovery, which are the main operations for a yacht finder. Minor gaps include no explicit tool for listing builders or harbours, but these can be inferred from search filters and results.
Search YachtFinder's catalogue of about 20,000 yachts by builder, length, asking price, build year, status (for sale, for charter, reported sold, not for sale) and place. Returns up to 25 yachts, longest first by default, each with her status, the broker's asking price, YachtFinder's estimate where her page shows one, and a link to her page on yachtfinder.co. near keeps yachts whose AIS position, as the site publishes it, lies within radius_km of a named harbour or anchorage; listed_in matches the town or country the broker's listing states.
| Name | Required | Description | Default |
|---|---|---|---|
| near | No | A harbour, harbour town or anchorage by name, e.g. "Port Hercule", "Antibes", "Fort Lauderdale", "Off Monaco". | |
| sort | No | longest | |
| limit | No | ||
| status | No | Default for_sale. for_charter includes yachts offered for both. | for_sale |
| builder | No | Shipyard, e.g. "Benetti", "Feadship", "Lürssen". Case and accents are ignored. | |
| max_year | No | Latest build year. | |
| min_year | No | Earliest build year. | |
| listed_in | No | Town or country named in the broker's listing, e.g. "Fort Lauderdale", "Italy". This is where the listing says she is, not an AIS position. | |
| radius_km | No | With near: the radius. Default 2 km for a harbour, 3 km for an anchorage. | |
| max_length_m | No | Maximum length overall, metres. | |
| min_length_m | No | Minimum length overall, metres. | |
| max_price_usd | No | Maximum asking price in whole US dollars. | |
| min_price_usd | No | Minimum asking price in whole US dollars (20000000 = $20M). Only yachts with a published asking price are compared. | |
| name_contains | No | Part of the yacht's name. | |
| seen_within_hours | No | With near: only AIS positions this recent. Default: any position the site publishes (up to 120 days). |
| Name | Required | Description |
|---|---|---|
| notes | Yes | |
| source | Yes | |
| read_at | Yes | When this server read that catalogue (ISO 8601). |
| results | Yes | |
| summary | Yes | |
| data_as_of | Yes | When YachtFinder last rebuilt the catalogue this answer was read from (ISO 8601). |
| answered_at | Yes | |
| total_matches | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent/non-destructive, so the bar is lower. The description adds real context beyond them: result cap of 25, default sort 'longest', the fact that only yachts with a published asking price are compared for price filters, and that AIS data reaches back up to 120 days. It omits pagination/truncation behavior when more than 25 matches exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with scope and filters, then result shape, then location-filter semantics. Efficient and readable, though the sentence about return contents partially restates schema-provided defaults (sort order, 25 cap).
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 15-parameter, no-required-params drill-down search with an output schema (so return format needn't be explained), the description covers filtering semantics, defaults, and the AIS-vs-listing distinction well. The main gap is the absence of guidance relative to the sibling tools that share the geography feature.
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 already 87%, so baseline is 3. The description goes further by contrasting 'near' (published AIS position) with 'listed_in' (broker's stated location) — a distinction the schema states only partially — and by noting the default 'longest' ordering tied to the sort parameter.
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 (search) and resource (YachtFinder's ~20,000-yacht catalogue), enumerates the filterable facets, and specifies result cardinality and default ordering. An agent can tell this is a filtered catalogue search rather than a point-lookup (yacht_facts) or a proximity query (yachts_near).
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 disambiguates the two location filters ('near' = published AIS position within radius; 'listed_in' = town/country in the broker's listing), which is useful routing advice. However, it never says when to prefer this tool over the overlapping siblings yachts_near or yacht_facts, so tool selection is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One yacht's facts from YachtFinder: builder, year, length, status, the broker's asking price (never a sale price), YachtFinder's estimate where her page shows one, her published AIS position with its time, where her listing says she is, and her page on yachtfinder.co, with the source and date of each fact. Takes her name (add builder or length_m when several yachts share it) or her yachtfinder.co/y/ link.
| Name | Required | Description | Default |
|---|---|---|---|
| yacht | Yes | Her name, e.g. "Lady Lara", or her yachtfinder.co/y/ link or the id from another answer. | |
| builder | No | Her builder, to choose between yachts of the same name. | |
| length_m | No | Her length in metres, to choose between yachts of the same name. |
| Name | Required | Description |
|---|---|---|
| found | Yes | |
| notes | Yes | |
| yacht | No | |
| source | Yes | |
| matches | No | |
| read_at | Yes | When this server read that catalogue (ISO 8601). |
| summary | Yes | |
| data_as_of | Yes | When YachtFinder last rebuilt the catalogue this answer was read from (ISO 8601). |
| answered_at | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description still adds real context: the price is the broker's asking price and 'never a sale price', the estimate is only present 'where her page shows one', AIS position carries a timestamp, and every fact is attributed with source and date. That prevents misinterpretation of returned values.
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 core purpose, followed by a well-structured enumeration of returned facts and the input forms. Dense but every clause carries information; there is 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?
Because an output schema exists, return values need not be re-explained, and the description still covers the notable return caveats (asking vs sale price, conditional estimate, timestamped AIS). The only modest gap is the absence of any note on error behavior when no matching yacht is found.
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 100%, so a baseline of 3 is warranted, but the description goes further by explaining the disambiguation purpose of builder and length_m and by stating that the name may be replaced with a yachtfinder.co/y/ link or an id, which the schema only partially conveys.
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 resource (one yacht's facts) and enumerates exactly what is returned: builder, year, length, status, asking price, estimate, AIS position, listing location, and the source page. This contrasts implicitly but clearly with the plural siblings find_yachts and yachts_near, so an agent can select it 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 concrete instruction on disambiguation: 'add builder or length_m when several yachts share it', and accepts either a name or a yachtfinder.co/y/ link. It names no alternative tool or explicit when-not condition, but the single-yacht scope makes the intended context unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the yachts whose latest AIS position, as yachtfinder.co publishes it, lies within a radius of a named harbour or anchorage (e.g. "Port Hercule", "Antibes", "Off Monaco") or of a latitude and longitude. By default only positions from the last 24 hours. Each yacht comes with the time of her fix, her distance from the place, whether the harbour's page counts her in port, and a link to her page. A yacht whose position the site does not publish is never listed.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| place | No | A harbour, harbour town or anchorage by name. Give this, or latitude and longitude. | |
| status | No | any | |
| latitude | No | ||
| longitude | No | ||
| radius_km | No | Default 2 km for a harbour, 3 km for an anchorage, 10 km for a coordinate. | |
| seen_within_hours | No | Only positions this recent. Default 24. |
| Name | Required | Description |
|---|---|---|
| notes | Yes | |
| place | Yes | |
| source | Yes | |
| read_at | Yes | When this server read that catalogue (ISO 8601). |
| results | Yes | |
| summary | Yes | |
| data_as_of | Yes | When YachtFinder last rebuilt the catalogue this answer was read from (ISO 8601). |
| answered_at | Yes | |
| total_matches | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower, yet the description still adds real behavior: a default 24-hour position window, the rule that yachts with unpublished positions are never listed, and the fact that results are keyed to the source site yachtfinder.co. It does not mention rate limits or failure behavior for an unresolvable place name.
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 purpose in the first clause and the exceptions (default 24h window, unpublished positions) after. Three tight sentences with no filler, though each is long and the result-field enumeration is somewhat list-like inside prose.
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 annotations and an output schema present, the description is nearly complete: it explains the source, the freshness default, and the inclusion rule. It is slightly redundant in enumerating returned fields that the output schema already covers, and it does not address what happens when no place or coordinate is supplied despite zero required parameters.
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 43%, so the description needs to carry weight; it clarifies the place-vs-coordinates choice and the default recency window, but says nothing about status, limit, or radius defaults that remain thin in the schema. Partial compensation only, hence a mid score rather than a higher one.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a precise verb and resource ("List the yachts") and narrows it with an unmistakable criterion: AIS positions within a radius of a named harbour/anchorage or a lat/long pair. That geospatial scoping distinguishes it in practice from find_yachts and yacht_facts without the agent needing to open 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?
It states the selecting condition (named place OR coordinates) and provides concrete place-name examples ("Port Hercule", "Antibes", "Off Monaco"), which is clear usage context. It never names find_yachts as the alternative for non-proximity queries, nor states when not to use it, so it stops short of a full 5.
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.
find_yachtsyacht_factsyachts_nearVessel Tracking — live worldwide ship positions from AIS.
Vessel tracking for 750,000+ ships, with ownership, inspections, port records, routes, and more.
Search boats for sale or rent, marinas and live market stats on Obato, Europe's boat marketplace.
Live AIS vessel positions by MMSI, name, area, or radius, plus coverage. No sign-in, no key.
Add one secure layer between your agents and this server.
