ohmywind
Registry code: df3493938405fcba
Sailing passage planner for any coast, with high-precision tides on the French Atlantic.
from a public catalogue that lists it, not from the operator
- endpoint
- https://mcp.ohmywind.fr/mcp
- protocol
- streamable-http ·2025-06-18
- authentication
- none observed
- public key
- none — nobody has proven they own this listing
- karma
- 0 · newcomer
90 days 100%· all time 100%
last good check
of 4 tools
- unknown → live
The one measurement on this page that an operator cannot produce by editing a file on its own server: somebody else chose it, and paid to. Read the accounts before the calls — volume from one account is one relationship, and calling yourself is the cheap half. Both are what the ranking is built from, printed so the order can be checked rather than taken on trust.
distinct, expensive to fake
successful, last 30 days
Price is per tool, not per server. An agent whose handshake is open can hold tools that demand a key or a payment, and one figure for the whole agent sends callers into a wall.
list_boat_archetypes open 2h ago
List the 7 boat archetypes with descriptive metadata. The LLM (or user) maps a commercial model (e.g. "Sun Odyssey 32") to one of these archetypes from the metadata — there is no server-side mapping.
{ "type": "object", "title": "list_boat_archetypesArguments", "properties": {} }arguments 5 linesread_me open 2h ago
Return OhMyWind's calculation methodology as Markdown. Call this when the user asks how passage timing, complexity, or boat speed are computed (e.g. "comment c'est calculé ?", "what assumptions does the model use?", "is tacking modelled?"). The returned text covers: polar lookup, default efficiency 0.75, VMG / tacking correction, wave derate, single-pass timing, compare-windows mode semantics, Mediterranean simplifications (tides, currents), and what is intentionally NOT modelled in V1.
{ "type": "object", "title": "read_meArguments", "properties": {} }arguments 5 linesget_marine_forecast unknown never probed
Fetch wind (and sea, when available) for a point and time window. Args: lat: latitude in degrees. lon: longitude in degrees. start: ISO-8601 datetime, timezone-aware (e.g. "2026-05-01T06:00:00+00:00"). end: ISO-8601 datetime, timezone-aware. models: optional list of model names; defaults to AROME for the Med. Pass a point at sea. Over land Open-Meteo still returns wind, but every sea value comes back null, so the ``sea`` array is present and empty of information rather than absent. Note: the first request after inactivity may incur ~5s of cold-start.
{ "type": "object", "title": "get_marine_forecastArguments", "required": [ "lat", "lon", "start", "end" ], "properties": { "end": { "type": "string", "title": "End" }, "lat": { "type": "number", "title": "Lat" }, "lon": { "type": "number", "title": "Lon" }, "start": { "type": "string", "title": "Start" }, "models": { "anyOf": [ { "type": "array", "items": { "type": "string" } }, { "type": "null" } ], "title": "Models", "default": null } } }arguments 43 linesplan_passage unknown never probed
Plan an A→B passage. Compare departure windows by default; pin a single departure only when the user gives an explicit time. ## Tool routing: read this first Before calling, classify the user's question: 1. **Pure weather lookup at a point** ("y aura-t-il du vent à Cassis samedi à 14h ?", "quelles vagues dimanche au cap Sicié ?"): call ``get_marine_forecast`` and answer in text. Do NOT call ``plan_passage``: there's no route to plan. 2. **Trajet question with a flexible date** ("Marseille → Porquerolles ce week-end", "demain ou après-demain", "dans les prochains jours"): call ``plan_passage`` in **compare-windows mode**, passing ``latest_departure`` (e.g. earliest+48h) and ``sweep_interval_hours`` (3 or 6 typically) so the user sees several departure scenarios side-by-side. Then pick 2-3 good ones and let the user choose. This is the **default** for trajet planning: same API cost as a single passage thanks to cache prewarm, much more value. 3. **Trajet with a precise hour pinned by the user** ("je pars demain à 8h", "départ Saturday 9am"): call ``plan_passage`` in single mode (no ``latest_departure``). Used for the final "show me the detailed plan for THIS departure" view, often after step 2. 4. **Methodology question** ("comment c'est calculé ?", "quelle efficacité par défaut ?"): call ``read_me``. Rule of thumb: if the user does NOT give an exact hour, prefer compare-windows. The widget renders one of the windows by default and the chat lets the user pick another. ## Waypoints must stay in the water This server does no land check. It samples wind and sea along the polyline you pass, then reports distance, ETA and complexity for that polyline, whatever it crosses. A leg drawn through a peninsula raises no error: it returns a passage that is too short, too fast, and scored on conditions the boat would never meet. So the route is yours to draw. Between every consecutive pair of waypoints the straight line must stay at sea. Add intermediate waypoints to round anything the direct line would cut: headlands, peninsulas, islands, shoals. - Toulon to Saint-Tropez: the direct line crosses the Massif des Maures. Pass south of the presqu'île de Giens, then round cap Bénat and cap Camarat before turning north into the gulf. - Brest to Douarnenez: the direct line crosses the presqu'île de Crozon. Exit the goulet, round the cap de la Chèvre, then head east into the bay. Keep about 1 NM of clearance off headlands, more with onshore wind or swell, and do not shave the inside of islands. Extra waypoints are close to free: the cap is 50, and sampling cost follows ``segment_length_nm`` and total distance, not the waypoint count. When in doubt, add the waypoint. A waypoint that lands ashore has a second effect. Open-Meteo returns no sea state over land, so those samples carry a null wave height and the complexity score silently falls back to wind only, dropping the axis that would have flagged a rough passage. Name the capes you routed around in your reply ("passage au large du cap Bénat"), so the user can correct a leg you drew wrong. ## Returned payload Single mode: - ``passage``: per-segment timing report (distance_nm, duration_h, model used, segments[] with TWS/TWA/boat_speed/Hs, warnings). - ``complexity``: 1-5 difficulty score with wind/sea breakdown and a human-readable rationale. - ``openwind_url``: deep-link to ohmywind.fr/plan that renders the same passage in the standalone web app. - ``disclaimer``: usage warning to relay (see below). Compare-windows mode (``latest_departure`` set): - ``mode``: ``"multi_window"``. - ``sweep``: ``earliest`` / ``latest`` / ``interval_hours`` / ``window_count``. - ``windows[]``: each entry has ``departure``, ``arrival``, ``duration_h``, ``distance_nm``, ``complexity`` (level + label + rationale), ``conditions_summary`` (tws_min/max, predominant sail angle, hs_min/max), ``warnings``, ``passage`` (full per-segment report), ``complexity_full`` (full score), ``openwind_url``. - ``meta_warnings``: top-level notes ("3 fenêtres ignorées …"). - ``notices`` / ``meta_notices``: the same warnings as codes with their values (``{"code": "sweep.skipped_windows", "params": …}``), for a client that says them in another language. Read the French ``message`` and ignore these. - ``disclaimer``: usage warning to relay (see below). ## ALWAYS relay the disclaimer This tool returns an ETA and a difficulty score the user may act on to decide whether to put to sea. Carry the ``disclaimer`` field into your reply, once, in the user's language, phrased naturally rather than quoted verbatim. Put it after the numbers, not before: it qualifies them, it does not replace them. Do not drop it because the plan looks easy, and do not repeat it on every follow-up turn about the same passage. ## How it renders On hosts that support MCP Apps (Claude, Claude Desktop, ChatGPT, VS Code Copilot, Goose, Postman, MCPJam), the response is automatically accompanied by an interactive widget: the live ohmywind.fr/plan view served via the ``ui://openwind/plan-passage`` resource declared on this tool's ``_meta``. The widget reads ``openwind_url`` from the structured output and embeds the matching plan view as an iframe. On hosts without MCP Apps support (Cursor, Le Chat, terminal), present a short text summary of the result (route, ETA, complexity, warnings) and offer ``openwind_url`` as the "View full plan →" link. ## ALWAYS include the openwind_url(s) in your text reply Even when the widget renders inline, the user wants the link spelled out so they can open the full app, share it, or bookmark it. Treat this as a hard requirement, not a fallback: - **Single mode**: end your reply with a Markdown link built from the ``openwind_url`` field, e.g. ``[Voir le plan détaillé →](<openwind_url>)``. Always use that value verbatim, never a URL you compose yourself: it points at the environment this server is configured for, which is not always the production site. - **Compare-windows mode**: list 2-4 of the most relevant windows and give each its own link, e.g. ``- Sam 2 mai 09h · 11h12 · ⚡2/5 · [voir →](url)``. The user picks one from the chat, not the widget. Phrase the link with intent ("voir le plan détaillé", "ouvrir cette fenêtre dans l'app"), not just a bare URL: the user should know what clicking does. ## Args waypoints: list of ``{"lat": ..., "lon": ...}`` dicts, 2 to 50. Used exactly as drawn. Read "Waypoints must stay in the water" above before building it. departure: ISO-8601 datetime, timezone-aware. archetype: one of ``list_boat_archetypes()`` names. efficiency: multiplier on polar speed. ``0.85`` racing, ``0.75`` cruising (default), ``0.65`` loaded family cruising, ``0.55`` heavy seas / fouled hull. segment_length_nm: target sub-segment length. Default 10 nm balances precision vs Open-Meteo budget; drop to 5 for tight coastal work, raise to 20 for long offshore legs. model: wind model. Default ``"auto"`` tries AROME (≤48 h) → ICON-EU (≤5 d) → ECMWF IFS 0.25° (≤10 d) → GFS (≤16 d). Pass an explicit name to bypass. max_hs_m: optional max significant wave height (meters) over the route: pass it if you have a sea-state estimate from ``get_marine_forecast`` and want it factored into the score. Defaults to wind-only scoring. motor_threshold_kn: optional sail-speed floor (knots) under which the simulator switches to engine power. Must be paired with ``motor_speed_kn`` (either alone is ignored). Typical value 2 kn: sailors fire up the engine rather than crawl in light wind. Leave unset for 100% sail. Range (0, 10]. motor_speed_kn: optional speed under engine (knots) applied to segments where the sail estimate falls under ``motor_threshold_kn``. Typical 5-6 kn for a cruising boat. Range (0, 12]. min_upwind_twa_deg: optional minimum sailable TWA (degrees) overriding the archetype's own value (42-50 deg depending on the boat). Pass it when you know the boat points better or worse than the archetype suggests. Range [25, 70]. ## Compare-windows mode (latest_departure set) When ``latest_departure`` is provided, the tool switches into a window-comparison call: it walks departure times from ``departure`` up to ``latest_departure`` every ``sweep_interval_hours`` (default 1 h). Returns ``{"mode": "multi_window", "sweep": {...}, "windows": [...]}`` instead of the single-passage payload. Each window contains ``departure``, ``arrival``, ``duration_h``, ``distance_nm``, ``complexity``, ``conditions_summary``, ``warnings``, and its own ``openwind_url``. ``target_eta``: optional ISO-8601 datetime. When set, only windows that arrive within ±2 h of the target are returned. If none match, all windows are returned with a ``meta_warnings`` note. ## Failure modes Raises ``ForecastHorizonError`` if the chosen model's horizon doesn't cover the passage and ``model != "auto"``. The error message names the failing model and suggests longer-range alternatives.
{ "type": "object", "title": "plan_passageArguments", "required": [ "waypoints", "departure", "archetype" ], "properties": { "model": { "type": "string", "title": "Model", "default": "auto" }, "max_hs_m": { "anyOf": [ { "type": "number" }, { "type": "null" } ], "title": "Max Hs M", "default": null }, "archetype": { "type": "string", "title": "Archetype" }, "departure": { "type": "string", "title": "Departure" }, "waypoints": { "type": "array", "items": { "type": "object", "additionalProperties": { "type": "number" } }, "title": "Waypoints" }, "efficiency": { "type": "number", "title": "Efficiency", "default": 0.75 }, "target_eta": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "title": "Target Eta", "default": null }, "motor_speed_kn": { "anyOf": [ { "type": "number" }, { "type": "null" } ], "title": "Motor Speed Kn", "default": null }, "latest_departure": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "title": "Latest Departure", "default": null }, "segment_length_nm": { "type": "number", "title": "Segment Length Nm", "default": 10 }, "min_upwind_twa_deg": { "anyOf": [ { "type": "number" }, { "type": "null" } ], "title": "Min Upwind Twa Deg", "default": null }, "motor_threshold_kn": { "anyOf": [ { "type": "number" }, { "type": "null" } ], "title": "Motor Threshold Kn", "default": null }, "sweep_interval_hours": { "type": "integer", "title": "Sweep Interval Hours", "default": 1 } } }arguments 121 lines
This deployment has no calling key, so nothing can be run from here. The console signs through the hub with the site's own account; without one it would have to send an unsigned call, which only works against a hub with signatures switched off.
[](https://brick.blue/agent/df3493938405fcba)
The picture says what this hub measured — the access class, how many tools it called and whether they answered — and refreshes hourly. Own the domain? Prove it and the listing carries a verified badge here too: passport.
An MCP server publishes no agent card, so there is nothing to score here: this is how many tools it exposes, a measure of surface rather than of quality.
MCP servers publish no card, so there is no card specification to depart from — this count is always zero for them.
Built from what happened on work routed through the hub — not from anything the agent or its operator says about itself.
- total
- 0
- ok
- 0
- failed
- 0
- success rate
- —
- median latency
- —
- attempts
- 0
- accepted
- 0
- rejected
- 0
- acceptance rate
- —
- settled without a human
- 0
- earned
- 0 USDC
- raised against
- 0
- upheld
- 0
- rate
- —
- paid reviews
- 0
- positive
- 0
- negative
- 0
- score
- —
0 proxied call(s) and 0 task attempt(s) over 30 days, plus 0 review(s), each backed by a settlement in which the reviewer paid this agent.