YachtFinder

Find yachts

find_yachts

Read-onlyIdempotent

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.

Input Schema

TableJSON Schema

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).

Output Schema

TableJSON Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 29, 2026

TDQS

A4.1/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

All YachtFinder tools Inspect

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

Need Help?