OhMyWind

fr.ohmywind/sailing-plannerVersion 1.11.0

Sailing passage planner for any coast, with high-precision tides on the French Atlantic.

Status

Responds388 msNov 14, 2026, 14:31 UTCAnswered our handshake without sign-in.

Registry data may be out of date

We could not refresh it, so this page shows the last copy.

Last checked: Nov 14, 2026, 14:31 UTC
Latency: 388 ms
Remotes responding: 1 of 1
Sign-in: No sign-in
Hosting: Hosted outside the EU (detected)
Registry data as of: Nov 14, 2026, 22:14 UTC

Data from the official MCP Registry, checked by run.zero. How we check

Connect

Streamable HTTP

https://mcp.ohmywind.fr/mcpResponds388 msNov 14, 2026, 14:31 UTC

No sign-in

Claude Code

claude mcp add --transport http sailing-planner https://mcp.ohmywind.fr/mcp

Claude Desktop and claude.ai

1
2
3

Settings > Connectors > Add custom connector
Name: sailing-planner
Remote MCP server URL: https://mcp.ohmywind.fr/mcp

Cursor

{
  "mcpServers": {
    "sailing-planner": {
      "url": "https://mcp.ohmywind.fr/mcp"
    }
  }
}

VS Code

code --add-mcp '{"name":"sailing-planner","type":"http","url":"https://mcp.ohmywind.fr/mcp"}'

Built your own server? run.zero hosts MCP servers on European infrastructure.

Host your own MCP server on run.zero

Tools

5 tools

Tools of OhMyWind
	Description		Read-only	Idempotent	Open world
`get_marine_forecast`Wind, sea, and where it matters current and tide, at one point. For the questions about a place rather than a passage: how hard it blows at Groix this afternoon, when the thermal breeze fills in, when the mistral eases, whether the models agree, what the swell does at a harbour entrance tonight. Args: lat: latitude in degrees. lon: longitude in degrees. start: ISO-8601 datetime with the user's UTC offset (e.g. "2026-05-01T08:00:00+02:00"). Every time in the answer comes back in that offset. end: ISO-8601 datetime, timezone-aware. models: optional list of model names. Leave it unset for the automatic choice: AROME (1.3 km) wherever it reaches the window, and the next model that reaches its end when the window runs past two days. Name several models (``["arome", "icon_eu", "ecmwf", "gfs"]``) only when the user asks whether the models agree: each one costs a request. Returns hourly ``wind`` per model (speed, direction it comes from, gusts, in knots), ``sea`` (wave height, period, direction), and, only where they are material, ``current`` (speed in knots, direction it flows to, from a tidal atlas where one covers the point) and ``tide`` (height around mean sea level: read the range and the times of high and low water from it, not a depth over chart datum). Each series is a table: ``columns`` names the fields once, each of ``rows`` is one hour. Also ``openwind_url``, the OhMyWind map centred on the point. No widget comes with this tool. The values are a model forecast, not a measurement of what is blowing right now. Pass a point at sea. Open-Meteo Marine answers from the nearest sea cell: a few kilometres inland the ``sea`` values are the open coast's (Gui	Wind, sea, and where it matters current and tide, at one point. For the questions about a place rather than a passage: how hard it blows at Groix this afternoon, when the thermal breeze fills in, when the mistral eases, whether the models agree, what the swell does at a harbour entrance tonight. Args: lat: latitude in degrees. lon: longitude in degrees. start: ISO-8601 datetime with the user's UTC offset (e.g. "2026-05-01T08:00:00+02:00"). Every time in the answer comes back in that offset. end: ISO-8601 datetime, timezone-aware. models: optional list of model names. Leave it unset for the automatic choice: AROME (1.3 km) wherever it reaches the window, and the next model that reaches its end when the window runs past two days. Name several models (``["arome", "icon_eu", "ecmwf", "gfs"]``) only when the user asks whether the models agree: each one costs a request. Returns hourly ``wind`` per model (speed, direction it comes from, gusts, in knots), ``sea`` (wave height, period, direction), and, only where they are material, ``current`` (speed in knots, direction it flows to, from a tidal atlas where one covers the point) and ``tide`` (height around mean sea level: read the range and the times of high and low water from it, not a depth over chart datum). Each series is a table: ``columns`` names the fields once, each of ``rows`` is one hour. Also ``openwind_url``, the OhMyWind map centred on the point. No widget comes with this tool. The values are a model forecast, not a measurement of what is blowing right now. Pass a point at sea. Open-Meteo Marine answers from the nearest sea cell: a few kilometres inland the ``sea`` values are the open coast's (Gui	No	Yes	Yes	Yes
`get_tidal_stream`The tidal stream and the tide at one point, from the tidal atlases alone. For the questions about a pass or a harbour entrance: when to be at the Raz de Sein to carry the stream, when the Fromveur turns, how hard it runs at Port-Navalo tomorrow, when high water is at Chausey. Costs no weather request: harmonic predictions from the atlases this server ships (SHOM, MARC and others), the same ones ``plan_passage`` applies leg by leg. Args: lat: latitude in degrees, at sea, in the pass itself. lon: longitude in degrees. start: ISO-8601 datetime with the user's UTC offset; every time in the answer comes back in that offset. end: ISO-8601 datetime, timezone-aware. At most 400 steps. heading_deg: optional course through the point (true degrees, the direction you head to). With it, each step gets ``along_kn`` (positive: the stream carries you, negative: it stems you) and the answer lists the ``favourable`` and ``adverse`` windows. step_minutes: 5 to 180, default 30. Returns ``covered``, ``source``, ``confidence``, ``points`` (a table: ``columns`` time, ``speed_kn``, ``direction_to_deg`` it flows to, ``along_kn``, ``height_m`` around mean sea level; one row per step), ``slack`` (the moments the stream nearly stops), ``high_waters`` / ``low_waters``, ``favourable`` / ``adverse`` when a heading is given, ``tide_coefficient`` (French national coefficient, Brest, on French atlases), a ``warning`` when the atlas does not resolve the pass, and ``openwind_url``. Outside every atlas (most of the Mediterranean, the open sea) ``covered`` is false; ``get_marine_forecast`` returns the global model's current there, where it matters. Astronomical tide only: no surge, no wind-driven cur	The tidal stream and the tide at one point, from the tidal atlases alone. For the questions about a pass or a harbour entrance: when to be at the Raz de Sein to carry the stream, when the Fromveur turns, how hard it runs at Port-Navalo tomorrow, when high water is at Chausey. Costs no weather request: harmonic predictions from the atlases this server ships (SHOM, MARC and others), the same ones ``plan_passage`` applies leg by leg. Args: lat: latitude in degrees, at sea, in the pass itself. lon: longitude in degrees. start: ISO-8601 datetime with the user's UTC offset; every time in the answer comes back in that offset. end: ISO-8601 datetime, timezone-aware. At most 400 steps. heading_deg: optional course through the point (true degrees, the direction you head to). With it, each step gets ``along_kn`` (positive: the stream carries you, negative: it stems you) and the answer lists the ``favourable`` and ``adverse`` windows. step_minutes: 5 to 180, default 30. Returns ``covered``, ``source``, ``confidence``, ``points`` (a table: ``columns`` time, ``speed_kn``, ``direction_to_deg`` it flows to, ``along_kn``, ``height_m`` around mean sea level; one row per step), ``slack`` (the moments the stream nearly stops), ``high_waters`` / ``low_waters``, ``favourable`` / ``adverse`` when a heading is given, ``tide_coefficient`` (French national coefficient, Brest, on French atlases), a ``warning`` when the atlas does not resolve the pass, and ``openwind_url``. Outside every atlas (most of the Mediterranean, the open sea) ``covered`` is false; ``get_marine_forecast`` returns the global model's current there, where it matters. Astronomical tide only: no surge, no wind-driven cur	No	Yes	Yes	No
`list_boat_archetypes`List the 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. ``voile_aviron_16ft`` is for open sail-and-oar dinghies only (no cabin, rowed as well as sailed); a small cabin cruiser maps to ``cruiser_20ft``.	List the 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. ``voile_aviron_16ft`` is for open sail-and-oar dinghies only (no cabin, rowed as well as sailed); a small cabin cruiser maps to ``cruiser_20ft``.	No	Yes	Yes	No
`plan_passage`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``. 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. 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. Two ways to go ("nord ou sud du Fromveur pour Ouessant ?", "par l'intérieur ou l'extérieur des Glénan ?", "Ré ou Aix demain ?"): one ``plan_passage`` call, the first route in ``waypoints`` and the others in ``alternatives`` (two at most), each with a short ``label`` saying how it goes ("Par le nord du Fromveur"). Every route is computed for the same departures, so the widget compares them cell by cell. Do not make one call per route. 5. When to be at a pass ("à quelle heure au Raz de Sein ?", "quand renverse le courant au Fromveur ?"): `	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``. 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. 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. Two ways to go ("nord ou sud du Fromveur pour Ouessant ?", "par l'intérieur ou l'extérieur des Glénan ?", "Ré ou Aix demain ?"): one ``plan_passage`` call, the first route in ``waypoints`` and the others in ``alternatives`` (two at most), each with a short ``label`` saying how it goes ("Par le nord du Fromveur"). Every route is computed for the same departures, so the widget compares them cell by cell. Do not make one call per route. 5. When to be at a pass ("à quelle heure au Raz de Sein ?", "quand renverse le courant au Fromveur ?"): `	No	Yes	Yes	Yes
`read_me`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, regional defaults, wind against current, short-period chop, what is intentionally not modelled, and the data attributions.	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, regional defaults, wind against current, short-period chop, what is intentionally not modelled, and the data attributions.	No	Yes	Yes	No

Details

Registry status: Active
Published: Oct 21, 2026
Updated: Oct 21, 2026
Website: https://ohmywind.fr/⁠ (opens in a new tab)
Repository: https://github.com/qdonnars/ohmywind⁠ (opens in a new tab)
Categories (suggested): Data and analyticsSuggested categories are assigned automatically from the registry text and may be wrong. Verified operators can correct them.
GDPR: Not declared

Are you the operator? Claim this listing